From kde-panel-devel Fri Sep 16 07:49:00 2005 From: Vinay Khaitan Date: Fri, 16 Sep 2005 07:49:00 +0000 To: kde-panel-devel Subject: [Panel-devel] Design file of SK Message-Id: <56c5347705091600495faaec64 () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=112685698923520 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0630234452==" --===============0630234452== Content-Type: multipart/alternative; boundary="----=_Part_27332_7200345.1126856940009" ------=_Part_27332_7200345.1126856940009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I want that people keep track of design of SK in a file.=20 I have put a file DESIGN_DISCUSS( should be renamed to DESIGN) . Please kee= p=20 track of design(to be implemented) ideas in that file. I have put some sensor specific ideas into that. It follows here. Please comment. * Sensors derived classes needs to be made singleton. Why do we need 2=20 cpusensor object? When values returned by them would be the same? Exceptions:- The sensors, which need some parameter setting, would need to= =20 be instantiated by meters, which need them. *Update Interval:- All Sensors dont need to set update interval at all. The= =20 sensors like tasksensor, dont even need to update in fact. They would update data, only when system indicates that a task is changed. In fact, those sensors need update interval, whose data change is not=20 signaled by system. So they need to obtain current data at specific interval. But things like tasksensor, changing after certain interval of actual chang= e=20 by system, would look very odd. So they would change when system indicates. CPUSensor Will have default values for update. If the theme writer specifie= s=20 any meter update interval, meter would set the update interval to be minimum of all meters connected. Meters would refresh only when they want, although they will always have th= e=20 updated data. * A Look at all sensors:- CPUsensor:- discussed already about updateInterval . needs singleton=20 pattern. No parameters needed. DiskSensor:- UpdateInterval just like CPUSensor. needs singleton pattern.= =20 MOUNTPOINT parameter not needed. It will return values of all partition/mountpoint. MemorySensor:- Just like cpusensor. NetworkSensor:- updateInterval like CPU. Device parameter not needed. Need= =20 to be singleton. NoAtun:- Singleton, no update needed. It will update only when Noatun=20 changes (through signal) Program:- Non Singleton because of PROGRAM and other parameters.=20 UpdateInterval has no meaning. Sensor:- just like cpusensor Textfile:- non-singletom. No update interval. Updates if textfile=20 changes(through may be FAM possibly, or when meter wants) Time:- cpusensor like. uptime:- cpusensor like. Xmms:- noatun like. Sometimes mailing lists becomes inefficient because of difference in time o= f=20 world zones :( Someone sends a mail to list in daytime, which is my night time. and then= =20 vice-versa. So if a topic requre 5 mail exchanges, it would require 5 days! very bad.= =20 Slows down efficiency drastically. Vinay Khaitan ------=_Part_27332_7200345.1126856940009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I want that people keep track of design of SK in a file.
I have put a file DESIGN_DISCUSS( should be renamed to DESIGN) . Please keep track of design(to be implemented) ideas in that file.

I have put some sensor specific ideas into that. It follows here.
Please comment.

* Sensors derived classes needs to be made singleton. Why do we need 2 cpusensor object? When values returned by them would be the same?
  Exceptions:- The sensors, which need some parameter setting, would n= eed to be instantiated by meters, which need them.

*Update Interval:- All Sensors dont need to set update interval at all. The sensors like tasksensor, dont even need to update in fact.
            &nb= sp;     They would update data, only when system indicates that a task is changed.

            &nb= sp;     In fact, those sensors need update interval, whose data change is not signaled by system. So they need to obtain
            &nb= sp;     current data at specific interval.
            &nb= sp;     But things like tasksensor, changing after certain interval of actual change by system, would look very odd.
            &nb= sp;     So they would change when system indicates.

            &nb= sp;     CPUSensor Will have default values for update. If the theme writer specifies any meter update interval, meter would
            &nb= sp;     set the update interval to be minimum of all meters connected.
            &nb= sp;     Meters would refresh only when they want, although they will always have the updated data.

* A Look at all sensors:-

    CPUsensor:-  discussed already about updateInterval= . needs singleton pattern. No parameters needed.
    DiskSensor:- UpdateInterval just like CPUSensor. needs singleton pattern. MOUNTPOINT parameter not needed. It will return values of
            all part= ition/mountpoint.
    MemorySensor:- Just like cpusensor.
    NetworkSensor:- updateInterval like CPU. Device paramete= r not needed. Need to be singleton.
    NoAtun:- Singleton, no update needed. It will update onl= y when Noatun changes (through signal)
    Program:- Non Singleton because of PROGRAM and other&nbs= p; parameters. UpdateInterval has no meaning.
    Sensor:- just like cpusensor
    Textfile:- non-singletom. No update interval. Updates if textfile changes(through may be FAM possibly, or when meter wants)
    Time:- cpusensor like.
    uptime:- cpusensor like.
    Xmms:- noatun like.

Sometimes mailing lists becomes inefficient because of difference in time o= f world zones :(
Someone sends a mail to list in daytime, which is my night time. and then v= ice-versa.
So if a topic requre 5 mail exchanges, it would require 5 days! very bad. S= lows down efficiency drastically.

Vinay Khaitan
------=_Part_27332_7200345.1126856940009-- --===============0630234452== 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 --===============0630234452==--