[Panel-devel] SuperKaramba meeting results

[Ryan Nickell]

Barring any changes from people that were unable to attend the meeting, here's 
what we came up with today.  We are open to suggestions and changes since all 
this information is tentative.

Results of the September 04, 2005 SuperKaramba meeting:

 * Restructuring
 * Refactoring
 * Bindings
 * ETC

Restructuring
---------------
We will be restructuring the build environment of SuperKaramba.
To make it a bit more sane, the new directory structure will be laid out
like this:

superkaramba/
        libsk/
        bindings/
                python/
                ruby/
                perl/
                etc...
        meters/
        sensors/



Refactoring
---------------
KarambaApp will be cut down to handle only KApplication initialization as
well as the new KarambaManager.

KarambaManager will be very much like kicker's [Extension,Menu]Manager 
classes. Its job will be simply: to load/unload themes. The loading will
take place once the theme is read and the language the theme was written
in is determined.  At that point, a KarambaWidget will be created with
the access to the correct language binding.

karamba will become KarambaWidget
This will be a instantiated when the KarambaManager reads the theme and is
told what language it was written in.  An AbstracInterface will be
determined and will call into the correct language binding library for the
look/feel/functionality of the theme. The KarambaWidget will handle all the
needed updating and drawing independent from the KarambaManager.

Bindings
----------------
AbstractInterface
Each KarambaWidget will have an AbstractInterface. An AbstractInterface is
an ABC (Abstract Base Class) for language bindings in SuperKaramba. It will
provide purely virtual methods which represent the functionality we provide
to the theme creators. Subclassed Interfaces will provide functionality
to these virtual methods according to that specific language (PythonInterface,
RubyInterface..)

Pedro and Matt have been looking into Richard Dale's work, in hopes that we
may be able to use his tools (notably Kalyptus with SMOKE) to generate a lot
of this code for us. The way it seems right now there will be a different 
lib created for each binding: libsk_python libsk_ruby libsk_perl etc..

ETC
---------
These are some important definitions that were presented at the meeting.
There was a certain amount of confusion surrounding their specific 
definitions and Petri cleared that up.

Meters
Meters are like small widgets.  Meters display the values of sensors.
Different Meters include Text, Image, Bar, ClickArea, Graph, InputBox,
RichText.

Sensors
Sensors are data objects where data is stored.  Sensors allow you to display
system properties automatically through a Meter.  There are sensors that hold
the status of everything from memory use to the results of shell scripts.
Different sensors include cpu, date, memory, network, noatun, xmms, uptime,
rss, sensor (i.e. lmsensors), disk, program.

And lastly...
Backwards Compatibility
As much as possible be backward compatible to current themes.  We want to
carry the current theme developer community with us as we transition.