Re: Session DBus protocol

2010-10-25 Thread Ryan Lortie
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

2010-10-25 Thread Matthias Clasen
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

2010-10-25 Thread Lennart Poettering
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

2010-10-25 Thread Richard Hughes
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

2010-10-25 Thread Ryan Lortie
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

2010-10-25 Thread Piñeiro
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

2010-10-25 Thread Bastien Nocera
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