Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager

[Danny Kukawka <danny kukawka web de>]

On Thursday 13 April 2006 21:52, David Zeuthen wrote:
> (dropping desktop-devel-list from the Cc)

Why?

> On Tue, 2006-04-11 at 19:13 +0200, Danny Kukawka wrote:
> > Btw. I don't understand: What's the problem with a system daemon (with a
> > well defined DBUS-Interface, with a well defined default policy, without
> > need a session daemon) specialized to powermanagement. You can use
> > provided functions, but you don't need to use all available if you don't
> > need them in g-p-m. The daemon is _complete_ desktop _independent_, I
> > think this was the whish of Davyd Madeley (* A daemon with no GTK+
> > dependance that would be suitable for cross-desktop use).
>
> Desktop independency for the sake of.. well desktop independency... is
> just pretty point-less.

Sorry, I don't understand what you try to tell me.

> Here are *some* of the problems
>
>  2. It's completely stupid to read system wide settings from a different
>     location than per-user settings. Code duplication is bad.

I don't see this problem. The deamon can read his settings from one place and 
can get changed via the dbus-interface from any connected client. It's 
complete uninteresting for the client from where the daemon get his settings 
and also complete uninteresting for the daemon from where the client read his 
settings. There is nothing stupid.

>  3. Having a system-wide daemon encourages very silly things
>     - read plain text system wide settings from /etc instead of the
>       default area of your desktop configuration system - what happens
>       when your desktop configuration grows an LDAP backend?

Where is the problem? I can't see here any problem ... see above.

>     - do completely silly things like grepping the process list and
>       refuse to suspend e.g. when a process named "mplayer", "totem"
>       etc. is running

This is IMO not really the primary job of the deamon. The client can do this 
also. The benefit: you don't need to do this in the daemon if there is no 
client which need this function. In case of KPowersave for example we do this 
in the client and also only if the user enable it and edit the, for the user 
specific, blacklist. 

And by the way: there are really more elegant methodes to get information 
about running processes than 'grepping the process list' and if it maybe make 
sense to do this in the deamon - I see no problem to implement this.

>  4. What if GNOME wants a crack-rock interface in the system daemon and
>     the KDE don't want this because they don't like so many options?

Hey, this only a argument to stop all targeted discussion. Take a look at 
NetworkManager or your own project: HAL. Why do you think there is no way to 
develop a project together - KDE and GNOME guys? No comment. 

Btw. why do you think KDE developers would have problems with many options? 
Sounds crazy. 

>  5. Splitting g-p-m into more than one process will most likely just
>     complicate the code and introduce bugs. The interface is *not*
>     simply "upload settings from gconf to system daemon" since you
>     want to popup dialogs from time to time.

I know the code. Btw. nobody said: split g-p-m into more than one process. We 
suggested to share code between the desktops and use _one_ _common_ _cross_ 
_deskop_ _daemon_ for powermanagement. 

> >  This would be a win-win situation for all desktops.
>
> It's great when KDE and GNOME can share specs and software.
>
> However, this is kinda an area where we may be too different.

Sorry, but this is a point I don't understand. Have you ever take a look at 
the current solution on KDE or on powersave or KPowersave? I taked a look at 
g-p-m while integration on SUSE and I don't see why you think KDE and GNOME 
are too different to work together.

Don't get me wrong, but this all sounds for me a littlebit as if there is 
always only one way to share projects and code between the desktops - if it 
is developed for (by) GNOME (developers) (see for example NetworkManager). 
I'm maybe wrong, but if so: this is sad, isn't it?

Maybe there would be a way to discuss what is possible instead of what is 
_maybe_ not possible or problematic. If there are people which are interested 
in such a discussion: let me know.

Cheers,

Danny