[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: "Aaron J. Seigo" <aseigo () kde ! org>
Date: 2005-09-09 13:01:50
Message-ID: 200509090701.51177.aseigo () kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/signed)]
On Thursday 08 September 2005 11:33, Vinay Khaitan wrote:
> > Sensor sensor = CPUSensor this;
> > Meter meter = BarMeter this sensor;
>
> This sounds to me like backward step. Our idea is to separate meters and
> sensors althogether.
that would be somewhat daft since the point of "sensors" and "meters" is, in
the common case, to use meters to show the output of sensors. so that common
pattern of usage should be optimized for. this isn't about hardwiring them
together to the exclusion of all other possibilities, but providing an easy
and future-proof path to doing what will certainly be the most common
activity: connecting sensors to meters.
> they dont know each other (this is what matt
> broadstone like to call OO design). There are reasons for it. Let's take an
> example of cpusensor on multi-cpu system. It returns , let's say,
> QMap<QString, int> and contents are....
> cpu0->700
> cpu1->2400
> Now, bar->acceptSensor(cpusensor) would show cpu0 or cpu1 ? It wil have to
> skip it! but we want that bar should show cpu0 .
not at all. there are several ways around this. one is to use:
QVariant::QVariant ( const QMap<QString, QVariant> & val )
and require that meters accept a QMap as a possible input. of course this
leaves the "one sensor with N outputs distributed across N meters" so you can
have 3 CPUs and set up one bar per CPU. in which case, i'd say this calls for
a "multimeter" which takes a QMap and displays one output widget per value in
the map. which solves that scenario neatly. internally the multimeter would
take individual meters and manage them "by hand" internally, but again this
would encapsulate this behaviour in one class instead of forcing applet
developers to repeat this task over and over.
another thing to keep in mind is that there is nothing that says one can't,
for the odd case, do everything by hand as you describe. so i could hook up a
meter to signals internal to my applet that were emitted upon some custon
event if i really wanted; heck one should be able to manually call
meter->setValue(foobar); but common things (connecting a sensor to a meter)
should be simple to accomplish and not require deep knowledge of
implementation details.
> The important thing is not what is the type of return value, but how the
> return value is arranged to show system info. We dont know the pattern in
> advance at all. The pattern of return is totally dependent on sensor(sensor
> can even be a plugin).
> The same problem is there with sensor->showInMeter(Meter*) . The meters
> could be of different variety, which we dont know in advance(when given as
> plugin).
this is why one sets down some basic patterns during design. patterns rarely
emerge on their own, they are usually set down by the people designing the
software.
> I hope I am clear. OO design has amazing benefits.
erm. this is hardly "OO design". what you're doing is saying there is no
design or pattern, so leave everything up to the applet writers. to wit, it's
the opposite of "design". =/
the biggest down side to doing it the "connect everything yourself" approach
is that by exposing that level of detail in each applet, if we ever decide to
change how sensors or meters work (e.g. wish to add some additional
functionality to them, or change the input or output mechanisms) then every
single applet that depends on them will have to reflect those changes as
well.
it also means that if an applet writer wishes to change the meter in use or
the sensor in use then they have to change more code than necessary. unless,
of course, it's done the same way for every sensor and meter in which case it
should be abstracted away.
applets should be shielded from the implementation details as much as possible
and the sensors and meters should be able to be plugged in together as simply
as possible. using a visitor type pattern keeps the implementation specific
details as close to the implementation as possible in this case.
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
[Attachment #5 (application/pgp-signature)]
_______________________________________________
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