[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: [Panel-devel] Connection of Sensor and Meter
From: Vinay Khaitan <vkhaitan () gmail ! com>
Date: 2005-09-20 5:57:52
Message-ID: 56c5347705091922573e7125fc () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi,
Having a parent/child relationship between meters sounds like just another
> way
> to do what we are already doing according to your example. Currently
> people
> create those items in a certain order to have them display the way they
> like,
> i.e. bar image first, and graph image second.
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.
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.
And yes, we can introduce something like Z ordering in meters.
> My general thought on how this will work is in this fashion:
> 1) Meter connects to a Sensor, which has some default interval for
> reporting
> data
> 2) Sensor reports new data to Meter using qt signals/slots
> 3) Meter redraws/refreshes its display when it received data from Sensor
> 4) Meter waits while there is no data to change(saving cpu usage by not
> redrawing, unlike how SK currently is implemented)
>
> No need for a separate interval for Meters.
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.
> On a side note, since Meters will be qwidgets, they will have to be able
> to
> handle events such as mouse clicks to replace the current clickArea
> functionality, and keyboard presses to replace the keyPressed
> functionality.
I am replacing that as I am converting meter to qwidgets.
One more idea came into my mind. If we replace the current design of one
karambaWidget which encompasses all meters to independent meters?
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)!
Old design of karamba is not the answer to current requirements. That
karamba was limited, we dont want that now.
Design should be future perfect. At that requires that needs should be
directly mapped to design. That means.....
If two instance of sensor does the same thing, there is no meaning in
instantiating that again and again whatever the future may require!
I have given enough possibilities which can create trouble with old karamba
design.
[Attachment #5 (text/html)]
<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>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic