[Panel-devel] Superkaramba applets configuration

Aaron J. Seigo aseigo at kde.org
Wed Jun 22 22:50:40 CEST 2005


On Tuesday 21 June 2005 09:52, Fred Schaettgen wrote:
> > the taskbar will also almost
> > certainly continue to be C++. other applets will almost certainly not be
> > C++, however. all will be "plasma applets", however.
>
> I see. IIRC you said somewhere that you want all plasma applets to the
> themeable, then there was the announcement of SK becoming part of KDE4. So
> my conclusion was that your plan was to do the UI of all plasma applets
> with a scripting language at some point.

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.

> > so yes, you'll be able to pop up a calendar next to the clock =) whether
> > you can do that in language X is another question. if a calendar is a
> > common enough need for scripted plugins, then we may include an interface
> > for that in libplasma.
>
> That was my point. The calendar will only be used for the clock for sure.
> So I was hoping that I'll be able to create an own widget host, which
> derives from the generic widget engine, but provides an additional
> "ShowCalendarWidget" method to the themes it is hosting.

ah, i see what you're saying now. yes, this makes lots of sense.

> I don't see how this would complicate the live of applet authors. They
> would simply write their applet script and do whatever they want as usual.
> But probably they won't be able to do everything with a script in a clean,
> usable and efficient way. If they want to write a task management applet or
> a system monitor applet, they would specify somewhere in their applet
> descriptor to use the task management applet engine and they would be
> provided with the API they need for that task, together with proper
> configuration dialogs for that specific use case.

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.

an open question is how to make it easy to provide non-C++/JS bindings for 
these.

> > and to be honest, with Qt Designer files it's pretty easy to do slick
> > configuration dialogs in JS or Ruby. i'm sure it's the same or similar in
> > Python.
>
> Hm, then give me a single reason why I should reinvent the wheel for
> styleclock and define a Javascript API and everything else instead of
> making it a SK applet ;)

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. writing it in Python or Ruby is right out, though.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20050622/ebdde4d9/attachment.pgp


More information about the Panel-devel mailing list