[Panel-devel] Superkaramba applets configuration

[Fred Schaettgen]

On Tuesday, 21. June 2005 09:24, Marc Cramdal wrote:
> Hello,
>
> This post is about SK applets configuration.
>
> Currently, some applets like Liquidweather++ uses context menus for
> the configuration. I find this not very usable : when you want to
> configure it the first time, you have to right-click, then browse
> through menus many times. So why not provide some kind of generic (and
> eyecandy ;-)) config dialog for Superkaramba applets which would have
> all the config options in the same dialog ?

Good that you ask this question.
In my opinion the API configuration dialogs should not be limited in any way.
I'm the author of a themeable clock applet (styleclock), which Aaron wants to 
become the default clock for KDE4. It uses javascript for the themes and 
OpenGL for the output, mainly because I didn't want it to introduce new 
dependencies. But if KDE4 comes with SK included, it would certainly be 
better for it to reuse the scripting API and get-new-theme-dialogs and what 
else of SK.

But my biggest concern is in fact configuration. While it might be ok for hand 
crafted just-for-me themes to be configured with context menues, this is 
totally unacceptable for themes that will be part of every KDE desktop.
I also don't like the idea of *having* to do the configuration GUI with a 
scripting language, unless we can be sure that the scripting API is as 
feature complete, stable and efficient as the C++ counterpart.
Or a similar problem - will I be able to pop up a calendar next to the clock 
with a SK theme?

What if we limit the scripted part of the applets to just the regular applet 
GUI, not including configuration and other dialogs opened by interacting with 
the applet?
We could have different applet engines written in C++. Every theme (script) 
picks one applet engine and thus chooses the API available to the script code 
of the theme - somewhat similar to the ksplash engines and themes.
Most applets will come with a dedicated applet engine, because they have very 
special requirements. But it would still be possible to create new themes for 
the same engine - new clock faces for the clock engine, new taskbar themes 
for the taskbar engine etc.
And very simple applets could use a generic applet engine, which has no 
configuration options at all or a simple script API to create custom config 
dialogs - but none of the applets shipped with KDE should use those.

Well, these were just the thoughts of a good-old-applet author, who doesn't 
know much about SK so far. If SK does or will work like that, then I don't 
see a problem with the configuration. 

Fred
-- 
Fred Schaettgen
kde.sch at ttgen.net