[Panel-devel] SuperKaramba meeting results

[Wade Olson]

Thanks for the meeting notes Ryan.

On 9/5/05, Ryan Nickell <p0z3r at earthlink.net> wrote:
> 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.
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>