From kde-panel-devel Wed Sep 14 06:01:02 2005 From: Vinay Khaitan Date: Wed, 14 Sep 2005 06:01:02 +0000 To: kde-panel-devel Subject: Re: [Panel-devel] Design of Sensor and meters Message-Id: <56c5347705091323014608dc38 () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=112667770428167 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0379349302==" --===============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.

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 "ra= ise the bar" for people starting out
since they would need to understand these concepts before making
the= mes/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 t= o me deciding in favour of layout.

Vinay Khaitan
------=_Part_17001_17564173.1126677662414-- --===============0379349302== Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline _______________________________________________ Panel-devel mailing list Panel-devel@kde.org https://mail.kde.org/mailman/listinfo/panel-devel --===============0379349302==--