[Panel-devel] applet facilities

[Ryan]

On Wednesday 04 January 2006 17:49, Aaron J. Seigo wrote:
> hi all...
>
> so while playing with applet related code in plasma and messing around with
> SK i've arrived at the following thoughts. please discuss them, expand on
> them, add to them, etc...
>
> 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.

Agreed.  Graphical consistency is something that is lacking across the board 
with any widget system on any OS currently.  It would be nice to offer 
widgets the ability to "adopt" a look/feel offered by a standard KDE install 
or a third party style.  This is similar to how windecs and styles work 
nowadays.  One drawback is that we need to make the style generation much 
easier for people to work on without having to dive through code and existing 
styles while asking for help in places that that they may or may not get 
answers.  Before I go off on that tangent, I would also like the ability for 
someone to apply a "unique style" for their individual widget should they 
want.  The idea here is coming from existing applications such as amaroK.
AmaroK has its own style or you can use their style in the music 
browser/player window.  It doesn't follow necessarily the selected Qt style, 
but it is unique to the application.

Returning to the drawback issue, creating widget styles needs to be easy.
As simple as someone drawing a pixmap and selecting borders, corners, body of 
widget, etc., so that the average joe can contribute to our beautification.  
I'm kind of speaking of what I saw geieri doing the other night so I know 
that this is mostly possible if not already closely there.  Regarding a place 
to ask questions, the developer.kde.org site is good for us low level 
developers, but we'd also need some resource available to common users either 
an associated pdf manual from head to toe on how to make widgets, 
screenshots, etc or a nicely marketed website solely focused on widgets 
(maybe a revamp of the kdelook site for the plasma release?).

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

Not much for me to comment on here as I'm not too familiar with the KConfigXT 
stuff currently, but as long as it is directed toward unifying the 
configuration dialogs for all widgets it sounds good here.

>
> applet bundles: applets should come with bundles. C++ based applets will
> ship both a library and a bundle, while script applets will provide just a
> bundle with the scripts included. basically what sk does right now. i would
> like to sanitize the layout of the bundles, though, and define how things
> are generally laid out. that way we can provide a nice little bundle
> assembler GUI for applet authors.

Mandating the layout to be more strict than the current SK schema would be a 
good idea as it has created a little more complexity than I want, but it 
still does the job for what it does.

>
> general theming: i'm currently working with ken weimer to nail this puppy
> down better. looks like right now it'll be a set of svg files in a zip file
> with a directory structure like this:
>
> /plasma
>      \___ chain_endcap_left.svg
>
>      |___ .... more files ...
>
> by keeping all the files in a /plasma dir, we can then add more directories
> in the future so that hopefully a theme pack may include svg's for widget
> styles, window decorations and plasma bits... we should have some sample
> svg's to play with in svn shortly, courtesy of ken.

Is there going to be some sort of manifest as well in the widget bundle so 
that way things like version, author, license, contact info, binding 
language, etc.? 
 
Will we have a way to tie the bundle to some initial relative position on the 
screen when ran so that later in the game we can tie multiple widgets to a 
complex layout of sorts?  i.e. Foo widget is top/left corner of screen layout 
and Bar widget is RightOf Foo.

Just my thoughts.
-Ryan