I think, most of the structures have been finalized. So I would suggest
that we should start some higher level coding now(like karamba
application and karamba manager).<br>
<br>
I propose that make a directory inside trunk/kde/work/superkaramba.<br>
<br>
those people, who had design in mind(matt, ryan) start the main
application part. then divide the work of other part in smaller task
and assign them. We will utilize SK code in that eventually.<br>
<br>
Am I making sense?<br>
<br>
Vinay Khaitan<br><br><div><span class="gmail_quote">On 9/4/05, <b class="gmail_sendername">Ryan Nickell</b> <<a href="mailto:p0z3r@earthlink.net">p0z3r@earthlink.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Barring any changes from people that were unable to attend the meeting, here's<br>what we came up with today. We are open to suggestions and changes since all<br>this information is tentative.<br><br>Results of the September 04, 2005 SuperKaramba meeting:
<br><br>* Restructuring<br>* Refactoring<br>* Bindings<br>* ETC<br><br>Restructuring<br>---------------<br>We will be restructuring the build environment of SuperKaramba.<br>To make it a bit more sane, the new directory structure will be laid out
<br>like this:<br><br>superkaramba/<br>libsk/<br>bindings/<br>python/<br>ruby/<br>perl/<br>etc...<br>meters/<br>sensors/<br><br><br><br>Refactoring<br>---------------<br>KarambaApp will be cut down to handle only KApplication initialization as
<br>well as the new KarambaManager.<br><br>KarambaManager will be very much like kicker's [Extension,Menu]Manager<br>classes. Its job will be simply: to load/unload themes. The loading will<br>take place once the theme is read and the language the theme was written
<br>in is determined. At that point, a KarambaWidget will be created with<br>the access to the correct language binding.<br><br>karamba will become KarambaWidget<br>This will be a instantiated when the KarambaManager reads the theme and is
<br>told what language it was written in. An AbstracInterface will be<br>determined and will call into the correct language binding library for the<br>look/feel/functionality of the theme. The KarambaWidget will handle all the
<br>needed updating and drawing independent from the KarambaManager.<br><br>Bindings<br>----------------<br>AbstractInterface<br>Each KarambaWidget will have an AbstractInterface. An AbstractInterface is<br>an ABC (Abstract Base Class) for language bindings in SuperKaramba. It will
<br>provide purely virtual methods which represent the functionality we provide<br>to the theme creators. Subclassed Interfaces will provide functionality<br>to these virtual methods according to that specific language (PythonInterface,
<br>RubyInterface..)<br><br>Pedro and Matt have been looking into Richard Dale's work, in hopes that we<br>may be able to use his tools (notably Kalyptus with SMOKE) to generate a lot<br>of this code for us. The way it seems right now there will be a different
<br>lib created for each binding: libsk_python libsk_ruby libsk_perl etc..<br><br>ETC<br>---------<br>These are some important definitions that were presented at the meeting.<br>There was a certain amount of confusion surrounding their specific
<br>definitions and Petri cleared that up.<br><br>Meters<br>Meters are like small widgets. Meters display the values of sensors.<br>Different Meters include Text, Image, Bar, ClickArea, Graph, InputBox,<br>RichText.<br><br>
Sensors<br>Sensors are data objects where data is stored. Sensors allow you to display<br>system properties automatically through a Meter. There are sensors that hold<br>the status of everything from memory use to the results of shell scripts.
<br>Different sensors include cpu, date, memory, network, noatun, xmms, uptime,<br>rss, sensor (i.e. lmsensors), disk, program.<br><br>And lastly...<br>Backwards Compatibility<br>As much as possible be backward compatible to current themes. We want to
<br>carry the current theme developer community with us as we transition.<br>_______________________________________________<br>Panel-devel mailing list<br><a href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/panel-devel">
https://mail.kde.org/mailman/listinfo/panel-devel</a><br></blockquote></div><br>