Bug #8302

Shutdown helper applet in Jessie

Added by anonym 2014-11-25 12:24:00 . Updated 2015-10-05 05:04:08 .

Status:
Resolved
Priority:
Elevated
Assignee:
Category:
Target version:
Start date:
2014-11-26
Due date:
2015-10-15
% Done:

100%

Feature Branch:
feature/jessie
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:
267

Description

In Jessie we use GNOME Shell, which doesn’t handle status area icons like in GNOME 2.x. We use the topIcons GNOME Shell extension to re-enable such status area icons, e.g. for gpgApplet and Vidalia, but for some reason the shutdown helper doesn’t show up.

Even if we could get it to work with topIcons, it’s probably not a good idea. The GNOME user menu already has a shutdown icon in it, and it’d be more elegant to integrate it there, most likely by writing some simple GNOME Shell extension.


Files


Subtasks

Feature #8314: Jessie: integrate shutdown-helper extension with our translation system Resolved

100

Feature #8315: Import existing translations of shutdown-helper extension Rejected

0

Bug #8316: Should not display a Lock button unless a password was set Resolved

0

Bug #10173: Make shutdown-helper in Jessie compatible with Orca Resolved

100


History

#1 Updated by anonym 2014-11-25 12:46:19

I propose the following:

Goal: In the GNOME user menu, show both a “Restart” and “Power Off” button, instead of only the “Power Off” button (which switches to “Suspend” when Alt is pressed). When one of these are pressed, the reboot/shutdown action happens without further user intervention, i.e. there’s no prompt.

This can be achieved quite easily by basing our work on https://github.com/laserb/gnome-shell-extension-suspend-button. What it does is that it splits the “Power Off”/“Suspend” button into two separate buttons (so the Alt-switching described above is removed). We essentially will just have to s/Suspend/Restart/ to get the functionality we want, but it would be a good for maintainability to rip out everything we don’t need as well.

Bonus: it’s packaged in Debian so we can make it into a separate package quite easily: git://anonscm.debian.org/collab-maint/gnome-shell-extension-suspend-button.git

Also, I’ve noticed that GNOME Shell behaves sane with screen locking; if I run gnome-screensaver-command --lock with a password set, the screen is locked and a password is required to unlock, but when a password is not set, none is required. Adding a separate “Lock Screen” button should be simple. The we don’t have to worry about the current state of Feature #5878 as we get what we want for free.

#2 Updated by anonym 2014-11-25 13:58:20

See attached file for an implementation of comment 1. To test it in a running Jessie-based Tails with an admin password set, untar it into /usr/share/gnome-shell/extensions (and make sure the ownership/permissions are good), and then enable the “Shutdown Helper” extension with gnome-shell-extension-prefs. You may have to restart GNOME (systemctl restart gdm3) to make it apply the first time, but after that it can be enabled/disabled at will.

#3 Updated by anonym 2014-11-25 15:01:21

anonym wrote:
> Also, I’ve noticed that GNOME Shell behaves sane with screen locking; if I run gnome-screensaver-command --lock with a password set, the screen is locked and a password is required to unlock, but when a password is not set, none is required.

For this to work, it seems we have to passwd -d amnesia, which we can add to Tails Greeter’s PostLogin script, where we handle the case where no password is set.

#4 Updated by intrigeri 2014-11-25 19:45:10

> Bonus: it’s packaged in Debian so we can make it into a separate package quite easily:
> git://anonscm.debian.org/collab-maint/gnome-shell-extension-suspend-button.git

I don’t get what you mean with “make it into a separate package”, nor why you’re attaching a tarball. Can’t we just install the package from Jessie?

#5 Updated by intrigeri 2014-11-25 19:45:40

> I propose the following:

I like this plan!

#6 Updated by anonym 2014-11-26 08:41:42

  • Subject changed from Emergency shutdown helper applet in Jessie to Shutdown helper applet in Jessie
  • Description updated

#7 Updated by anonym 2014-11-26 08:56:54

intrigeri wrote:
> > Bonus: it’s packaged in Debian so we can make it into a separate package quite easily:
> > git://anonscm.debian.org/collab-maint/gnome-shell-extension-suspend-button.git
>
> I don’t get what you mean with “make it into a separate package”, nor why you’re attaching a tarball. Can’t we just install the package from Jessie?

I suggested that we fork gnome-shell-extension-suspend-button since its plumbing is similar to what we want, so it’s a good base for the extension we actually want. To be clear: gnome-shell-extension-suspend-button does not do what we want at all.

The attached tarball, and the instructions can be used to test how this will actually look and work. I thought that would be helpful for making a decision on whether we want this. Any way, I’ll attach a screen shot instead.

What I meant with the “bonus” remark was simply that since it’s already packaged for Debian, so we don’t have to make the packaging from scratch, we can just adapt the existing one. OTOH, the packaging is setup to track an upstream, but we probably want it to be native, so I suppose the adaption won’t be completely trivial (although still easy).

The (even easier) alternative would be to just dump the extension straight into Tails’ Git repo, like you did with topIcons. It may not be so bad of an idea since this now is a completely divergent fork, so we won’t be frequently pulling anything from gnome-shell-extension-suspend-button. What do you think?

Sorry if I was unclear.

>> I propose the following:
> I like this plan!

I’ll proceed then after I’ve gotten your opinion on how to install this extension.

#8 Updated by anonym 2014-11-26 09:02:47

#9 Updated by intrigeri 2014-11-26 09:19:56

OK, got it. Thanks for clarifying!

Before diving into the “how to maintain a fork” topic, just a sanity check: why not add the options we need to the existing extension, so that we don’t have to maintain it ourselves forever?

> The (even easier) alternative would be to just dump the extension straight into Tails’ Git repo, like you did with topIcons. It may not be so bad of an idea since this now is a completely divergent fork, so we won’t be frequently pulling anything from gnome-shell-extension-suspend-button. What do you think?

Agreed, this is acceptable too. We’ll have to be careful about potential future updates of gnome-shell-extension-suspend-button in Jessie, but tracking this should be cheaper than maintaining a Debian package. And I doubt anyone would really be benefiting from a proper Debian package anyway.

#10 Updated by intrigeri 2014-11-26 09:22:46

  • Assignee set to anonym
  • Type of work changed from Research to Code

#11 Updated by anonym 2014-11-26 10:22:57

  • Assignee deleted (anonym)
  • Type of work changed from Code to Research

intrigeri wrote:
> Before diving into the “how to maintain a fork” topic, just a sanity check: why not add the options we need to the existing extension, so that we don’t have to maintain it ourselves forever?

I simply doubt that the maintainer would be interested. I think the background of this extension is the following: In GNOME 3.10 (I think) the GNOME devs made it impossible to suspend without pressing Alt, which then transforms the Shutdown button to the Suspend button. Some people run GNOME from tablets that do not have an Alt key (except via the on-screen keyboard, which is inconvenient) or just find it utterly retarded and unintuitive design (me included). I believe gnome-shell-extension-suspend-button was created for fixing this, and nothing else.

What we’d need upstreamed is the following:

  • An option to show a Lock Screen button
  • An option to show a Restart button
  • An option to not show the “Suspend” button
  • Options to change the manner of how Shutdown/Restart is initiated. We don’t want to use GNOME’s controlled way, since it shows a verification promp, and may be inhibited by a number of things (root application running, tty login, etc.). While the verification prompt can be suppressed with dconf’s /org/gnome/gnome-session/logout-prompt, the inhibition cannot AFAICT, so we want to run sudo -n reboot/halt or similar.

All this will add a lot of complexity for things that goes outside of the extension’s original purpose (the -suspend-button part), and which are likely irrelevant for most GNOME users.

> > The (even easier) alternative would be to just dump the extension straight into Tails’ Git repo, like you did with topIcons. It may not be so bad of an idea since this now is a completely divergent fork, so we won’t be frequently pulling anything from gnome-shell-extension-suspend-button. What do you think?
>
> Agreed, this is acceptable too. We’ll have to be careful about potential future updates of gnome-shell-extension-suspend-button in Jessie, but tracking this should be cheaper than maintaining a Debian paccompletely divergent forkage. And I doubt anyone would really be benefiting from a proper Debian package anyway.

Right. I sort of doubt we will ever have to pull anything from gnome-shell-extension-suspend-button any more. I ripped out all code that isn’t relevant to us, so it’s effectively a different extension.

So, given my explanation above, do we agree that this is the way to go?

#12 Updated by anonym 2014-11-26 10:23:21

  • Assignee set to anonym
  • Type of work changed from Research to Code

#13 Updated by intrigeri 2014-11-26 10:42:43

> I simply doubt that the maintainer would be interested.

I’m now convinced. Go, go, go :)

> We don’t want to use GNOME’s controlled way, since it shows a verification promp, and may be inhibited by a number of things (root application running, tty login, etc.). While the verification prompt can be suppressed with dconf’s /org/gnome/gnome-session/logout-prompt, the inhibition cannot AFAICT, so we want to run sudo -n reboot/halt or similar.

Is that still the case on Jessie? I’ve not seen such inhibition messages for months on my sid desktop (while I previously did).

#14 Updated by anonym 2014-11-26 13:20:43

intrigeri wrote:
> > We don’t want to use GNOME’s controlled way, since it shows a verification promp, and may be inhibited by a number of things (root application running, tty login, etc.). While the verification prompt can be suppressed with dconf’s /org/gnome/gnome-session/logout-prompt, the inhibition cannot AFAICT, so we want to run sudo -n reboot/halt or similar.
>
> Is that still the case on Jessie? I’ve not seen such inhibition messages for months on my sid desktop (while I previously did).

Hmm. It seems it doesn’t any more for root-run applications like synaptic, but it does for tty logins. That shouldn’t happen often, but I see no reason why sudo -n reboot/halt would be worse.

#15 Updated by anonym 2014-11-26 15:34:32

  • Status changed from Confirmed to Resolved
  • Assignee deleted (anonym)
  • Feature Branch set to feature/jessie

Fixed in commit 814d2b0. This also closes Feature #5684 and Feature #5878 but only when feature/jessie is merged.

#16 Updated by intrigeri 2014-11-26 15:48:00

  • Status changed from Resolved to In Progress
  • Assignee set to anonym
  • % Done changed from 0 to 60

Reviewing, finding small issues, will file subtasks.

#17 Updated by anonym 2014-11-26 17:12:34

  • Status changed from In Progress to Resolved
  • Assignee deleted (anonym)

#18 Updated by intrigeri 2014-11-26 17:24:14

  • Status changed from Resolved to In Progress
  • Assignee set to anonym

#19 Updated by BitingBird 2015-01-07 18:24:57

  • related to Bug #8372: Shutdown/reboot broken in Jessie added

#20 Updated by intrigeri 2015-01-08 10:25:42

  • related to deleted (Bug #8372: Shutdown/reboot broken in Jessie)

#21 Updated by intrigeri 2015-08-02 08:59:44

  • Target version changed from Tails_2.0 to Tails_1.6

#23 Updated by intrigeri 2015-08-02 09:01:01

  • blocks #8668 added

#24 Updated by anonym 2015-09-08 11:34:33

With all child tickets closed now, I think we’re done.

#25 Updated by anonym 2015-09-08 12:20:44

Hmm. Well, child Feature #8314 (Jessie: integrate shutdown-helper extension with our translation system) is blocked by Bug #8371 (Incomplete screen reader support in Jessie) so perhaps I was wrong to close it. OTOH, I think the blocker is incorrect. The translation system is integrated, and that Orca cannot read the “hidden” button labels is a separate, issue.

#26 Updated by anonym 2015-09-08 16:08:44

So please let me know if you actually think that Bug #10173 should be a child/blocking. I’m not sure I think so, since not even the default GNOME combined shutdown/suspend/etc button is compatible with Orca.

#27 Updated by intrigeri 2015-09-17 00:17:23

> So please let me know if you actually think that Bug #10173 should be a child/blocking. I’m not sure I think so, since not even the default GNOME combined shutdown/suspend/etc button is compatible with Orca.

The main question here is whether the current state on feature/jessie brings a usability regression compared to current Tails/Wheezy. If it does, then Bug #10173 is a blocker. It seems that there’s no clear-cut answer to this:

  • On current Tails/Wheezy, if I start Orca, click on the power button (top-right), and move my mouse down a bit, then the highlighted menu entry is read by Orca (exactly as displayed on screen). Same if I navigate that menu with the keyboard. But one has to already know that one should click at the top-right of the screen first, because there’s no audio feedback when the mouse is over that power button.
  • On current Tails/Jessie, if I start Orca and open the top-right GNOME menu, and then navigate with the keyboard, then our custom reboot/shutdown buttons are read by Orca (with the “push button” suffix, though), which is quite good. But mouse navigation is not possible with Orca in that menu. Given it’s layout, I guess it’s fully expected that if one needs a screen reader, then one must navigate this menu with the keyboard.

So we have a real regression for mouse navigation, but OTOH keyboard navigation seems to be good enough. I suggest we try to patch our extension so that the “push button” suffix is not added — don’t spend more than 20 minutes on that. And then, regardless of the outcome, we can call the current state good enough and close this ticket.

#28 Updated by anonym 2015-09-18 07:06:57

  • Assignee changed from anonym to intrigeri
  • QA Check set to Info Needed

intrigeri wrote:
> > So please let me know if you actually think that Bug #10173 should be a child/blocking. I’m not sure I think so, since not even the default GNOME combined shutdown/suspend/etc button is compatible with Orca.
>
> The main question here is whether the current state on feature/jessie brings a usability regression compared to current Tails/Wheezy. If it does, then Bug #10173 is a blocker. It seems that there’s no clear-cut answer to this:
>
> * On current Tails/Wheezy, if I start Orca, click on the power button (top-right), and move my mouse down a bit, then the highlighted menu entry is read by Orca (exactly as displayed on screen). Same if I navigate that menu with the keyboard. But one has to already know that one should click at the top-right of the screen first, because there’s no audio feedback when the mouse is over that power button.
> * On current Tails/Jessie, if I start Orca and open the top-right GNOME menu, and then navigate with the keyboard, then our custom reboot/shutdown buttons are read by Orca (with the “push button” suffix, though), which is quite good. But mouse navigation is not possible with Orca in that menu. Given it’s layout, I guess it’s fully expected that if one needs a screen reader, then one must navigate this menu with the keyboard.

I was unaware of keyboard navigation. Ok, then the situation isn’t so bad.

> So we have a real regression for mouse navigation,

I sort of fixed it in:

01f67bf Trigger accessibility events for Restart/Power Off on mouse hover.


It’s a bit clunky. Please give it a try and tell me what you think. We might want to revert this given how the key focus stays, so there can be two seemingly selected elements at the same time (one of the buttons via keys, one via the mouse).

> but OTOH keyboard navigation seems to be good enough. I suggest we try to patch our extension so that the “push button” suffix is not added — don’t spend more than 20 minutes on that. And then, regardless of the outcome, we can call the current state good enough and close this ticket.
Fixed in

eab3a6e Simplify accessibility notification for Restart/Power Off.

#29 Updated by intrigeri 2015-09-22 02:52:38

  • Assignee changed from intrigeri to anonym

>> So we have a real regression for mouse navigation,

> I sort of fixed it in:

Yes, “sort of”: sending accessibility events may be useful, but it doesn’t make the GUI discoverable with the mouse only given the complex layout.

> It’s a bit clunky. Please give it a try and tell me what you think. We might want to revert this given how the key focus stays, so there can be two seemingly selected elements at the same time (one of the buttons via keys, one via the mouse).

Reading that, and without testing yet, it indeed feels it’s not a clear cut improvement, especially considering it’s not clear to me that this is going to be useful in practice (see above). So I’m in favour of a revert right now.

>> but OTOH keyboard navigation seems to be good enough. I suggest we try to patch our extension so that the “push button” suffix is not added — don’t spend more than 20 minutes on that. And then, regardless of the outcome, we can call the current state good enough and close this ticket.

> Fixed in
>

> eab3a6e Simplify accessibility notification for Restart/Power Off.
> 

I find commit:eab3a6e a bit scary, but that’s because I lack expertise in this area so I am not able to evaluate, with enough self-confidence, the side-effects of set_accessible_role(Atk.Role.UNKNOWN): we’re basically removing information here, and I’ve no idea what else could be using that information; e.g. there must be a11y tools to get some kind of map/overview of a GUI, and knowing what widget is of what kind, and how it can be interacted with, seems to be potentially a pretty important part of this, no?

#30 Updated by anonym 2015-09-22 15:03:06

  • Target version changed from Tails_1.6 to Tails_1.7

#31 Updated by anonym 2015-10-05 01:27:29

  • Assignee changed from anonym to intrigeri

intrigeri wrote:
> >> So we have a real regression for mouse navigation,
>
> > I sort of fixed it in:
>
> Yes, “sort of”: sending accessibility events may be useful, but it doesn’t make the GUI discoverable with the mouse only given the complex layout.
>
> > It’s a bit clunky. Please give it a try and tell me what you think. We might want to revert this given how the key focus stays, so there can be two seemingly selected elements at the same time (one of the buttons via keys, one via the mouse).
>
> Reading that, and without testing yet, it indeed feels it’s not a clear cut improvement, especially considering it’s not clear to me that this is going to be useful in practice (see above). So I’m in favour of a revert right now.

As you might guess, I’m rather happy to revert this. Done!

> >> but OTOH keyboard navigation seems to be good enough. I suggest we try to patch our extension so that the “push button” suffix is not added — don’t spend more than 20 minutes on that. And then, regardless of the outcome, we can call the current state good enough and close this ticket.
>
> > Fixed in
> > […]
>
> I find commit:eab3a6e a bit scary, but that’s because I lack expertise in this area so I am not able to evaluate, with enough self-confidence, the side-effects of set_accessible_role(Atk.Role.UNKNOWN): we’re basically removing information here, and I’ve no idea what else could be using that information; e.g. there must be a11y tools to get some kind of map/overview of a GUI, and knowing what widget is of what kind, and how it can be interacted with, seems to be potentially a pretty important part of this, no?

Probably, yes. I do not know how to otherwise make orca not say “push button”, as you requested. Reverted!

So, we’re back at what you described in Bug #8302#note-27. My feeling is that I’ll waste a lot of time trying to improve the situation, and IMHO the situation is quite good as it is (per your comment), so I think we can accept the situation as it is and close this ticket. Thoughts?

#32 Updated by intrigeri 2015-10-05 05:02:38

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • QA Check changed from Info Needed to Pass

Yes, the current situation is good enough => closing.