Has not yet replaced the existing log out applet

[Scott James Remnant (Canonical)]

Binary package hint: fast-user-switch-applet

The intrepid fast-user-switch applet combines the functionality of itself and the old log out applet.

On upgrades, it should move to the right-hand-side replacing the log out applet.

On new installations, it should only appear on the right-hand-side.

[Sebastien Bacher (seb128)]

the issue is tricky since the gnome-panel layout is user configuration, we could deprecate the hardy user switching applet and change the session button into the new one on upgrade but that would break for people who changed their layout to not have a session applet but the user switching for example

[Sebastien Bacher (seb128)]

the issue has been discussed today at the desktop team meeting again, some of the options which are been listed:

* do nothing on upgrade and describe the change in the upgrade notes

* change the correspondance between applets and namespace on upgrade (ie migrates the session applet to the new fast user switching applet automatically), but that has side effects:

- that will break configuration for users which are using a fast user switch applet and no session applet for example
- users will not be able to use the upstream session applet if they want
- that will create use configurations which are ubuntu specific (some people run jhbuild session using the same profile for example)

* dynamically change the user configuration on upgrade or first login, that's something we didn't do until now and we have no good framework for it, it would require to writte a tool now and get it right

None of those is really good. I would not rush in changing namespaces or users configuration in upgrade. Does anybody else has a better idea about that?

[Martin Pitt (pitti)]

Option 2 will not only break jhbuild sessions, but also situations where you share your home partitions amongst different distributions or even just different Ubuntu releases. For the same reason, option 3 is not really good.

I am still a strong believer in never trying to change user configuration on upgrades automatically, since there will always be cases when we'll get it wrong.

My personal feeling is that we should describe the change in the upgrade notes, and just let the user remove the superfluous applet himself after the upgrade, depending on which one he likes better. After all, it is an upgrade, which users do to *not* loose all their configuration after all? Would that really be so bad?

[Laura Cowen (lauracowen)]

I raised bug #274576 which has been marked as a duplicate of this bug.

I don't quite understand all the options described above but I think the bug I raised is related but actually not a duplicate. The bug I raised wasn't about the placement of the new fast-switch button, but the fact that the new button does not contain all the functionality of the old applet - the main thing being that I can't 'shutdown' from the new button. Is this intentional or should the new button include all the old options?

[James Westby (james-w)]

Hi Laura,

There are a few issues that have conspired to leave the confusing state
that you saw.

Firstly, the old "shut down" button was an Ubuntu patch to have everything
in one dialog. The code changed underneath it from Hardy to Intrepid, so it would
have to have been re-written. This wasn't done immediately though as other
options were being considered.

The current state is that the "green man" is just for logout, and the user is expected
to go to "System->Shut Down..." to suspend or shut down the machine. This is
the current functionality of the upstream code, but it is being discussed there,
and they will possibly move to a single dialog as Ubuntu had (this is in the 9.04
timeframe).

As well as this the "fast-user-switch" applet (the one that has your name in it)
has been improved to, as well as switching users, show your IM status, and offer
shutdown options. This will be the default in the top right in Intrepid, with the
"green man" not in the panel. I believe this is now the default, and it may have
been that you installed just after the change was made.

This bug is a discussion about the best way to transition users who still have
the "green man" to using the user-switch applet, which provides all of the options
in one. I believe that is why your bug was marked a duplicate, as this bug is
trying to transition users to a situation where they have all the options in one
place again.

Thanks,

James

[Steve Langasek (vorlon)]

Is there a consensus that not changing the applet setup on upgrade is the correct course of action? In that case, should this bug be closed? (I'm inclined to say that redundant applets don't warrant a release notes entry)

[Martin Pitt (pitti)]

Steve Langasek [2008-09-30 3:13 -0000]:
> Is there a consensus that not changing the applet setup on upgrade is
> the correct course of action?

+1 from me.

[Sebastien Bacher (seb128)]

I'm in favor or not changing user configurations on upgrade too

[Ted Gould (ted)]

+1

I think that it is a problem, but one that we need another way to address than what we have currently. User settings are going to continue to be a problem.

[Martin Pitt (pitti)]

CC'ing the bug again, to archive the discussion. I hope you don't mind.

Scott James Remnant [2008-09-30 15:57 +0100]:
> - use gconftool-2 to query the panel applet list and object list:
> /apps/panel/general/applet_id_list
> /apps/panel/generic/object_id_list
>
> (the logout applet is actually an internal object)
>
> - match to /apps/panel/general/applets/*
> and /apps/panel/general/objects/*
>
> - find the logout app and the fusa app, and delete them from the panel
> with gconftool-2
>
> - use --load to load a new applet description for the new fusa app
> (right stick, 0 position) - this has the advantage of attaching
> schema - can get this by --dump on our own
>
> - remember that the applet name needs to be unique ;) we can name it
> whatever we want though

That's exactly the approach that concerned me and which I don't like
at all, since it's just shifting breakage. In particular, there is no
way back: you can't ever use that home directory on an older ubuntu
installation, which happens if you share your /home amongst several
computers in the network (corporate customers *cough*) or just have
several different distros installed at the same time (those kind of
users which also generate the most noise and bad press). Or sharing
your configuration amongst several computers through backup tools,
or ...

For reasons like this I am holding the "don't automatically modify ~
on upgrades" principle very high, and starting to violate it now is a
big step which should be considered thoroughly.

In order to not break compatibility to other distros, I'm also not
much of a fan to invent arbitrary applet names unique to Ubuntu, but
that's a minor aspect, and I'm happy to ignore it if it helps us any
further.

In order to also place something constructive here: IMHO it would be
totally ok if this logic was purely dynamic and wouldn't depend on
gconf changes. Something like:

 - if the old logout applet is configured in the panel, show the new
   f-u-s-a instead
 - if the old f-u-s-a applet is configured:
   - if the new fusa or the old logout applet is configured, ignore
   - else: show the new f-u-s-a

This should give a reasonable semantics without breaking the panel
position or the user's configuration. In particular, it still won't
show f-u-s-a if the user previously had neither, and it maintains the
correct position if the user only had the old fusa and not the logout
applet.

Ted, Seb, is this possible with a reasonable amount of coding?

Thanks,

Martin

[Scott James Remnant (Canonical) (canonical-scott)]

On Wed, 2008-10-01 at 07:48 +0200, Martin Pitt wrote:

> - if the old logout applet is configured in the panel, show the new
> f-u-s-a instead
> - if the old f-u-s-a applet is configured:
> - if the new fusa or the old logout applet is configured, ignore
> - else: show the new f-u-s-a
>
Since this could result in the old logout applet being present, the
behaviour of that applet must be maintained.

So clicking on the old logout applet must present a dialog box with all
of the options that it previously had:

  Lock Screen
  Log Out
  Switch User
  Shut Down
  Suspend
  Hibernate
  Restart

Otherwise we are regressing on behaviour of that applet.

Scott
--
Scott James Remnant
<email address hidden>

[Martin Pitt (pitti)]

Scott James Remnant [2008-10-01 10:07 +0100]:
> On Wed, 2008-10-01 at 07:48 +0200, Martin Pitt wrote:
>
> > - if the old logout applet is configured in the panel, show the new
> > f-u-s-a instead
> > - if the old f-u-s-a applet is configured:
> > - if the new fusa or the old logout applet is configured, ignore
> > - else: show the new f-u-s-a
> >
> Since this could result in the old logout applet being present, the
> behaviour of that applet must be maintained.

How so? I thought the old logout applet was deprecated, so under
intrepid we should show f-u-s-a instead?

Just to be clear, that's the "green running man" we are talking about,
right?

Martin

[Matt Zimmerman (mdz)]

On Wed, Oct 01, 2008 at 02:23:42PM +0200, Martin Pitt wrote:
> Scott James Remnant [2008-10-01 10:07 +0100]:
> > On Wed, 2008-10-01 at 07:48 +0200, Martin Pitt wrote:
> >
> > > - if the old logout applet is configured in the panel, show the new
> > > f-u-s-a instead
> > > - if the old f-u-s-a applet is configured:
> > > - if the new fusa or the old logout applet is configured, ignore
> > > - else: show the new f-u-s-a
> > >
> > Since this could result in the old logout applet being present, the
> > behaviour of that applet must be maintained.
>
> How so? I thought the old logout applet was deprecated, so under
> intrepid we should show f-u-s-a instead?

That would be better, but my impression from this thread is that that would
be too high risk.

> Just to be clear, that's the "green running man" we are talking about,
> right?

Yes (where the "power button" used to be).

--
 - mdz

[Ted Gould (ted)]

On Wed, 2008-10-01 at 14:19 +0100, Matt Zimmerman wrote:
> Note that this, the most significant issue in my opinion, could be easily
> addressed by restoring the lost functionality to the logout button.

Are you suggesting that the logout button should have it's own dialog
and not use the gnome-session one?

> Beyond that, I think it would be sufficient to include a program which users
> could run (manually) to restore their panel (session?) to the default. This
> way, when users ask "hey, how do I get that fancy new panel?" they get the
> answer "run restore-default-panel" rather than "rm -rf ~/.gconf" :-)

  $ gconftool-2 --unset-recursive /apps/panel

I generally dislike any answer being "use the command line" but I think
in this case it's okay.

> Would this be less objectionable than attempting to migrate automatically?

Yes. Perhaps we should include a "gconftool --dump /apps/panel >
myfile.xml" and a "gconftool --load=/apps/panel myfile.xml" in there
also for undo.

  --Ted

[Matt Zimmerman (mdz)]

On Wed, Oct 01, 2008 at 10:15:53AM -0500, Ted Gould wrote:
> On Wed, 2008-10-01 at 14:19 +0100, Matt Zimmerman wrote:
> > Note that this, the most significant issue in my opinion, could be easily
> > addressed by restoring the lost functionality to the logout button.
>
> Are you suggesting that the logout button should have it's own dialog
> and not use the gnome-session one?

gnome-session, as I understand it, has two. I think that button should
(continue to) provide a single dialog with all of the options.

> > Beyond that, I think it would be sufficient to include a program which users
> > could run (manually) to restore their panel (session?) to the default. This
> > way, when users ask "hey, how do I get that fancy new panel?" they get the
> > answer "run restore-default-panel" rather than "rm -rf ~/.gconf" :-)
>
> $ gconftool-2 --unset-recursive /apps/panel
>
> I generally dislike any answer being "use the command line" but I think
> in this case it's okay.

That might be a useful script to have in the package.

> > Would this be less objectionable than attempting to migrate automatically?
>
> Yes. Perhaps we should include a "gconftool --dump /apps/panel >
> myfile.xml" and a "gconftool --load=/apps/panel myfile.xml" in there
> also for undo.

That's a good idea. While we're at it, we could add that info to an apport
hook so that it gets attached to bug reports.

--
 - mdz

[Martin Pitt (pitti)]

Hello Matt,

Matt Zimmerman [2008-10-01 14:19 +0100]:
> > That's correct. However, if the user doesn't get the deskbar applet added,
> > they don't lose anything they had before. With the changed logout button,
> > they are losing functionality they previously had.
>
> Note that this, the most significant issue in my opinion, could be easily
> addressed by restoring the lost functionality to the logout button.

If that would actually be easy to do, sure. However, my gut feeling
says it should actually be easier to just pretend that the new f-u-s-a
applet is just the "replacement" of the old logout applet? It already
provides all the logout/shutdown/etc. options. Ted, do you have a
qualified estimate of how much work either option would be?

> Beyond that, I think it would be sufficient to include a program which users
> could run (manually) to restore their panel (session?) to the default. This
> way, when users ask "hey, how do I get that fancy new panel?" they get the
> answer "run restore-default-panel" rather than "rm -rf ~/.gconf" :-)
>
> Would this be less objectionable than attempting to migrate automatically?

Yes, definitively. That's the fallback we should have at hand if this
kind of dynamic auto-migration doesn't work out.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Ted Gould (ted)]

On Wed, 2008-10-01 at 19:13 +0200, Martin Pitt wrote:
> Matt Zimmerman [2008-10-01 14:19 +0100]:
> > > That's correct. However, if the user doesn't get the deskbar applet added,
> > > they don't lose anything they had before. With the changed logout button,
> > > they are losing functionality they previously had.
> >
> > Note that this, the most significant issue in my opinion, could be easily
> > addressed by restoring the lost functionality to the logout button.
>
> If that would actually be easy to do, sure. However, my gut feeling
> says it should actually be easier to just pretend that the new f-u-s-a
> applet is just the "replacement" of the old logout applet? It already
> provides all the logout/shutdown/etc. options. Ted, do you have a
> qualified estimate of how much work either option would be?

I think I'm going to try and be a little verbose here, just to ensure
that we're all talking about the same thing and that others (and perhaps
me) aren't confused in the thread :)

To change the current logout button to show the old dialog, and work
around the GNOME session dialogs would take a couple things. One would
be writing that dialog, though probably most of that would be available
in the previous GNOME session patch. Then it would call GNOME Session
through XSMP with the "no GUI" option similar to how the FUSA applet
does it today. This would requiring the C code that implements the
panel object that is the logout button.

To change gnome-panel so that when it saw the object ID for the logout
button and then put in the FUSA applet would be... interesting. I
imagine the code itself wouldn't be hard but I would be a little worried
about fallout in things like the "Add to Panel" dialog and things like
that where we'd need to ensure that we accurately display what is going
to happen.

  --Ted

[Steve Langasek (vorlon)]

Since there is still ongoing discussion here, I'm pushing the milestone back to 8.10 instead of closing the bug.

It would be a good idea to bring the discussion to a conclusion this week, so that the implementation can be uploaded as soon after beta as possible.

[Matt Zimmerman (mdz)]

On Wed, Oct 01, 2008 at 04:38:44PM -0500, Ted Gould wrote:
> On Wed, 2008-10-01 at 19:13 +0200, Martin Pitt wrote:
> > Matt Zimmerman [2008-10-01 14:19 +0100]:
> > > > That's correct. However, if the user doesn't get the deskbar applet added,
> > > > they don't lose anything they had before. With the changed logout button,
> > > > they are losing functionality they previously had.
> > >
> > > Note that this, the most significant issue in my opinion, could be easily
> > > addressed by restoring the lost functionality to the logout button.
> >
> > If that would actually be easy to do, sure. However, my gut feeling
> > says it should actually be easier to just pretend that the new f-u-s-a
> > applet is just the "replacement" of the old logout applet? It already
> > provides all the logout/shutdown/etc. options. Ted, do you have a
> > qualified estimate of how much work either option would be?
>
> I think I'm going to try and be a little verbose here, just to ensure
> that we're all talking about the same thing and that others (and perhaps
> me) aren't confused in the thread :)
>
> To change the current logout button to show the old dialog, and work
> around the GNOME session dialogs would take a couple things. One would
> be writing that dialog, though probably most of that would be available
> in the previous GNOME session patch. Then it would call GNOME Session
> through XSMP with the "no GUI" option similar to how the FUSA applet
> does it today. This would requiring the C code that implements the
> panel object that is the logout button.

This is not about how the dialog looks, but the end user functionality in
it. The current upstream "Shut Down" dialog offers everything we need
*except* the "Log Out" option, and I would imagine this is possible to add.
Then the logout button could open that dialog.

Is there a technical reason why that wouldn't work?

--
 - mdz

[Sebastien Bacher (seb128)]

Le jeudi 02 octobre 2008 à 09:04 +0100, Matt Zimmerman a écrit :
> This is not about how the dialog looks, but the end user functionality
> in
> it. The current upstream "Shut Down" dialog offers everything we need
> *except* the "Log Out" option, and I would imagine this is possible to
> add.
> Then the logout button could open that dialog.
>
> Is there a technical reason why that wouldn't work?

Doing that would either require to change the upstream dialog to list
all the option or to add a new dialog similar to the current upstream
ones which list those. Changing the dialog would create a delta over
upstream we will need to maintain, makes the two system menu entries
irrevelant and makes some user unhappy who like the upstream way better
(we had a gconf key in hardy to use the upstream dialog). Creating a
similar dialog which lists all the option bring back to the
configuration migration issue since that would be a new object and that
requires to update the user configuration on upgrade, the change would
be easier though since we would just have to change the object naming
and not the layout for example. Users who don't have an user switching
applet would probably expect this action to be in the dialog too though

[Matt Zimmerman (mdz)]

On Thu, Oct 02, 2008 at 12:30:46PM +0200, Sebastien Bacher wrote:
> Le jeudi 02 octobre 2008 à 09:04 +0100, Matt Zimmerman a écrit :
> > This is not about how the dialog looks, but the end user functionality
> > in
> > it. The current upstream "Shut Down" dialog offers everything we need
> > *except* the "Log Out" option, and I would imagine this is possible to
> > add.
> > Then the logout button could open that dialog.
> >
> > Is there a technical reason why that wouldn't work?
>
> Doing that would either require to change the upstream dialog to list
> all the option or to add a new dialog similar to the current upstream
> ones which list those. Changing the dialog would create a delta over
> upstream we will need to maintain

All of the functions we need are already there. It's just adding an entry
to the dialog. This is a tiny delta.

> , makes the two system menu entries irrevelant

No more so than they already are (due to the logout applet and f-u-s-a), or
were in previous versions of Ubuntu (due to the unified logout dialog).

> and makes some user unhappy who like the upstream way better

How so? They can still use the menu entries.

> (we had a gconf key in hardy to use the upstream dialog). Creating a
> similar dialog which lists all the option bring back to the
> configuration migration issue since that would be a new object and that
> requires to update the user configuration on upgrade, the change would
> be easier though since we would just have to change the object naming
> and not the layout for example. Users who don't have an user switching
> applet would probably expect this action to be in the dialog too though

There is no need for a new object; users upgrading from Hardy or early
Intrepid will already have the logout button at the upper right.

--
 - mdz

[Sebastien Bacher (seb128)]

Le jeudi 02 octobre 2008 à 11:42 +0100, Matt Zimmerman a écrit :
> > Doing that would either require to change the upstream dialog to
> list
> > all the option or to add a new dialog similar to the current
> upstream
> > ones which list those. Changing the dialog would create a delta over
> > upstream we will need to maintain
>
> All of the functions we need are already there. It's just adding an
> entry
> to the dialog. This is a tiny delta.

right, but by doing that you will have the system, closing session and
the shutdown entry list the duplicated actions for example. in this case
does it still make sense to have two entries there?

> No more so than they already are (due to the logout applet and
> f-u-s-a), or
> were in previous versions of Ubuntu (due to the unified logout
> dialog).

the ubuntu changes were on the gnome-session dialog that GNOME doesn't
use and there was a gconf key which allowed users to use the gnome-panel
upstream dialogs instead

> How so? They can still use the menu entries.

you suggest patching one of the dialogs so the menu entries will have
redundant actions, in which case in might not make sense to have several
items listed there

> There is no need for a new object; users upgrading from Hardy or early
> Intrepid will already have the logout button at the upper right.

right, it you decide to modify the upstream dialogs, in which case no
change is required but we go back to have one dialog rather than two and
then need to change gnome-panel and the other softwares using those

[Matt Zimmerman (mdz)]

On Thu, Oct 02, 2008 at 02:30:44PM +0200, Sebastien Bacher wrote:
> Le jeudi 02 octobre 2008 à 11:42 +0100, Matt Zimmerman a écrit :
> > > Doing that would either require to change the upstream dialog to
> > list
> > > all the option or to add a new dialog similar to the current
> > upstream
> > > ones which list those. Changing the dialog would create a delta over
> > > upstream we will need to maintain
> >
> > All of the functions we need are already there. It's just adding an
> > entry
> > to the dialog. This is a tiny delta.
>
> right, but by doing that you will have the system, closing session and
> the shutdown entry list the duplicated actions for example. in this case
> does it still make sense to have two entries there?

I don't think it makes sense to have two entries there in the first place,
but if you are opposed to removing them, I don't think it's a problem.

> > No more so than they already are (due to the logout applet and f-u-s-a),
> > or were in previous versions of Ubuntu (due to the unified logout
> > dialog).
>
> the ubuntu changes were on the gnome-session dialog that GNOME doesn't
> use and there was a gconf key which allowed users to use the gnome-panel
> upstream dialogs instead

If that's a concern, we could make the patch 10 lines longer and still check
the same gconf key. That way, the 5 people who need that key aren't
inconvenienced, but we do the right thing for the other millions of users.

> > How so? They can still use the menu entries.
>
> you suggest patching one of the dialogs so the menu entries will have
> redundant actions, in which case in might not make sense to have several
> items listed there
>
> > There is no need for a new object; users upgrading from Hardy or early
> > Intrepid will already have the logout button at the upper right.
>
> right, it you decide to modify the upstream dialogs, in which case no
> change is required but we go back to have one dialog rather than two and
> then need to change gnome-panel and the other softwares using those

I don't consider the redundant menu entries to be as much of a problem as
having one of the most prominent buttons on the default desktop lose most of
its functionality.

--
 - mdz

[Sebastien Bacher (seb128)]

Le jeudi 02 octobre 2008 à 13:37 +0100, Matt Zimmerman a écrit :
> I don't consider the redundant menu entries to be as much of a problem
> as
> having one of the most prominent buttons on the default desktop lose
> most of
> its functionality.

Right, so let's summarize the discussion, I see 3 ways to go there:

* use the stock upstream dialogs and the new user switch applet and do
users configurations changes on update:

advantages:
- that works out of the box for new installation
- there is no upstream patching required
- some users like the upstream way to have different dialogs

inconvenients:
- requires to migrate the configuration on upgrade in a non trivial way
(basically what scott described before)
- some users will likely not like the new switch user applet and would
like better to have a dialog listing all the session options

* change the logout upstream dialog to list all the options

advantages:
- will not confuse users who like having one dialog listing everything
- doesn't require configuration changes on upgrade

inconvenients:
- requires to apply patches to the upstream code
- makes the configuration, interfaces and layout ubuntu specific
- some users like the upstream way better

* add an extra dialog similar to the 2 upstream ones which lists all the
options

advantages:
- the gnome-panel layout is the upstream one and the applet will still
be listing all the available actions
- no configuration change required (or a limited one if you want to add
a new applet for this dialog, that would just be changed the object name
in the configuration and not the layout)
- there is no need to change the upstream code but rather to add some
new one which makes updates easier

inconvenients:
- requires to write the new dialog, though if we want to something
similar to the upstream ones listing all the options that's trivial
- the new dialog and the user switching applet will somewhat be
redundant since they will list all the actions and should probably not
be both listed on upgrades (or the switch user applet should have go
back to only switching users)

Not sure what would be the best but my preference would be to add an
extra dialog lists all the options (that's also what vuntz suggested
when we first talked about the new upstream session dialogs), that would
nicely solve the upgrade case, we would need to figure if we want to use
that or the new user switching applet on new installations though.
Changing the user configuration on upgrade would work too, we would have
to ask a question after the first login though and it will require some
testing to make sure it's working correctly. I would prefer not have to
diverge over what upstream is doing there if that's not required

[Martin Pitt (pitti)]

Ted Gould [2008-10-01 16:38 -0500]:
> To change gnome-panel so that when it saw the object ID for the logout
> button and then put in the FUSA applet would be... interesting. I
> imagine the code itself wouldn't be hard

It'd actually be a bit more complex than that. The new fusa is
essentially meant to merge the functionality of the old fusa and
logout applets, thus the new fusa needs to be displayed if *either*
old fusa or logout applet is currently configured in the panel, and
appear at the respective place (with preferring the location of the
logout applet)

> but I would be a little worried about fallout in things like the
> "Add to Panel" dialog and things like that where we'd need to ensure
> that we accurately display what is going to happen.

Ideally the logout applet wouldn't even appear there any more, as far
as I can see. When you add a new one, you should just get the new fusa
with its proper object ID.

[Martin Pitt (pitti)]

Sebastien Bacher [2008-10-02 16:28 +0200]:
> * use the stock upstream dialogs and the new user switch applet and do
> users configurations changes on update:
> [...]
> inconvenients:

- breaks compatibility with earlier Ubuntu releases and other
  distributions, which is an issue for shared /home (network or
  multi-boot)

> * change the logout upstream dialog to list all the options
>
> advantages:
> - will not confuse users who like having one dialog listing everything
> - doesn't require configuration changes on upgrade
>
> inconvenients:
> - requires to apply patches to the upstream code
(basically forever)

> * add an extra dialog similar to the 2 upstream ones which lists all the
> options
> inconvenients:
[...]
- the dialog would be even worse than the one we had in hardy, since
  it has too many options, and now even lots of text to it, too

But we actually discuss a fourth option, too:

 * make the new fusa applet recognize the object ID of the old logout
   applet, so that the panel shows it instead of the logout applet;
   in a couple of releases we can finally transition this to a
   permanent configuration with the first option (gconftool invocation)

pro:
 - maintains backwards compatibility
 - upgraded system looks like freshly installed one
 - no deviation from upstream look&feel
 - no eternal code deviation from upstream
 - no need to maintain the old logout applet forever

con:
 - unknown amount of work for implementing this
 - complex logic for placement of the new fusa (at the position of the
   logout applet if it exists, or the old fusa applet if it exists)

This would be my preferrred option.

> I would prefer not have to
> diverge over what upstream is doing there if that's not required

Same here.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Scott James Remnant (Canonical) (canonical-scott)]

NOTE: panel "applets" and "objects" are _DIFFERENT_ things!

On Thu, 2008-10-02 at 17:40 +0200, Martin Pitt wrote:

> * make the new fusa applet recognize the object ID of the old logout
> applet, so that the panel shows it instead of the logout applet;
> in a couple of releases we can finally transition this to a
> permanent configuration with the first option (gconftool invocation)
>
My understanding from Vincent is that applets cannot be objects and
vice-versa.

The only way to have the panel show the fusa applet instead of the
logout object would be to have the fusa applet code merged into the
panel as a new object.

Scott
--
Scott James Remnant
<email address hidden>

[Matt Zimmerman (mdz)]

On Thu, Oct 02, 2008 at 04:28:48PM +0200, Sebastien Bacher wrote:
> Le jeudi 02 octobre 2008 à 13:37 +0100, Matt Zimmerman a écrit :
> > I don't consider the redundant menu entries to be as much of a problem
> > as
> > having one of the most prominent buttons on the default desktop lose
> > most of
> > its functionality.
>
> Right, so let's summarize the discussion, I see 3 ways to go there:
>
> * use the stock upstream dialogs and the new user switch applet and do
> users configurations changes on update:
>
> advantages:
> - that works out of the box for new installation
> - there is no upstream patching required
> - some users like the upstream way to have different dialogs
>
> inconvenients:
> - requires to migrate the configuration on upgrade in a non trivial way
> (basically what scott described before)
> - some users will likely not like the new switch user applet and would
> like better to have a dialog listing all the session options

This seems like the most risky to me.

> * change the logout upstream dialog to list all the options
>
> advantages:
> - will not confuse users who like having one dialog listing everything
> - doesn't require configuration changes on upgrade
>
> inconvenients:
> - requires to apply patches to the upstream code
> - makes the configuration, interfaces and layout ubuntu specific
> - some users like the upstream way better
>
>
> * add an extra dialog similar to the 2 upstream ones which lists all the
> options

...and change the logout applet to use it (right?).

> advantages:
> - the gnome-panel layout is the upstream one and the applet will still
> be listing all the available actions
> - no configuration change required (or a limited one if you want to add
> a new applet for this dialog, that would just be changed the object name
> in the configuration and not the layout)
> - there is no need to change the upstream code but rather to add some
> new one which makes updates easier
>
> inconvenients:
> - requires to write the new dialog, though if we want to something
> similar to the upstream ones listing all the options that's trivial
> - the new dialog and the user switching applet will somewhat be
> redundant since they will list all the actions and should probably not
> be both listed on upgrades (or the switch user applet should have go
> back to only switching users)

I can think of another option:

 * change the logout applet to display the shut down dialog instead of the
   log out dialog

advantages:
- no configuration changes required
- should be a very small code change

problems:
- makes the applet name counter-intuitive
- some people might use the log out option (but I think this is unusual on
  single-user systems), though we could add it to the shut down dialog
  (smaller change than modifying the log out dialog)

--
 - mdz

[Sebastien Bacher (seb128)]

Le jeudi 02 octobre 2008 à 16:57 +0100, Matt Zimmerman a écrit :
> On Thu, Oct 02, 2008 at 04:28:48PM +0200, Sebastien Bacher wrote:

> > * add an extra dialog similar to the 2 upstream ones which lists all the
> > options
>
> ...and change the logout applet to use it (right?).

no, since we would be changing the logout dialog (the one the button is
opening right now) there is no applet change to do, the applet is only
showing this dialog

> * change the logout applet to display the shut down dialog instead of the
> log out dialog

right, we could do that too, it would still not list some actions though

> - some people might use the log out option (but I think this is unusual on
> single-user systems), though we could add it to the shut down dialog
> (smaller change than modifying the log out dialog)

if we do that we are back at duplication between the dialogs

[Martin Pitt (pitti)]

Sebastien Bacher [2008-10-02 17:53 +0200]:
> there is no "old logout applet", this applet is an upstream gnome-panel
> one and is still there in the current version

Seb just pointed out to me that the logout applet is not actually
deprecated. Previously I understood it that way, and thus looked for
solutions in that direction. So since that's obviously not the case,
the dynamic replacement is wrong, and I discard that proposal.

Scott James Remnant [2008-10-02 16:55 +0100]:
> NOTE: panel "applets" and "objects" are _DIFFERENT_ things!

For that reason I discard it as well :)

> The only way to have the panel show the fusa applet instead of the
> logout object would be to have the fusa applet code merged into the
> panel as a new object.

Right, that's not something we'd ever want to do as an Ubuntu patch,
let alone this close to a release.

[Matt Zimmerman (mdz)]

On Thu, Oct 02, 2008 at 06:09:58PM +0200, Sebastien Bacher wrote:
> Le jeudi 02 octobre 2008 à 16:57 +0100, Matt Zimmerman a écrit :
> > On Thu, Oct 02, 2008 at 04:28:48PM +0200, Sebastien Bacher wrote:
>
> > > * add an extra dialog similar to the 2 upstream ones which lists all the
> > > options
> >
> > ...and change the logout applet to use it (right?).
>
> no, since we would be changing the logout dialog (the one the button is
> opening right now) there is no applet change to do, the applet is only
> showing this dialog

Maybe I'm confused. Above, it says "add an extra dialog" (in addition to
the other two). Unless the applet is changed, it will still use the log out
dialog.

>
> > * change the logout applet to display the shut down dialog instead of the
> > log out dialog
>
> right, we could do that too, it would still not list some actions though
>
> > - some people might use the log out option (but I think this is unusual on
> > single-user systems), though we could add it to the shut down dialog
> > (smaller change than modifying the log out dialog)
>
> if we do that we are back at duplication between the dialogs

What is the issue with duplicating one option between the two dialogs?

--
 - mdz

[Sebastien Bacher (seb128)]

Le jeudi 02 octobre 2008 à 17:43 +0100, Matt Zimmerman a écrit :
> Maybe I'm confused. Above, it says "add an extra dialog" (in addition
> to
> the other two). Unless the applet is changed, it will still use the
> log out
> dialog.

oh right, that's me who got confused when reading the reply

[Sebastien Bacher (seb128)]

Le jeudi 02 octobre 2008 à 17:43 +0100, Matt Zimmerman a écrit :
> What is the issue with duplicating one option between the two dialogs?

no real issue but I'm not an usability expert, mpt do you think that's
something that could confuse users?

[Matthew Paul Thomas (mpt)]

I'm not sure that it would be confusing, but I am sure that it would be ridiculed by users and reviewers, and rightly so.

Using a pointing device, there should be one obvious way of logging out, one obvious way of restarting, and one obvious way of shutting down. Now that we have the new status menu, it provides all three of those commands. Therefore, we should not have extra buttons for any of them, and we should no longer have Log Out in any dialogs *at all*.

The only reason we need a dialog is when someone presses the power button on their machine, because (until ExitStrategy is implemented) we need to ask whether they mean Suspend, Hibernate, Shut Down, or Restart. We can assume they don't mean Log Out, because, well, it's a power button.

People using the same home folder with an older version of Ubuntu, or a different distribution, can quit using the items in the System menu of the Menu Bar or Main Menu. But when anyone uses Ubuntu 8.10, whether a new installation or an upgrade, please, have the new status menu as the single access point for all the quit commands.

[Ted Gould (ted)]

On Thu, 2008-10-02 at 19:14 +0000, Matthew Paul Thomas wrote:
> People using the same home folder with an older version of Ubuntu, or a
> different distribution, can quit using the items in the System menu of
> the Menu Bar or Main Menu. But when anyone uses Ubuntu 8.10, whether a
> new installation or an upgrade, please, have the new status menu as the
> single access point for all the quit commands.

Users with default installations will have the FUSA applet to do these
commands. They have not been removed from the System menu.

While technically possible, it would require a patch to gnome-panel to
do this. I'm not sure that it would (or should) get a beta freeze
exception.

[Vincent Untz (vuntz)]

I quickly read the various comments. And here are my €0.02.

It's not clear to me whether you guys want to migrate panels from old users to the new config or not. If you do, you'll have to either patch the panel for the next 2-3 years (until next LTS, I guess?), or provide a small migration helper for the same amount of time. So, migration means code to maintain.

Then you have the issues of how to logout/shutdown/reboot. I didn't see the new applet, so those are purely comments from an upstream point of view:

 + note that you're already using a patch that I wrote for the logout dialogs. Those dialogs are not upstream, and some people upstream don't like it. FWIW, we ship them in openSUSE, so I expect the patch to be "maintained" by me at least.

 + you can add an additional patch to have one dialog. It's not hard, and I already talked a bit to Sebastien about this, I believe (you'll want to add a new ubuntu-specific dbus method, and copy & paste code to create the new dialog). However, this will most probably never go upstream.

 + if you don't migrate the panel config, you'll have to keep the logout/shutdown options in the menubar.

Now, my opinion: I would probably migrate the user setting, and only have logout/shutdown in the fusa applet. This means patching things out in the menubar (well, actually, you could dynamically detect if the fusa applet is on one panel and show/hide those items in the menubar).

My guess is that the fusa menu would directly contain logout/reboot/shutdown and you're doing a bit like OS X here. So in this case, you'd want to have new confirmation dialogs instead of the upstream dialogs which propose more than just "ok/cancel" (since the user has to choose if he wants to reboot or shutdown in this dialog). This means new code, either in gnome-session or in the applet.

[of course, all this is discussion that should happen upstream, because the work you've done to the fusa applet should have been done upstream]

[Ted Gould (ted)]

I think we're at the point of choose one. I don't think that anything has come out as the obvious winner.

[Martin Pitt (pitti)]

As per today's desktop team meeting, the consensus is to provide a script for the migration:

if either the logout applet or the old fusa is configured, do:
  * delete the session button
  * add new fusa into the corner
  * delete old fusa before doing that if it's used in the config

Michael has a prototype for this script already which just needs some tweaks.

This should be wrapped into an interactive upgrading hook, which explains the merging of the two applets, and offers the user to do the migration. The note should point out that this is an one-way migration and thus your configuration will not work any more on earlier Ubuntu installations.

[Michael Vogt (mvo)]

Here is a possible solution based on the interactive upgrade hooks:
http://people.ubuntu.com/~mvo/tmp/fusa-foo.diff

Please review and let me know what you think. Especially the strings could do with some love :)

It also needs to deal with the case were the fusa applet is missing entirely - not sure about this yet.

[Michael Vogt (mvo)]

I improved the text a bit and uploaded it.

The text may not be ideal, someone with a good sense for UI design may want to have a look. The other shortcoming is the "run this action now" button. The button caption is really not ideal, currently updat-enotifier has no way to replace the button caption with a custom one. We could add that (and should for jaunty) but I'm not sure about intrepid, because we are just too deeply frozen.

[Martin Pitt (pitti)]

gnome-panel (1:2.24.0-0ubuntu2) intrepid; urgency=low

  * debian/fusa-applet.note.in, debian/migrate-fusa-config.py,
    20_fusa_migration_note_i18n.patch:
    - show a update-notifer hook about the new fusa applet and
      add a script that can do the config migration (LP: #274146)

 -- Michael Vogt < <email address hidden>> Fri, 10 Oct 2008 13:10:54 +0200

[Steve Langasek (vorlon)]

The fix for this implemented in GNOME seems reasonably complete, so I don't think there's any longer a need to document this in the release notes. If you disagree, please reopen this task.