[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: [Panel-devel] Sensors and Meters in SK
From: Pedro Suarez Casal <pedro.wotan () mundo-r ! com>
Date: 2005-09-11 2:40:25
Message-ID: 200509110440.26039.pedro.wotan () mundo-r ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> and what's an "AbstractEngine"? shouldn't that be "AbstractSensor"? "plasma
> engine" is broader in concept that just Sensors. for instance, while we
> could provide a Sensor driven model for libtaskmanager, it would really be
> a "round peg, square hole" sort of deal.
Well, I think I should review it before send it :). I was playing with the diagram \
after the meetup, and I changed that for myself, but it wasn't meant to have the \
meaning of an Engine. Sorry for that.
>
> > In this case, the only difference would be how Meters and Sensors are
> > connected. Instead of calling a method in the Sensor for creating the
> > connection, the Meter itself would create it.
>
> that would work, but IMHO not as well.the code path would be:
>
> Sensor emits a signal
> Meter requests the value for the Sensor
> Sensor returns the requested value
> Meter displays it
>
> with visitor, you'd just get:
>
> Sensor emits a signal with the value(s)
> Meter displays it
>
> if you wanted to keep the class dependency down to just "Meter knows of
> Sensor" then have Meter do the connecting of the Sensor signal to itself.
> or have a third class that does the connecting. i just don't see the need
> for the extra code paths that will be executed on _every update_ when we
> could simply do the "right connection" once per sensor/meter pair.
>
> furthermore, but letting the Sensor do the connecting, one doesn't have to
> expose any Sensor-specific API to Meter allowing for each Sensor to be as
> specialized as it feels the need for. and i suspect that Sensors will need
> more specialization than Meters will as Meters have a fairly well define
> purpose (show values to the user) while Sensors are far broader in scope.
>
Well, Observer pattern has two forms of implementation. That one, and other that is \
more similar to the "Visitor's way", wich with every update sends all data. Choose \
what you prefer, I think that isn't the problem. The problem is more related with \
"who connects with who", and that's what I tried to suggest, a different way for \
doing the connections. If you think the connections creator should be the Sensor, \
then I agree :)
> > This way Sensors could be used
> > with other elements different from Meters.
>
> sensors could still be used with elements other than meters. it would just
> be EASIER to use them with meters. however, one has to ask: how often will
> any sensor be used with something that isn't a meter? the answer will
> dictate how much that should influence the design. i'd look at superkaramba
> widgets, kicker applets, mac dashboard widgets, gdesklets and konfabulators
> for the answer.
>
> i really don't see the issue with saying "meters and sensors know about
> each other" and keeping the base classes for each very basic and simple. in
> fact, Sensor should be a QObject, Meter a QWidget. Sensor should only
> define the signal which carries a QVariant and perhaps the necessary
> infrastructure for the pattern used to connect Sensors and Meters; Meters
> should only have the means necessary to connect with Sensors and a standard
> (set of?) slots to accept the Sensor new value(s) signal.
>
> hell if you _really_ wanted to you could make Meter an interface only and
> require multiple inheritance (e.g. MyMeter : public QWidget, public
> Plasma:Meter) at which point a sensor could be used with "anything".
> granted MI isn't the prettiest thing, but it may be just what the doc
> ordered here. my primary concern is scripting languages that don't allow
> for MI, such as Ruby. though Ruby could probably use mix ins instead to
> include the MyMeter interface. still, i'd be a bit concerned about
> requiring some sort of multiple inheritence / implementation scheme and not
> bother.
We thought meters as we know them in SK would disappear. For instance, in SK a text \
label is a Meter, and this could change in the future. That's why we decided to \
abstract that.
But anyway, you are right, it could be done using a sort of MI depending on the \
language.
[Attachment #5 (text/html)]
<html><head><meta name="qrichtext" content="1" /></head><body \
style="font-size:11pt;font-family:Sans Serif"> <p><span style="color:#008000">> \
and what's an "AbstractEngine"? shouldn't that be \
"AbstractSensor"? "plasma</span></p> <p><span \
style="color:#008000">> engine" is broader in concept that just Sensors. for \
instance, while we</span></p> <p><span style="color:#008000">> could provide a \
Sensor driven model for libtaskmanager, it would really be</span></p> <p><span \
style="color:#008000">> a "round peg, square hole" sort of \
deal.</span></p> <p></p>
<p>Well, I think I should review it before send it :). I was playing with the diagram \
after the meetup, and I changed that for myself, but it wasn't meant to have the \
meaning of an Engine. Sorry for that.</p> <p></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#007000">> > In this case, the only difference would be \
how Meters and Sensors are</span></p> <p><span style="color:#007000">> > \
connected. Instead of calling a method in the Sensor for creating the</span></p> \
<p><span style="color:#007000">> > connection, the Meter itself would create \
it.</span></p> <p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> that would work, but IMHO not as well.the code \
path would be:</span></p> <p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> Sensor emits a signal</span></p>
<p><span style="color:#008000">> Meter requests the value for the \
Sensor</span></p> <p><span style="color:#008000">> Sensor returns the requested \
value</span></p> <p><span style="color:#008000">> Meter displays it</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> with visitor, you'd just get:</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> Sensor emits a signal with the \
value(s)</span></p> <p><span style="color:#008000">> Meter displays it</span></p>
<p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> if you wanted to keep the class dependency down \
to just "Meter knows of</span></p> <p><span style="color:#008000">> \
Sensor" then have Meter do the connecting of the Sensor signal to \
itself.</span></p> <p><span style="color:#008000">> or have a third class that \
does the connecting. i just don't see the need</span></p> <p><span \
style="color:#008000">> for the extra code paths that will be executed on _every \
update_ when we</span></p> <p><span style="color:#008000">> could simply do the \
"right connection" once per sensor/meter pair.</span></p> <p><span \
style="color:#008000">></span></p> <p><span style="color:#008000">> \
furthermore, but letting the Sensor do the connecting, one doesn't have to</span></p> \
<p><span style="color:#008000">> expose any Sensor-specific API to Meter allowing \
for each Sensor to be as</span></p> <p><span style="color:#008000">> specialized \
as it feels the need for. and i suspect that Sensors will need</span></p> <p><span \
style="color:#008000">> more specialization than Meters will as Meters have a \
fairly well define</span></p> <p><span style="color:#008000">> purpose (show \
values to the user) while Sensors are far broader in scope.</span></p> <p><span \
style="color:#008000">></span></p> <p></p>
<p>Well, Observer pattern has two forms of implementation. That one, and other that \
is more similar to the "Visitor's way", wich with every update sends all \
data. Choose what you prefer, I think that isn't the problem. The problem is more \
related with "who connects with who", and that's what I tried to suggest, a \
different way for doing the connections. If you think the connections creator should \
be the Sensor, then I agree :)</p> <p></p>
<p><span style="color:#007000">> > This way Sensors could be used</span></p>
<p><span style="color:#007000">> > with other elements different from \
Meters.</span></p> <p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> sensors could still be used with elements other \
than meters. it would just</span></p> <p><span style="color:#008000">> be EASIER \
to use them with meters. however, one has to ask: how often will</span></p> <p><span \
style="color:#008000">> any sensor be used with something that isn't a meter? the \
answer will</span></p> <p><span style="color:#008000">> dictate how much that \
should influence the design. i'd look at superkaramba</span></p> <p><span \
style="color:#008000">> widgets, kicker applets, mac dashboard widgets, gdesklets \
and konfabulators</span></p> <p><span style="color:#008000">> for the \
answer.</span></p> <p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> i really don't see the issue with saying \
"meters and sensors know about</span></p> <p><span style="color:#008000">> \
each other" and keeping the base classes for each very basic and simple. \
in</span></p> <p><span style="color:#008000">> fact, Sensor should be a QObject, \
Meter a QWidget. Sensor should only</span></p> <p><span style="color:#008000">> \
define the signal which carries a QVariant and perhaps the necessary</span></p> \
<p><span style="color:#008000">> infrastructure for the pattern used to connect \
Sensors and Meters; Meters</span></p> <p><span style="color:#008000">> should only \
have the means necessary to connect with Sensors and a standard</span></p> <p><span \
style="color:#008000">> (set of?) slots to accept the Sensor new value(s) \
signal.</span></p> <p><span style="color:#008000">></span></p>
<p><span style="color:#008000">> hell if you _really_ wanted to you could make \
Meter an interface only and</span></p> <p><span style="color:#008000">> require \
multiple inheritance (e.g. MyMeter : public QWidget, public</span></p> <p><span \
style="color:#008000">> Plasma:Meter) at which point a sensor could be used with \
"anything".</span></p> <p><span style="color:#008000">> granted MI isn't \
the prettiest thing, but it may be just what the doc</span></p> <p><span \
style="color:#008000">> ordered here. my primary concern is scripting languages \
that don't allow</span></p> <p><span style="color:#008000">> for MI, such as Ruby. \
though Ruby could probably use mix ins instead to</span></p> <p><span \
style="color:#008000">> include the MyMeter interface. still, i'd be a bit \
concerned about</span></p> <p><span style="color:#008000">> requiring some sort of \
multiple inheritence / implementation scheme and not</span></p> <p><span \
style="color:#008000">> bother.</span></p> <p></p>
<p>We thought meters as we know them in SK would disappear. For instance, in SK a \
text label is a Meter, and this could change in the future. That's why we decided to \
abstract that. </p> <p></p>
<p>But anyway, you are right, it could be done using a sort of MI depending on the \
language.</p> <p></p>
<p></p>
</body></html>
_______________________________________________
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