[Panel-devel] applet facilities

[Vinay Khaitan]

hi,

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 :-) .


applet theming needs to be centralized. right now it's a PITA to try and get
> all your SK widgets looking the same. and they look far nicer when they
> do. i
> have noticed some graphical themes are carried across SK widgets, but it's
> pretty haphazard. the biggest thing is the widget background and borders,
> really. these are already written in as part of the plasma theme, so that
> shouldn't be a big issue. and this way the user can select a given widget
> style and all the widgets will match. there is no reason "custom
> backgrounds"
> for applets can't be added, of course. but applets shouldn't have to care
> about it; this should be handled by the AppletComposer.


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.

applet configuration should be standardized. requiring PyQt is a bit much
> (and
> becomes insane if people will be mix'n'matching applets in different
> langs),
> and we can do better than using KDialog. i'm thinking we use KConfigXT XML
> and include those in the applet bundle. an AppletConfigXT class would then
> read in the KConfigXT XML and create an appropriate KConfigSkeleton item.
> combined with a designer .ui file, this can create automagically working
> config dialogs. designer files can be instantiated at runtime (obviously)
> and
> connected with a KConfigSkeleton object (also obvious =). so an applet
> could
> simply call:
>
>         showConfig();
>
> and given a .ui file get a nice shiny GUI. if the .ui is missing, we could
> provide a standard (boring) widget or even rely on KConfigDialog to
> autogen
> the UI for us.


I am okay with the idea of configurationXT . 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.


applet bundles: applets should come with bundles. C++ based applets will
> ship
> both a library and a bundle,


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.

I am sorry, I am to tired to think atm, so may be I would have done some
mistakes in the mail.

Vinay Khaitan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20060105/b9ac04ee/attachment-0001.html