[Panel-devel] SuperKaramba meeting results

[Matt Broadstone]

Oh wade, you know I made them so nice and formatted _just_ for you :P
*HUUGS*


On 9/5/05, Wade Olson <wadejolson at gmail.com> wrote:
> 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
> >
> _______________________________________________
> Panel-devel mailing list
> Panel-devel at kde.org
> https://mail.kde.org/mailman/listinfo/panel-devel
>