--===============0379349302== Content-Type: multipart/alternative; boundary="----=_Part_17001_17564173.1126677662414" ------=_Part_17001_17564173.1126677662414 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 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= =20 > 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=20 widget update, is it? That looks to me very simple and certainly useful.=20 See, the data is always there with sensor for retrieving anytime. If meter= =20 doesn't want to update its gui, it will simply=20 ignore the sensor's signal. If it wants to update gui later, it can get the= =20 value from sensor from function data() manually. What is the problem with= =20 it? or it may copy the data, which comes with signal, to its private=20 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= =20 it mean? Meter itself would be QWidget hence GUI. so there is no as such an= y=20 counterpart. > oi vey. we need to have a discussion about what plasmoids are going to=20 > look > > like. >=20 > 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= =20 > 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=20 > they > are written. >=20 > This could be a better avenue that would allow a more flexible approach= =20 > 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. >=20 It doesn't raise the bar than current theme format IMHO. The people coding= =20 would be a programmer of certain language. So scripting style should suit t= o=20 them. And layout geometry stuff, it is for multimeter. They can get remain= =20 away from multimeter in initial stages. Although Using layouts even for normal meter composition is also tempting.= =20 But usefulness of layout over "raising the bar" looks to me deciding in=20 favour of layout. Vinay Khaitan ------=_Part_17001_17564173.1126677662414 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
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 GU= I
counterpart depending on what the theme developer specifies. &nbs= p;Probably
implemented via slots/signals.
> 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 "ra= ise the bar" for people starting out
since they would need to understand these concepts before making
the= mes/plasmoids.