<div><div><br>
Hi, <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;">Having a parent/child relationship between meters sounds like just another way<br>
to do what we are already doing according to your example. Currently people<br>create those items in a certain order to have them display the way they like,<br>i.e. bar image first, and graph image second.</blockquote><div>
<br>
I have thought about this idea too. But parent-child relation in
qwidget is slightly different that qobjects. If a widget is visually
child of any other qwidget, then only we can make that type of
realtionship.<br>
I dont know, if in future we would want to implement that thing or
not(may be a reality, in case something like textlabel in Tablemeter),
but that is not the substitute of what I wanted here.<br>
And yes, we can introduce something like Z ordering in meters.<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;"><br>My general thought on how this will work is in this fashion:<br>1) Meter connects to a Sensor, which has some default interval for reporting
<br>data<br>2) Sensor reports new data to Meter using qt signals/slots<br>3) Meter redraws/refreshes its display when it received data from Sensor<br>4) Meter waits while there is no data to change(saving cpu usage by not
<br>redrawing, unlike how SK currently is implemented)<br><br>No need for a separate interval for Meters.</blockquote><div>What
about the cases, in which data changes every millisecond (cpu load)?
sensor can have only one interval, and two meters want to refresh in
different intervals? We need to have meter update interval.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On a side note, since Meters will be qwidgets, they will have to be able to<br>
handle events such as mouse clicks to replace the current clickArea<br>functionality, and keyboard presses to replace the keyPressed functionality.</blockquote><div>I am replacing that as I am converting meter to qwidgets.
<br>
</div></div><br>
One more idea came into my mind. If we replace the current design of
one karambaWidget which encompasses all meters to independent meters?<br>
Right now, faked transparency is achieved by krootpixmap. mouse
interaction is still to karamba theme. If we separate out meters, then
we can have a real desktop instead of karambaWidget. And I also dont
think that this is difficult to do. This will also allow users to move
meters independently to where they wish ( but they can be grouped
together still)!<br>
<br>
Old design of karamba is not the answer to current requirements. That karamba was limited, we dont want that now.<br>
Design should be future perfect. At that requires that needs should be directly mapped to design. That means.....<br>
If two instance of sensor does the same thing, there is no meaning in
instantiating that again and again whatever the future may require! <br>
I have given enough possibilities which can create trouble with old karamba design.<br>
<br>
<br>