[Panel-devel] Design of Sensor and meters

[Vinay Khaitan]

> 
> if you need a key->value mapping, that's what a Map is for. e.g. 
> QMap<QString,
> QVariant>


hmm, yes! QMap<QString.QVariant> looks sufficient. Actually I wanted that we 
should be able to use the format like network.interface.eth0 . So in 
QMap<QString,QVariant>, if a key needs more than one dot, the QVariant 
itself can be QMap<QString,QVariant>. So actually, we have the option of 
using %alpha.beta.gamma.delta .

So we can have single return value. Nice! it is more efficient.

and again i really don't like the concept of meters constantly making calls 
> to
> sensors to grab bits of data. just send the current state of the sensor in 
> a
> signal to a slot in the sensor (it's cheap if we pass it by const 
> reference)
> and it's done.




> MULTIMETER meter=bar number=2 orientation=horizontal, separationX=50
> > separationY=50 value.1=cpu0.system bar.x=0 bar.y=etc
> > value.2=cpu1.systemSENSOR=cpusensor
> 
> oi vey. we need to have a discussion about what plasmoids are going to 
> look
> like.
> 
> to boil it down to essentials: are they going to be scripts, or are they 
> going
> to be "theme files". the latter will certainly not encompasse the needs of
> plasma applets in the least, though theme files could be a specialized 
> kind
> of plasmoid (and loaded via a theme container.. all transparent to the 
> user,
> so no concerns there). 
> 
so if we say that plasmoids will be actual code at the most base level, with 
> a
> simplistic theme engine added on top of that, then we ought to start 
> phrasing
> our use cases in those terms.
> 
> > The separation stuff would set the separation of multiple meters.
> > orientation is separation orientation.
> 
> how about:
> 
> MULTIMETER meter
> meter.setType bar
> meter.setNumberOfMeters 2
> meter.setOrientation horizontal
> meter.setMeterKey 1 cpu0.system
> meter.setMeterKey 2 cpu1.system
> SENSOR sensor = cpusensor
> meter.connectTo sensor
> 
> looks almost identical, but is done more like a real script.

The format of theme file was not my intention in first mail, but inteface of 
sensors and meters only. 
But, I must say, I like the idea of script type theme file much more that 
current theme file structure. It looks a lot readable for any programmer 
that the current theme file.

 what does concern
> me is the layout / geometry stuff: 
> 
meter.setSpacing 50
> bar.x=0 bar.y=etc

Well, using the layout for geometry also looks very nice idea. I am for it.

this stuff tends to get really messy if you work with translated strings,
> themed widgets (e.g. not just pixmaps) and what not.


I cant forsee the mess in those two things.

So after discussion with pedro,ryan and you, it looks the structure of 
meters and sensor seems agreed by all of us. is it? Should we go for it?

And pedro, the idea of Q_PROPERTY was introduced for things like MOUNTPOINT 
which can sometimes arise in specific types of sensors.

Vinay Khaitan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/panel-devel/attachments/20050914/18ee2df7/attachment-0001.html