[Panel-devel] Superkaramba applets configuration

[Fred Schaettgen]

On Wednesday, 22. June 2005 22:50, Aaron J. Seigo wrote:
> On Tuesday 21 June 2005 09:52, Fred Schaettgen wrote:
> well, i want the panel to be properly themable, including being sensitive
> to the contents of what's on it. this is not the same as necessitating that
> all applets are 100% themable.
...
> this is essentially the idea behind libplasma being the "applet API". how
> that ends up looking is a good question, though. after reading your email
> here and thinking about it for a bit, it seems to me that instead of one
> library we may end up with one core lib and several optional API "plugins".
> libtaskmanager and libtaskbar could be one of our first use case for these
> "API extending plugins", with the clock providing another.

Yeah, that would be great. 
I'm absolutely not asking to do the gui of every applet with a script, since 
this will easily lead to serious performance problems. So scripting the 
taskbar might be a not so good idea. But having both a clock with a KJS-based 
script engine and SK-applets with different script engines is bloat, too. 

> my concern with having core applets not written in C++ is tied to
> performance and maintainability. core applets, by which i mean applets that
> loaded as part of the default configuration, should be as tight as
> reasonable and have few dependencies.
>
> if you wish to write the entire clock applet in ECMA Script using the built
> in plasma bindings for KJSEmbed and that turns out to be performant enough,
> then by all means go ahead. ...

Certainly not. The scripted parts of the desktop should be kept down to a 
minimum. The gnome counterpart of kdebluetooth seems to be written in python, 
at least partly. And from peeking into their mailinglist from time to time I 
don't feel very encouraged to use a script language to implement a whole KDE 
application.
But there will be the clock and there will be SK and I don't want them to do 
everything twice. It would be harder for them to learn, harder for me to 
maintain and harder for the system to run.

And if the script API can be extended for single applications, then using 
scripts for an applet wouldn't be an all-or-nothing decision. It would blur 
the line between scripted applets and C++ applets, which is a good thing in 
my eyes, because it leaves no excuse for any inconsistencies of the look or 
behavior of these two types of applets.

Fred

-- 
Fred Schaettgen
kde.sch at ttgen.net