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