[Panel-devel] SuperKaramba plans

[Aaron J. Seigo]

On Tuesday 06 December 2005 16:12, Ryan wrote:
> SuperKaramba can do.  From what I understand, it will be composed of kparts
> and a "scripting glue" from one of the language bindings. 

the "kparts" thing is not at all a for sure thing at this points. it's one 
approach that is being tried. it may end up being too heavy, not flexible 
enough or just right.

> There will be 
> some way for people to define their workspace layouts that others can also
> use simply by loading the config.

yes ... this is not one of the first things to tackle, however.

> reorganization in /trunk/KDE/kdeutils/superkaramba.  My understanding is
> that Plasma will not be using any of the SK code, but instead expanding on
> SK's ideas and possibilities. 

as we discussed a few months ago before i got busy with finishing up with 3.5 
and dealing with doing presentations every other week, the idea is to 
separate out the "business logic" from the presentation in SK and turn the 
set of classes that provide information on the system, etc.. that SK themes 
currently use into thematic engines for use by plasma applets.

this was the approach attempted by the taskbar library in kicker and it worked 
pretty well (except that it didn't properly implement things as a model; it 
was half-model, half-view, half-confused ;) ... it allowed the creation of 
the standard taskbar, the window-aware pager and kasbar without rewriting any 
of the task management code.

this approach should allow us to more easily create applets that rock without 
reinventing the wheel (and the configuration of said wheel) over and over if 
applied to other fields.

SK already has quite a few of these types of classes, and they ought to be 
organized better and provide data models that applets can access / query. as 
we discussed, they should probably be accessible via a singleton type pattern 
wherever possible to limit memory and other resource consumption.

i suppose i have no one to blame for this knowledge being lost as i didn't sit 
down and write out the conclusions of these conversations in great detail. 
hoping that the email archives would be enough is obviously silly, and 
expecting anyone else to do this is almost equally so.

> Or a much simpler question, what needs help and where can I/we find a
> direction to move?

zack rusin is spending a few weeks at my place this month during which time we 
will be working on getting the foundational layers of code down for plasma.

from there we can move forward with creating the actual engines, starting with 
applet development, etc... until then, i really don't know whether to suggest 
working on engine related stuff, the Qt4 SK stuff you mentioned or just to 
enjoy the holiday season ;)

-- 
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/20051212/01a9b9ee/attachment.pgp