[Panel-devel] Sensors and Meters in SK

[Vinay Khaitan]

Noone replied negatively. So should I assume that there is nothing wrong 
with this idea. I would do experiements in 
branches/work/superkaramba ?

On 9/7/05, Vinay Khaitan <vkhaitan at gmail.com> wrote:
> 
> Hello Everyone,
> 
> First of all, Sorry to [mX] for putting SK back in the scenario of plasma 
> ;-)
> 
> I saw the slides of Aaron's presentation about plasma. Looks like he has 
> very nice and very well defined ideas about plasma. There are things which 
> suits to our purposes too. As superkaramaba is going to be integrated to 
> plasma, and some of the libs of SK may be useful to other plasma components, 
> I think It would be very nice to make such libs of SK decoupled from SK 
> design and make generic enough to be used by other extenders, applets. 
> First thing, sensors.
> 
> Right now, sensors are integrated with SK as We can define in theme file, 
> which sensor is shown by a meter.The purpose of sensor is just to provide 
> data independent of how the data is being shown, So sensor has nothing to do 
> with meter.
> We can create a interface of the class sensor, which will be implemented 
> by subclasses.The interface may consist of :-
> 
> type(), which says what type of data is returned by the sensor. it can be 
> bool,int,QString,QMap<QString,QString> 
> returnValue() which actually returns the value.
> readOnly(), which tells if sensor is readOnly Or its properties can be 
> changed. e.g., cpusensor is readonly. xmmssensor is read-write..
> SIGNAL update(), which can be connected by a meter to know when it needs 
> to be updated.
> ....and so on.
> 
> Sensors doesn't know anything about Meters at all. This way, sensors are 
> useful for all the applets and extenders too. 
> And one more useful feature is that, we can make sensor interface public 
> and sensors can be created as plugins.
> 
> Now Meters:-
> Meters actually acts as widgets but implemented as QObject, where they 
> just paint over karambawidget. I think, this is inefficient as one repaint 
> of karambawidget results in repaint of all the Meters(because karambawidget 
> iterates over all the meters for painting). QWidgets are inherently 
> optimized for painting. We should utilize this fact. Make all the Meters as 
> real Widgets with karambaWidget as Parent widget.
> The Meter Widgets would be very customizable. Take e.g. bars:- We should 
> be able to set Mask, backgrounds etc. It may even be possible to make the 
> each percent of bar as different picture. This way bars can be converted 
> into a dial(through assigning different QPixmap for different percentage).
> 
> theme write are responsible to connect meters to sensors. For example, 
> setBarValue(cpuload.returnValue()). then connecting sensors update SIGNALS 
> to meters slots.
> 
> Now, As meters are very customizable, these meters can be used even by 
> applets and extenders. 
> meters would go into libplasma. Sensors would become plasma engine.
> 
> The SK parts part would be done by KarambaWidget. KarambaManager would 
> load/unload theme. It creates KarambaWidget and And its childwidgets and all 
> the language interface stuff, as we discussed.
> So we should start making sensors free of meters. and meters, free of 
> sensors in SK codebase.
> Is this design looks good enough?
> 
> Vinay Khaitan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050908/a15e96cd/attachment.html