Re: Session saving & 2.26.0

[Vincent Untz <vuntz gnome org>]

Le mardi 24 mars 2009, à 23:24 -0400, Matthias Clasen a écrit :
> On Mon, Mar 16, 2009 at 10:20 AM, Vincent Untz <vuntz gnome org> wrote:
> > Le lundi 16 mars 2009, à 10:36 +0000, Lucas Rocha a écrit :
> >> Waiting for 2.26.1 and disabling session saving on 2.26.0 sounds like
> >> the sanest option.
> >
> > We have a deal, then.
> 
> I see that you have committed all your changes without further
> discussion to the stable branch now. I don't think that changes of
> this magnitude are compatible with our established policy for stable
> branches.

It was the plan that was agreed -- try to fix things for 2.26.1. If it
turns out all this is broken, we can still revert things, or
retroactively branch for 2.26.

> Anyway, I'd like to thank you for breaking up the huge patch
> into a series of reviewable commits. Looking over them, I can accept
> almost all of them as  bug fixes of some sort, but this one stands out
> as breaking the new gnome-session design:
> 
> 2009-03-25  Vincent Untz  <vuntz {at} gnome.org>
> 
> 	Allow an interacting app to cancel the logout.
> 
> 
> Can you justify that change ?

Sure.

This is basically only happening when a client is done with interacting
during logout; note that an interacting client creates a JIT
logout inhibitor.

Basically, you already have the possibility to cancel the logout from
the inhibit dialog (so I'm not quite sure why you're saying this breaks
the current design). It turns out that some clients also display a
button to cancel logout when they're interacting (gedit, for example).

We could say that it's useless to support cancelling both via the
inhibit dialog and via the clients interaction dialogs (this would of
course ignore the fact that we don't control if apps are displaying a
button to cancel logout -- ie, XSMP compatibility).

Even without saying this, there are some use cases where this can be
useful for the user: if the user starts logging out while on workspace X
and the application blocking logout is on workspace Y, then the inhibit
dialog will be on workspace X and the application dialog will be on
workspace Y. Thanks to the inhibit dialog, the user knows that the
blocking app is $APP and looks on other workspaces to find it. When the
user switches to workspace Y, he might find out that he actually doesn't
want to log out. Why force him to go back to workspace X if the app can
let him cancel the operation?

Vincent

-- 
Les gens heureux ne sont pas pressés.