Tails

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

• File gnome-shell-extension-shutdown-helper-0.1.tar.gz added

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.

#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

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

• File shutdown-helper.png added

#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

#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

#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.