[FFe] HUD hotkey assignment is suboptimal

Bug #1551986 reported by Will Cooke
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)
Won't Fix
High
Unassigned
Xenial
In Progress
High
Unassigned
ubuntu-docs (Ubuntu)
Won't Fix
High
Unassigned
unity (Ubuntu)
Won't Fix
High
Unassigned
Xenial
Won't Fix
High
Unassigned

Bug Description

= Proposed Change =
The suggestion (subject to Design approval) is to remap HUD to alt-space and also expose window controls in to the HUD such that people used to using "alt-space n"to minimize a window still can.

= Motivation =
Having HUD trigger on alt tap is not working so this is a request to change it. It conflicts with several other applications such as full screen games, etc.

= Potential Regressions =
* Hud fails to open on alt+space
* Hud fails to show normal menu entries for gtk applications
* Hud fails to show normal menu entries for qt applications

== Links to mailing lists ==
* https://lists.ubuntu.com/archives/ubuntu-translators/2016-April/007138.html
* https://lists.ubuntu.com/archives/ubuntu-doc/2016-April/019870.html

Related branches

Will Cooke (willcooke)
Changed in unity (Ubuntu Xenial):
status: New → Confirmed
assignee: nobody → Andrea Azzarone (azzar1)
Will Cooke (willcooke)
tags: added: u7-trello-import
tags: removed: u7-trello-import
Will Cooke (willcooke)
Changed in unity (Ubuntu Xenial):
status: Confirmed → In Progress
Andrea Azzarone (azzar1)
Changed in hud (Ubuntu Xenial):
assignee: nobody → Andrea Azzarone (azzar1)
status: New → In Progress
Revision history for this message
Will Cooke (willcooke) wrote :

alt-super is not really working for windows controls because it's two modifiers. Looking for an alternative....

Andrea Azzarone (azzar1)
Changed in bamf (Ubuntu Xenial):
assignee: nobody → Andrea Azzarone (azzar1)
Andrea Azzarone (azzar1)
Changed in libwnck (Ubuntu Xenial):
assignee: nobody → Andrea Azzarone (azzar1)
status: New → In Progress
Andrea Azzarone (azzar1)
Changed in bamf (Ubuntu Xenial):
status: New → In Progress
Andrea Azzarone (azzar1)
no longer affects: libwnck (Ubuntu)
no longer affects: libwnck (Ubuntu Xenial)
Changed in libwnck3 (Ubuntu Xenial):
status: New → In Progress
assignee: nobody → Andrea Azzarone (azzar1)
Revision history for this message
Andrea Azzarone (azzar1) wrote :

Please find attached a libwnck debdiff. We need this to avoid random "_" chars in the hud.

Andrea Azzarone (azzar1)
Changed in compiz (Ubuntu Xenial):
status: New → In Progress
assignee: nobody → Andrea Azzarone (azzar1)
Revision history for this message
Will Cooke (willcooke) wrote :

Release notes updated to include new default key binding for HUD.

Revision history for this message
Otus (jan-varho) wrote :

This is going to xenial *now*? UI freeze was weeks ago.

Andrea Azzarone (azzar1)
summary: - HUD hotkey assignment is suboptimal
+ [FFe] HUD hotkey assignment is suboptimal
summary: - [FFe] HUD hotkey assignment is suboptimal
+ HUD hotkey assignment is suboptimal
Andrea Azzarone (azzar1)
summary: - HUD hotkey assignment is suboptimal
+ [FFe][UIFe]HUD hotkey assignment is suboptimal
summary: - [FFe][UIFe]HUD hotkey assignment is suboptimal
+ [FFe][UIFe] HUD hotkey assignment is suboptimal
Andrea Azzarone (azzar1)
description: updated
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote : Re: [FFe][UIFe] HUD hotkey assignment is suboptimal

UIFe comment:
This change won't be reflected in the desktop guide, whose final version is currently in the Xenial upload queue. Guess we can live with that - fixing this issue carries probably greater weight.

As regards the new translatable string "Window", you have notified the translators via the ubuntu-translators list. Good. Currently six days remain before "LanguagePackTranslationDeadline" on April 14, so the upload should better be carried out instantly to give the translators a fair chance.

UIFe approved - with some reluctance.

Changed in ubuntu-docs (Ubuntu):
milestone: none → later
Changed in bamf (Ubuntu Xenial):
importance: Undecided → High
Changed in compiz (Ubuntu Xenial):
importance: Undecided → High
Changed in hud (Ubuntu Xenial):
importance: Undecided → High
Changed in libwnck3 (Ubuntu Xenial):
importance: Undecided → High
Changed in ubuntu-docs (Ubuntu):
importance: Undecided → High
Changed in unity (Ubuntu Xenial):
importance: Undecided → High
Changed in ubuntu-docs (Ubuntu):
status: New → Triaged
sadn3s (sadn3s)
description: updated
summary: - [FFe][UIFe] HUD hotkey assignment is suboptimal
+ [FFe][UIFe]
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Vandalism reversed.

description: updated
summary: - [FFe][UIFe]
+ [FFe][UIFe] HUD hotkey assignment is suboptimal
Revision history for this message
Will Cooke (willcooke) wrote :

Window controls to move to <alt> <semicolon> for now. This was chose as it is in a similar post for the majority of keyboard layouts and is near to the space bar.

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote : Re: [Bug 1551986] Re: [FFe][UIFe] HUD hotkey assignment is suboptimal

We have been able to use super+Alt now, so I guess we can go back with the
preferred solution.

Revision history for this message
Amr Ibrahim (amribrahim1987) wrote : Re: [FFe][UIFe] HUD hotkey assignment is suboptimal

The compiz changelog is wrong:

compiz (1:0.9.12.2+16.04.20160412-0ubuntu1) xenial; urgency=medium

  [ Andrea Azzarone ]
  * Show window actions menu on alt+semicolon. (LP: #1551986)

I think it should be alt+super, not alt+semicolon.

Revision history for this message
Amr Ibrahim (amribrahim1987) wrote :

Also in the release notes, "The default window controls change to alt-semicolon", it should be changed to alt+super https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#General

Revision history for this message
Iain Lane (laney) wrote :

I've blocked this change in xenial-proposed. They only got there because the CI train bypasses the unapproved queue.

The FFe wasn't approved so they shouldn't really have been uploaded.

I think it's contentious to make HUD take over what was a bit of window manager functionality, especially so close to release.

Revision history for this message
Adam Conrad (adconrad) wrote :

FWIW, despite the lateness in the cycle, I'm 100% supportive of moving the HUD away from Alt. That was (as has been pointed out) a pretty poor decision from the get-go, and it's the one key I've always had to remap locally to fix.

What I'm not okay with is fixing ONE bad binding by moving TWO. Alt-Space is a well-known binding that people have been using literally for decades.

If you want something that has a comfortably similar feel to Alt-Space, Super-Space is just one key over, and doesn't appear to currently do anything, but please don't break two bindings to fix one. Pretty please. With sugar on top.

Revision history for this message
Will Cooke (willcooke) wrote :

It's worth noting that the current alt-space functionality (move, minimize, maximize etc) will be exposed via the HUD. So that functionality will remain.

Revision history for this message
Luke Yelavich (themuso) wrote :

I have to disagree with this change. It makes sense that window movement related shortcut keys used the super key, however menus are opened with the alt key, i.e alt h for help, alt e for edit, etc. Following that logic, I think it makes sense to leave the window actions menu as alt space, given that the same convention si used in many other desktop environments, and other operating systems.

Revision history for this message
Iain Lane (laney) wrote : Re: [Bug 1551986] Re: [FFe][UIFe] HUD hotkey assignment is suboptimal

On Wed, Apr 13, 2016 at 09:01:54PM -0000, Will Cooke wrote:
> It's worth noting that the current alt-space functionality (move,
> minimize, maximize etc) will be exposed via the HUD. So that
> functionality will remain.

It'll break the existing mnemonics behaviour, unless alt-space, x with
the HUD activates maximise immediately - which would be bad behaviour
for the HUD itself.

I think this is way too close to the release. Can we just fix the hud's
bad default binding to something else or, failing that, back this change
out and work out an acceptable solution for 16.04.1?

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote : Re: [FFe][UIFe] HUD hotkey assignment is suboptimal

I understand and I quite agree that such keybinding replacement could cause some troubles to people who were used to use Alt+Space for such use case (which is historically relevant). I would have preferred to just move the HUD to Super+Space.

However, adding the ability of using the window actions from the HUD is something that doesn't impact with the keybinding change, and also it improves the accessibility for those actions. So you might just ACK the change for BAMF and HUD packages only, without breaking any user habit. While we can delay the default-shortcut for unity and compiz packages.

Revision history for this message
Martin Pitt (pitti) wrote :

For the record, our SABDFL requested this change, so this FFE/UIFE will go in by way of the ultimate power.

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

Moved the UIFe side of things to bug #1570812

no longer affects: bamf (Ubuntu)
no longer affects: bamf (Ubuntu Xenial)
no longer affects: hud (Ubuntu)
no longer affects: hud (Ubuntu Xenial)
no longer affects: libwnck3 (Ubuntu)
no longer affects: libwnck3 (Ubuntu Xenial)
summary: - [FFe][UIFe] HUD hotkey assignment is suboptimal
+ [FFe] HUD hotkey assignment is suboptimal
Revision history for this message
Iain Lane (laney) wrote :

To override the release team, a comment needs to be posted on the bug.

Here's what will happen right now

  - Marco will remove the not-acked parts of Unity and Compiz and re-upload these.
  - I'll unblock bamf and hud - these changes are not-contentious and add window manager controls to the hud. Apparently hud doesn't handle its own default keybinding - who knew? :)
  - Once the new versions of compiz and unity (with bug fixes only) are published in xenial-proposed, I'll unblock those.

If we are formally overridden then the merge proposals should be built again for another upload. If this happens then I would personally prefer that it becomes an SRU so that any unexpected problems don't interfere with the release, but that would no longer be my call.

Ideally (IMO) we'd reverse the decision to take over the window manager's controls shortcut and take our time to figure out another solution for 16.04.1, when we turn on upgrades for everybody.

Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

Have asked for a second opinion. If it can be made to work smoothly with the existing use of alt-space (window actions menu) then I would rather we moved the keybinding NOW and sru'd the final bits later, than try to change the keybinding post release.

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

Wondering about the state of this bug, since we are updating the 16.04 desktop guide and will accomplish an ubuntu-docs SRU before the release of Ubuntu 16.04.1.

HUD is still opened by tapping <Alt>, as is stated both in the "Keyboard Shortcuts" window and at:

https://help.ubuntu.com/16.04/ubuntu-help/unity-hud-intro.html

So, will the 16.04 behavior be changed as an SRU?

Revision history for this message
Andrea Azzarone (azzar1) wrote :

Ubuntu 17.10 will ship with Gnome Shell by default. Given this, we do not plan to work on this bug anymore. Closing.

Changed in unity (Ubuntu Xenial):
status: In Progress → Won't Fix
Changed in unity (Ubuntu):
status: In Progress → Won't Fix
Changed in ubuntu-docs (Ubuntu):
status: Triaged → Won't Fix
Changed in compiz (Ubuntu):
status: In Progress → Won't Fix
assignee: Andrea Azzarone (azzar1) → nobody
Changed in compiz (Ubuntu Xenial):
assignee: Andrea Azzarone (azzar1) → nobody
Changed in unity (Ubuntu Xenial):
assignee: Andrea Azzarone (azzar1) → nobody
Changed in unity (Ubuntu):
assignee: Andrea Azzarone (azzar1) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.