<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">if you need a key->value mapping, that's what a Map is for. e.g. QMap<QString,<br>
QVariant></blockquote><div><br>
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 .<br>
<br>
So we can have single return value. Nice! it is more efficient.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">and again i really don't like the concept of meters constantly making calls to<br>
sensors to grab bits of data. just send the current state of the sensor in a<br>signal to a slot in the sensor (it's cheap if we pass it by const reference)<br>and it's done.</blockquote><div><br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> MULTIMETER meter=bar number=2 orientation=horizontal, separationX=50<br>> separationY=50
value.1=cpu0.system bar.x=0 bar.y=etc<br>> value.2=cpu1.systemSENSOR=cpusensor<br><br>oi vey. we need to have a discussion about what plasmoids are going to look<br>like.<br><br>to boil it down to essentials: are they going to be scripts, or are they going
<br>to be "theme files". the latter will certainly not encompasse the needs of<br>plasma applets in the least, though theme files could be a specialized kind<br>of plasmoid (and loaded via a theme container.. all transparent to the user,
<br>so no concerns there). <br>
</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">so if we say that plasmoids will be actual code at the most base level, with a
<br>simplistic theme engine added on top of that, then we ought to start phrasing<br>our use cases in those terms.<br><br>> The separation stuff would set the separation of multiple meters.<br>> orientation is separation orientation.
<br><br>how about:<br><br>MULTIMETER meter<br>meter.setType bar<br>meter.setNumberOfMeters 2<br>meter.setOrientation horizontal<br>meter.setMeterKey 1 cpu0.system<br>meter.setMeterKey 2 cpu1.system<br>SENSOR sensor = cpusensor
<br>meter.connectTo sensor<br><br>looks almost identical, but is done more like a real script.</blockquote><div>The format of theme file was not my intention in first mail, but inteface of sensors and meters only. <br>
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.<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> what does concern<br>me is the layout / geometry stuff: <br>
</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">meter.setSpacing 50<br>bar.x=0 bar.y=etc</blockquote><div>Well, using the layout for geometry also looks very nice idea. I am for it.
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">this stuff tends to get really messy if you work with translated strings,<br>themed widgets (
e.g. not just pixmaps) and what not.</blockquote><div><br>
I cant forsee the mess in those two things.<br>
</div><br>
</div>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?<br>
<br>
And pedro, the idea of Q_PROPERTY was introduced for things like
MOUNTPOINT which can sometimes arise in specific types of sensors.<br>
<br>
Vinay Khaitan<br>