[Panel-devel] applet facilities

[Aaron J. Seigo]

On Thursday 05 January 2006 01:44, Vinay Khaitan wrote:
> It's nice to see that finally there is something going in plasma in "open"
> . Although I know that the core-work were going with full pace behind the
> doors :-) .

where "the doors" is another way of saying "my eyelids" ;)

> I could understand it, please clarify. AFAIK SK widgets are native kde
> widgets with its own customisations. Those customisations are defined by
> theme writer. If they don't, it will fall back to default. So,  where this
> theming funda comes from? I may be missing something probably.

this is one thing i'm hoping to change. right now i have 4 different SK 
widgets on my desktop. i like and use all of them. they all look completely 
different and there's no way for me fix this without hacking the themes. i'd 
like to make it easy for applet creators to use a commonly provided set of 
(svg) theme pieces so that instead of each coming up with their own borders, 
backgrounds, etc there is a global one they can access. this will be provided 
by way of the AppletCompositor.

> I am okay with the idea of configurationXT . 

Petri of KMediaFactory emailed me today to let me know that he's already got 
code for this. looks like we're further along than we expected!

> I am just thinking about 
> signals and slots though. I think, there XML file or UI file can be
> extended to call the slots or generate signal, when user does something to
> UI, and then those signal/slots can be used by whatever language theme for
> doing something.

i'm not sure this is needed. looking at the config dialogs around KDE, only 
the most complex even make calls within themselves let alone to the host app. 
for the kind of config that applets tend to do, it's pretty much only 
necessary to let them know that the config changed once the user is done. if 
the need for more complex dialogs arises, that applet can either provide a 
language-native dialog (e.g. a kjsembed one if it's a kjs applet) or we can 
(if demand is there) provide for this in the framework.

for now though, simple is better. add as needed. agility =)

> Some problems with compiled languages. The library would be compatible with
> the underlying system or not.....who knows ? Some ABI issues, versioning
> issues etc ?
> I think, that's where scripting langauges have advantages.

of course. which is why we're offering, and even promoting, them. not allowing 
for C++ applets at all seems a bit unecessary, however.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- 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/20060105/bab2273b/attachment.pgp