Re: Session DBus protocol
On Mon, 2010-10-25 at 20:16 -0400, Matthias Clasen wrote: > I fail to see any difference ?! > All this is already happening with the way things currently are... Two situations combined to confuse me: 1) I guess we don't have enough bugs because I've never seen the current "you have apps not responding" dialog. 2) I only read the spec which doesn't mention that this might exist. Matthias set me straight on IRC. In short, I actually have absolutely no complaints about how it works now. Please disregard. :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Session DBus protocol
On Mon, Oct 25, 2010 at 4:01 PM, Ryan Lortie wrote: > hi, > > Vincent and I are sitting on a couch here at UDS reviewing the DBus > protocol used by gnome-session. > > I am interested in adding support to GtkApplication. > > My biggest concern is that the "emit signal and wait 1 second" approach > for checking which clients want to stop the logout from happening is > really bad. > > 1) Some clients might miss the deadline (if they are swapped, or the > system is really bogged down). Data loss here. 1 second is really a long time, if clients don't get around to responding within that time, chances are the user will have power-cycled the machine before they get around to responding... Also note that clients don't really have to wait until the QueryEndSession signal, they can just go ahead and place an Inhibitor when they start whatever uninterruptible operation they are doing. Finally, clients should not rely on save-at-session-end to prevent data loss, anyway. > 2) We may end up waiting for 1 second completely unnecessarily. In reality, you are going to have all clients responses within a few milliseconds. The 1 second timeout is really only going to trigger if you have a hung client. > I was wondering if maybe we could improve this interface to work more > like the following: > > 1) Clients that may want to block the logout register themselves with > gnome-session. > > 2) gnome-session does a AddMatch on their NameOwnerChanged so it can > tell if they exited (and unregister them). > > 3) At logout time, gnome-session makes a method call to each registered > app and *waits for a reply*. The length of time to wait should be > much longer than 1 second. Similar to the close button on > unresponsive windows, we could pop up a "this application is stuck" > dialog in that case allowing the user to kill it if they explicitly > choose to (but never assuming that no reply equals "no data to > save"). I fail to see any difference ?! All this is already happening with the way things currently are... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Session DBus protocol
On Mon, 25.10.10 16:01, Ryan Lortie (de...@desrt.ca) wrote: > hi, > > Vincent and I are sitting on a couch here at UDS reviewing the DBus > protocol used by gnome-session. > > I am interested in adding support to GtkApplication. > > My biggest concern is that the "emit signal and wait 1 second" approach > for checking which clients want to stop the logout from happening is > really bad. > > 1) Some clients might miss the deadline (if they are swapped, or the > system is really bogged down). Data loss here. > > 2) We may end up waiting for 1 second completely unnecessarily. > > > I was wondering if maybe we could improve this interface to work more > like the following: > > 1) Clients that may want to block the logout register themselves with > gnome-session. > > 2) gnome-session does a AddMatch on their NameOwnerChanged so it can > tell if they exited (and unregister them). > > 3) At logout time, gnome-session makes a method call to each registered > app and *waits for a reply*. The length of time to wait should be > much longer than 1 second. Similar to the close button on > unresponsive windows, we could pop up a "this application is stuck" > dialog in that case allowing the user to kill it if they explicitly > choose to (but never assuming that no reply equals "no data to > save"). Instead of having clients register with gnome-session I'd simply make them take a prefixed name on the bus. i.e. take "org.freedesktop.SessionInhibitor.Foobar" or so in an app "Foobar" (or include the PID or some other id as suffix). Then g-s should just watch all those prefixed names and log off as soon as none of them remain. And of course, add some dbus iface to the apps to make those apps quit (but I figure gtkapplication has that anyway?). In general I do believe we should use the dbus name registration for all those "registration" use cases, instead of having client-to-client registration. It's nicer for loose coupling (because clients can just take the name, and need no fallbacks/error checking in case g-s isn't around), and also more robust, and less duplication. And, last but not least, it allows for a greater amount of parallelization, which (with my systemd hat on) I can only welcome! Also, it minimizes the dbus function calls you have to do. On startup of all apps you just need to take a name, which only travels to the bus, and can be done asynchronously without expecting a reply. On shutdown of the apps, don't do anything. On session logout in many case you just need EnumerateServices, which needs to be sync. And to ping the individual clients you just need one sync msg each. I don't think it can get any better than that. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Session DBus protocol
On 25 October 2010 21:01, Ryan Lortie wrote: > I am interested in adding support to GtkApplication. In porting gnome-power-manager to GDBus, there was a lot of overlap between the new GtkApplication stuff, and the gnome-session functionality. It would certainly make sense to tie this together. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Session DBus protocol
hi, Vincent and I are sitting on a couch here at UDS reviewing the DBus protocol used by gnome-session. I am interested in adding support to GtkApplication. My biggest concern is that the "emit signal and wait 1 second" approach for checking which clients want to stop the logout from happening is really bad. 1) Some clients might miss the deadline (if they are swapped, or the system is really bogged down). Data loss here. 2) We may end up waiting for 1 second completely unnecessarily. I was wondering if maybe we could improve this interface to work more like the following: 1) Clients that may want to block the logout register themselves with gnome-session. 2) gnome-session does a AddMatch on their NameOwnerChanged so it can tell if they exited (and unregister them). 3) At logout time, gnome-session makes a method call to each registered app and *waits for a reply*. The length of time to wait should be much longer than 1 second. Similar to the close button on unresponsive windows, we could pop up a "this application is stuck" dialog in that case allowing the user to kill it if they explicitly choose to (but never assuming that no reply equals "no data to save"). Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changes for a11y applications, and AutostartCondition users
From: Bastien Nocera Adding gnome-accessibility-devel to this announce. > Heya, > > If you work on accessibility, you'll have to make a few changes for the > GSettings port. > > A new "AutoStartCondition" was added to gnome-session[1] which will > allow you to use a GSettings schema and key instead of a GConf key as > the condition for your application to get launched. > > A very simple change to at-spi for example: > -AutostartCondition=GNOME /desktop/gnome/interface/accessibility > +AutostartCondition=GSettings org.gnome.desktop.interface accessibility > > This will load and monitor the accessibility key in the > org.gnome.desktop.interface schema, instead of using GConf. You will > need a recent gnome-settings-daemon[2] to take advantage of this change. > > There will soon also be changes to the way GTK+ modules are loaded. > > Cheers > > [1]: https://bugzilla.gnome.org/show_bug.cgi?id=632724 > [2]: https://bugzilla.gnome.org/show_bug.cgi?id=632727 > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Changes for a11y applications, and AutostartCondition users
Heya, If you work on accessibility, you'll have to make a few changes for the GSettings port. A new "AutoStartCondition" was added to gnome-session[1] which will allow you to use a GSettings schema and key instead of a GConf key as the condition for your application to get launched. A very simple change to at-spi for example: -AutostartCondition=GNOME /desktop/gnome/interface/accessibility +AutostartCondition=GSettings org.gnome.desktop.interface accessibility This will load and monitor the accessibility key in the org.gnome.desktop.interface schema, instead of using GConf. You will need a recent gnome-settings-daemon[2] to take advantage of this change. There will soon also be changes to the way GTK+ modules are loaded. Cheers [1]: https://bugzilla.gnome.org/show_bug.cgi?id=632724 [2]: https://bugzilla.gnome.org/show_bug.cgi?id=632727 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list