Monitor plugins Was: Xfce task manager prototype

[Mike Massonnet]

Hey,

Took a while to answer since neither I am sure how the build should look like.

2010/4/30 Florian Rivoal <frivoal at gmail.com>:
> On Wed, 28 Apr 2010 22:03:59 +0200
> Mike Massonnet <mmassonnet at gmail.com> wrote:
>
>> 2010/4/26 Landry Breuil <landry.breuil at gmail.com>:
>> > On Mon, Apr 26, 2010 at 3:05 PM, Mike Massonnet
>> > <mmassonnet at gmail.com> wrote:
>> >> Something else has made noise more than once, the possibility to
>> >> share code between the panel plugins. Currently we have a system
>> >> monitor, a netload plugin, and a cpugraph (if I'm not mistaken.)
>> >> Do you have a call on this?
>
>> > Iirc frivoal talked about that once he'd had finished what he
>> > planned for cpugraph. Currently systemload, netload and wavelan
>> > plugins don't see any development as they are more or less feature
>> > complete, but they each have their own os-dependent code. All that
>> > should really be in a single panel plugin, or at least separate
>> > plugins but sharing a common lib to access system values.
>
>> @frivoal: If the new project should be created, I suggest it to be
>> named after “monitor” f.e. xfce4-system-monitors-plugin.
>
>
> Indeed, I am still thinking of a merger project. For CPU-graph, I am
> pretty much done with what I wanted to do. I haven't made a new release
> yet, as translations are not ready yet, and there are still a bit of
> work on *BSD compatibility, but other than than, I am pretty much where
> I wanted to be.
>
> As for the merger project, I'd very much like to do this, but as I
> can't work full-time on xfce, it is likely to take a while, and in any
> case, won't be ready for xfce 4.8. While the various monitors are
> indeed more or less "featyre complete", they are not bug-free, so, in
> order to make 4.8 a solid release, I was thinking of doing bug-fixing on
> them until 4.8 is out, and switch to the merger project after that.
>
> Since I am now mostly done with cpu-graph, I'll switch to fixing
> another of the monitors. Any opinion on which should take priority?

Well, I didn't make a tour in the list of bugs, but I generated a
Bugzilla report[0] to point at all the components in question. What I
believe is that it will be a waste of time to fix bugs in order to get
them stable -- they all work, don't they? -- but it will give you the
opportunity to have a close look at more code which can then give you
a good idea how to start with the merger. If you are confortable with
this, sure why not :-)

[0] http://tinyurl.com/32hq277

I listed the cpufreq and battery plugins as well in the report.
However I don't believe the cpufreq to be as useful as it used to be,
strong Linux hackers already mentionned that the default gorvernor is
the best so at least it can be useful to display the current CPU
frequencies. And for the battery plugin some users may still use the
ACPI version.

Of course not all of these plugins have to be part of the merger, for
example the sensors plugin has an active maintainer. I had say
starting with the disk i/o, network and system information is a good
start.

>> > A common library for that would be nice, and libgtop is far from
>> > working fine on !linux. Its code is not really understandable, and
>> > the doc is nothing more than the autogenerated one.
>> > Isn't it possible to merge all those in a single package, with a
>> > common lib/api for xfce4-taskmanager and the
>> > 'put-all-monitors-together'-panel-plugin ?
>
>> I really don't want to see any kind of shared library and very likely
>> recommend the use of a static library. So that is a no for sharing
>> code between this possible new project and the existing task manager;
>> unless someone knows a solution to use a static library cross git
>> components. Maybe the git-sub-modules-what-not can be used to build
>> stuff from the static lib in the task manager... We will have to see!
>
> Part of the merger project would likely result in either fixing
> libgtop, or more likely in writing an alternative, based on bits of the
> current monitor plugins. As I haven't started, I don't have (yet) a
> strong opinion on how it should be done, but what do you have against a
> shared library? It seems to me that especially if it is going to be
> used in several projects (monitors, task manager), a shared library
> would make a lot of sense. And if libgtop is as broken as Landry said,
> projects beyond xfce might find it handy.

I only have a small opinion on why not use any yet-another-small
library. You are going to provide plugins that all depend on a part of
the library, in this case why not pull the necessary code in the
binary in order to get it loaded even faster. Loading/unloading
libraries comes at a (small) price. Other projects can always copy the
needed code or (if there is) the static library entirely. I have in
mind that plugins for the panel must load as fast as possible.

Linking to libgtop is IMO a bad idea because it will pull an extra
library which I am trying to avoid for the task manager. My local git
tree depends only on GTK+ and this will make it possible to adopt it
on other lightweight (or heavy) desktops. Currently there are several
forks of it, lxtask, gtaskmanager and maybe others.

So in the end, I have my reasons not to link against an external
library, but your mileage may vary :-) And fixing (does it really need
to?) libgtop is the best one can do.

>  - Florian



-- 
Mike