[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: [Panel-devel] Design of Sensor and meters
From: Vinay Khaitan <vkhaitan () gmail ! com>
Date: 2005-09-14 6:01:02
Message-ID: 56c5347705091323014608dc38 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> 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.
I think, you want to differentiate between meter data update and meter
widget update, is it? That looks to me very simple and certainly useful.
See, the data is always there with sensor for retrieving anytime. If meter
doesn't want to update its gui, it will simply
ignore the sensor's signal. If it wants to update gui later, it can get the
value from sensor from function data() manually. What is the problem with
it? or it may copy the data, which comes with signal, to its private
variable. Whatever you chose, it is simple. I like the second solution.
Or Have I misunderstood you?
"and then the meter can choose to update it's GUI counterpart "---what does
it mean? Meter itself would be QWidget hence GUI. so there is no as such any
counterpart.
> 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.
>
> 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.
>
It doesn't raise the bar than current theme format IMHO. The people coding
would be a programmer of certain language. So scripting style should suit to
them. And layout geometry stuff, it is for multimeter. They can get remain
away from multimeter in initial stages.
Although Using layouts even for normal meter composition is also tempting.
But usefulness of layout over "raising the bar" looks to me deciding in
favour of layout.
Vinay Khaitan
[Attachment #5 (text/html)]
<div><div><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Me neither. There should be a \
way that sensors can asynchronously update a<br> meter when it has new data, and then \
the meter can choose to update it's GUI<br>counterpart depending on what the theme \
developer specifies. Probably<br>implemented via \
slots/signals.</blockquote><div><br> I think, you want to differentiate between meter \
data update and meter widget update, is it? That looks to me very simple and \
certainly useful. <br>
See, the data is always there with sensor for retrieving anytime. If meter doesn't \
want to update its gui, it will simply <br> ignore the sensor's signal. If it wants \
to update gui later, it can get the value from sensor from function data() manually. \
What is the problem with it? or it may copy the data, which comes with signal, to
its private variable. Whatever you chose, it is simple. I like the
second solution.<br>
Or Have I misunderstood you?<br>
"and then the meter can choose to update it's GUI counterpart "---what
does it mean? Meter itself would be QWidget hence GUI. so there is no
as such any counterpart.<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;">> oi vey. we need to have a \
discussion about what plasmoids are going to look<br>
> like.<br><br>Personally I don't like the pseudo xml .theme file \
format. I feel that it<br>needs to be a bit more formal. Of \
course that is just for plasmoids that are<br>only implemented in this \
way. Other plasmoids will be written in ruby, <br>kjsembed, etc., that \
will have their own structure b/c of the language they<br>are written.<br><br>This \
could be a better avenue that would allow a more flexible approach \
than<br>traditional SK themes, but it may "raise the bar" for people \
starting out <br>since they would need to understand these concepts before \
making<br>themes/plasmoids.<br></blockquote></div>It doesn't raise the bar than \
current theme format IMHO. The people coding would be a programmer of certain \
language. So scripting style should suit to them. And layout geometry stuff, it is \
for multimeter. They can get remain away from multimeter in initial stages.<br>
Although Using layouts even for normal meter composition is also
tempting. But usefulness of layout over "raising the bar" looks to me
deciding in favour of layout.<br>
<br>
Vinay Khaitan<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