[Panel-devel] Design of Sensor and meters

[Ryan Nickell]

On Tuesday 13 September 2005 20:56, Aaron J. Seigo wrote:
> On Monday 12 September 2005 10:40, Vinay Khaitan wrote:
> > Pedro has done some refactoring of superkaramba. He has encountered some
> > design troubles. They are similiar to what I had earlier talked about
> > i.e. meters dont know the format sensor's return value. And type of
> > return value doesn't give any information about that.
>
> if you need a key->value mapping, that's what a Map is for. e.g.
> QMap<QString, QVariant>
>
> 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.

Me neither. There should be a way that sensors can asynchronously update a 
meter when it has new data, and then the meter can choose to update it's GUI 
counterpart depending on what the theme developer specifies.  Probably 
implemented via slots/signals. 

>
> > 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.

Personally I don't like the pseudo xml .theme file format.  I feel that it 
needs to be a bit more formal.  Of course that is just for plasmoids that are 
only implemented in this way.  Other plasmoids will be written in ruby, 
kjsembed, etc., that will have their own structure b/c of the language they 
are written.

>
> 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. what does
> concern me is the layout / geometry stuff:
>
> meter.setSpacing 50
> bar.x=0 bar.y=etc
>
> this stuff tends to get really messy if you work with translated strings,
> themed widgets (e.g. not just pixmaps) and what not.. it's usually better
> to use layouts and define basic properties like preferred size, spacing and
> margins (all of which tend to have good defaults).

This could be a better avenue that would allow a more flexible approach than 
traditional SK themes, but it may "raise the bar" for people starting out 
since they would need to understand these concepts before making 
themes/plasmoids.