On Mon, Apr 10, 2006 at 06:02:53PM +0200, Holger Macht wrote: > Ubuntu guys would also take it IMHO if there would be a gnome > client for it.
We'll take it if there's a gnome client /and/ it provides the same degree of useful functionality as g-p-m currently does. But I think we'll have the opportunity to discuss that later this week :) > And power management is something real complex. It's not just popping up > some notifications. It's definitely worth to reside in an own daemon like > NetworkManager which has root privileges and can do CPU frequency scaling, > throttling, harddisk adjustments, runtime device power management, battery > management, proper suspend implementation, CPU hotplugging and a lot more. Woah, hold on there. There's several issues involved here. Hal already provides mechanisms to trigger suspend, and it doesn't seem illogical to provide functionality like runtime device power management in there as well. If I select a wired network in NetworkManager, it makes sense for the device to be powered up. If it's going to be talking to hal to find out what capabilities the device has /anyway/, I think it makes sense for hal to be the basic interface for managing the power state. Otherwise NetworkManager has to start talking to the powersave daemon as well, which seems awkward. I'd much rather have a user-level powersave daemon that collates available information (such as asking Networkmanager whether any devices are up or not) and makes policy decisions that are enacted via hal than have policy management and enactment more tightly coupled. > Furthermore, we support all kind of systems, not only laptops. It's even > very useful on servers. The daemon also cares about shutting down or > suspend the system if battery runs low, even if no client is running. We > have a notification architecture that just works in every environment: Now, that's a slightly separate problem - that is, the fact that most DBus applications are focused on the "User logged in" case. David Zeuthen's been working on that, and I think there's a more elegant solution than "Run as root, and fall back to a default policy if there's no client". > - No client running but KDE installed: Daemon notifies user through > kdialog > - No client running but GNOME installed: Daemon notifies user > through zenityugly And I'm really not sure that the "No client" case is one that needs to be concentrated on - if people disable chunks of their desktop, then they're going to lose functionality. -- Matthew Garrett | [EMAIL PROTECTED] _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list