On pá 30. března 2007, Brian J. Tarricone wrote: > On Fri, 30 Mar 2007 23:19:26 +0200 Lubos Lunak wrote: > > I thought supporting an opinion did not require one to repeat it, but > > if you > >want: Shutdown/Reboot are basic functionality but power management > >features are an add-on that not everybody may be interested in having > >(see above for my feedback on that part). Since a DBUS interface > >cannot be split that makes the whole org.fd.PM interface optional and > >therefore Shutdown/Reboot should not be part of it. > > There's nothing stopping someone from implementing a daemon that > handles org.fd.PM and only supports the Shutdown/Reboot methods. For > the CanStandby/CanSuspend/CanHibernate methods, just return FALSE. For > the Standby/Suspend/Hibernate methods, return the NoHardwareSupport > error. For GetPowerSaveStatus and GetBatteryState, return FALSE. If > other methods are added, I'm sure dummy non-implementations can be > added for people who really care about saving 200k of RAM.
Or, since the two things are[*] independent, they can have independent interfaces and supporting either only one of them or both of them is simple. No dummies needed. [*] Unless you have another reason why shutdown/reboot should go together with PM besides the Inhibit functionality, which for shutdown/reboot exists in the form of session management. (In fact, thinking of it right now, perhaps even having Inhibit in PM interface is not quite right? A DVD burner app strictly speaking probably doesn't care about the machine being suspended, it just wants to keep the DVD device until it's finished and the machine shouldn't shutdown with the DVD device being busy - so in fact maybe it should be HAL preventing suspend in such case. You can have Inhibit for the screen, which is a bit like keeping the screen, but that has nothing to do with shutdown/reboot again. But maybe this is overengineering it already and irrelevant to the 'should shutdown/reboot be part of PM' topic anyway.) > At any rate, you're complaining about a specific implementation being a > memory hog. Take your beef to the authors of that software. The > org.fd.PM interface is mostly orthogonal. > > Of course, the ridiculously ornery among us can just open a terminal > and type 'sudo poweroff'; they won't even run g-p-m or kpowersave or > whatever, and any apps they run won't be able to make use of the > advanced features org.fd.PM can offer. Your average user who would > benefit from org.fd.PM features won't care about a meg or two of RAM > gone missing. This is not about g-p-m being a memory hog or not, this is about the principle. Everything has its cost and you want to make a power management daemon compulsory even just for shutdown. Okay. Next week somebody proposes a WIFI access daemon should be made compulsory for some reason, because, after all, your average user will benefit from it and who cares about a meg or two. Actually two or four, by now, things add up. Do I need to continue to the next month and later and add up more? I'd prefer not to, I feel strongly tempted to point out some flamewar material. Let's just say that there are users who also care about this, ok? Besides, the main reason is that having shutdown/reboot seen as a part of power management functionality simply seems technically wrong. -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http//www.suse.cz _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
