On Fri, 2007-03-30 at 09:25 -0400, Dan Winship wrote: > Richard Hughes wrote: > > On Thu, 2007-03-29 at 18:31 -0400, David Zeuthen wrote: > >> Perhaps it's just easier to remove these from the org.fd.PM interface > >> then and tell ISV's to do... something else. I don't know. What's the > >> freedesktop.org story for this these days? How should an app reboot > >> the system? XMSP? Wasn't Dan Winship of Novell working on this? > > XSMP lets an app request a logout, but not a reboot/shutdown. In GNOME, > reboots and shutdowns are really handled by gdm, so currently if you > want to shutdown/reboot directly from the desktop (like the panel and > gnome-power-manager do), you have to use a secret gdm protocol to tell > gdm to reboot/shutdown after the current session, and then use XSMP to > tell gnome-session to log out without presenting a dialog to the user > (and then once gnome-session exits, gdm does what you told it to). > > XSMP is not really extensible, so if we want something better than this, > it would have to be via D-Bus anyway. I'd been thinking about eventually > having a standard D-Bus interface for the session manager, with Logout, > Reboot, and Shutdown commands. Putting those commands on a session > management interface would solve the objection some people had that > those commands should always be available even if you aren't running any > sort of power manager.
Sure. That would be good. I'm quite prepared to either deprecate the Shutdown and Restart methods, or just proxy them when GNOME and KDE both have a common session abstraction, but that could be a long time coming; No insult intended to anybody here. > > Ick. So completely different ways to this. Doing this via XMSP also > > breaks the InhibitManual semantics also, as then we have to inhibit the > > session using XMSP (somehow) just to stop a shutdown half-way through a > > partition resize. Complexity central. > > Well, but in that case you'd want to inhibit *logout* as well as > reboot/shutdown anyway, right? (Since logging out would kill X and > probably the partition-resizing app along with it.) So the session > manager needs to be involved somehow anyway. The easy way to do this > would be to have the power manager (or the partition-resizing app > itself) register as an XSMP client, and when it receives a logout > notification, cancel the logout and pop up a dialog explaining why. (Or > pop up an "are you sure blah blah blah" dialog and cancel or don't > cancel the logout accordingly.) That's the plan, although I admit I never quite understood the exact subtleties of XSMP, hence why it's not in g-p-m yet. > You're going to need the power manager to talk to the session manager > anyway, because if the power manager is handling o.f.PM.Shutdown, it's > probably going to want to implement it basically the same way g-p-m does > now (letting the session manager deal with the logout part), so that the > user gets logged out cleanly rather than just killing all his > processes. Yes, that fine as a long term plan, but I want something we can shove at ISV's and application developers really soon. I see *worst case* we have to proxy the method when the session abstraction comes about. Cheers, Richard. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
