Add the missing keyboard equivalents for menu items

[aksaks]

Provide keyboard equivalents for most, if not all, of the top menu items. For example,"Fine tune all points" does not have a keyboard equivalent.

[Bruno Postle (brunopostle)]

Hi, what would be really useful would be for somene to put together a complete list of operations in the GUI and menus that need keyboard equivalents.

[Joachim Schneider (j-schneid)]

Undo = Ctrl Z is usual. Isn't Ctrl Y usual for redo? (currently Ctrl R).
Save as -> Ctrl-Shift S
In Lists: Select all -> Ctrl A

[Yuv (yuv)]

On November 27, 2010 06:54:13 am Joachim Schneider wrote:
> Undo = Ctrl Z is usual. Isn't Ctrl Y usual for redo? (currently Ctrl R).

sometimes. sometimes it is also CTRL+SIFT+Z, and in Hugin it has been
historically R.

I personally prefer R to Y because Y & Z are interchanged on the keyboards I
use (Swiss and Canadians). If it was CTRL-Y I'd have a total mix up between
redo and undo. Better keep the functionality attached to the Z and Y key
totally unrelated.

> Save as -> Ctrl-Shift S
> In Lists: Select all -> Ctrl A

are there any more functionalities that need a shortcut key?

Yuv

[James Legg (lankyleggy)]

The Gnome Human interface guides say Undo should be Shift+Ctrl+Z, Save As should be Crtl+Shift+S, Update on the old preview should be called Refresh and have the shortcut Ctrl+R. Also, File|Preferences should be Edit|Preferences, and Help|Help should be Help|Contents. Keyboard accelerators and menu layouts are platform specific.

I think Add images should have a keyboard accelerator, maybe Ctrl+I?

The rarely used menu items shouldn't have accelerators, it just adds visual noise to the menus.

Some other potentially useful missing keyboard shortcuts:
Delete on the images list on the Images tab should remove the selected photo from the project.
Delete on the mask list on the masks tab should delete the select mask.
Delete on the control points list on the control points tab should delete the selected control point. It already works on the control points list window though.

There are some keyboard navigation problems too:
On the main window, the toolbar and top level tabs are not keyboard focusable. (The tabs within the camera and lens tab are.)
On the fast preview, it seems impossible to navigate between the tabbed box at the top, the display image toggle buttons, the All/None buttons, and each field of view slider using just the keyboard.
On the old preview, none of the controls respond to tab except the image toggle buttons.
None of the controls on the control point window respond to tab either.
It probably isn't necessary to be able to navigate to the second column on the check lists on the optimiser tabs, if you do then the space bar doesn't toggle the checkbox in the first column, which is unexpected.
The tab order of the buttons at the bottom of the preferences window is not the same as the visual order.

[tmodes (tmodes)]

User Experience Interaction Guidelines for Windows say
Undo: Ctrl+Z
Redo: Ctrl+Y
Refresh: F5

On Windows I can navigate from the tab to the image toggle buttons and the All/None buttons, but not to the view sliders.

[tmodes (tmodes)]

I added similiar feature requests as duplicates (not sure if I catched all). So follow also duplicates for get a complete list.

[Yuv (yuv)]

So there are Gnome Guidelines, and Windows Guidelines, and probably also OSX Guidelines and KDE Guidelines. And in the future there are likely to be iOS, Android, etc. guidelines.

Suggested solution: A lookup table of shortcut, one such table for each guideline, and very picky users can even edit their own version of such a table.

Suggested naming convention for the lookup table file: sxrc/data/shortcuts.PLATFORM.txt with PLATFORM being gnome, windows, etc.

Add a preferences drop-down list that lists all available values of PLATFORM. Default is what is sensible on the platform (assuming the platform can be identified on the first run when no default is set yet). User can ovverride by choosing from the dropdown.

Suggested format for the table: one line per shortcut, tab separated. on the left the current / hard coded shortcut. on the right the platform specific shortcut. what is after an additional tab is ignored (comments).

Code changes:
- add function to parse the shortcuts file
- add lookup function to implement the shortcuts
- change all places of the app where shortcuts are implemented to use the lookup function

Estimated effort?

This is one of the most important "unclean" aspect of the user interface. I would suggest making it a higher priority once a complete list of keyboard shortcuts is assembled.

[Yuv (yuv)]

My analysis was incomplete. It is not just guidelines, it is locale as well - different locale have different keyboard layouts.

so it should be shortcuts.PLATFORM.LOCALE.txt

[J B (buchner-johannes)]

Its not just adding shortcuts.

From my bug report, bug 679973 (it was marked as a dupe of this)
> It is impossible to use hugin with the keyboard only, since tab don't help you along the window, and there are no shortcuts for the buttons in the assistant. Please please improve that.
>
> 1) Jumping to the tabs content area (e.g. using tab)
> 2) Jumping between the buttons (e.g. using tab)
> 3) Maybe shortcuts to the 1-2-3 buttons
> 4) Jumping to and within the menu (e.g. using tab)
>
> For implementation, reading usability guidelines (such as GNOME's or KDE's) is often useful.

So navigation in the GUI, across menu, buttons, fields should also be possible.

[Goat Carrot (360cities)]

So what now? Should I start a list? :-)

[Yuv (yuv)]

yes, please provide a possibly comprehensive list of functions that need a shortcut attached; and the suggested key for the shortcut.

This ticket is incomplete as long as there is no such list. Don't worry about expiration, activity will keep it alive.

[Bruno Postle (brunopostle)]

Basically this usage of the tracker sucks. This bug gets marked as incomplete because the bug doesn't contain any information, however the bugs that are marked as duplicates do contain useful and complete bug reports (e.g Bug #697657). The inevitable result will be that the 'duplicates' get ignored and the 'parent' bug vanishes by default.

It seems to me that the only way around this is to copy and paste any information from one bug to another when marking as duplicate, but this would be tedious and prone to errors.

[Yuv (yuv)]

On January 9, 2011 04:53:02 pm Bruno Postle wrote:
> Basically this usage of the tracker sucks.

No, we just need to fine tune our common understanding of tracker usage.

> This bug gets marked as incomplete because the bug doesn't contain
> any information

it's not a binary flag. It may contain some information, but it is still
incomplete to start coding.

> however the
> bugs that are marked as duplicates do contain useful and complete bug
> reports (e.g Bug #697657).

unmark bug #697657 from duplicate status and let it go the normal ticket life
cycle.

duplicate marking has the advantage that if somebody picks up the issue, they
will see also the related issues and may provide a solution for all of them
together. But if this does not work, then let those bugs that hurt enough for
information to be complete go ahead on their own.

The next task for this ticket is still listed in comment #1. Without that,
there is not much that can be done about this request.

> The inevitable result will be that the
> 'duplicates' get ignored and the 'parent' bug vanishes by default.

wrong. First of all, it takes two months of inactivity for a 'parent' bug to
vanish. You can set a 'cron job to ping it' every 50 days and it will not
vanish.

simply keeping it alive and ignoring it is no better solution.

second, if you don't want it to vanish, assign it to yourself. if I am not
mistaken, assigned bugs don't expire. the status will still reflect the
reality that information is missing. But somebody will have taken
responsibility to collect this information.

or to keep it alive and ignore it which, again, is just cosmetic and clogs the
view from those bugs that actually attract real action.

Does the lack of keyboard shortcuts pain you? it does not pain me. If it
would, I would know which keyboard shortcuts that I am missing and I could
list them out of the top of my head.

> It seems to me that the only way around this is to copy and paste any
> information from one bug to another when marking as duplicate, but this
> would be tedious and prone to errors.

don't do that. just un-duplicate them (e.g. specify 'duplicate no' in an
email to the bug) and they will go the normal ticket lifecycle again. before
doing that, make sure they are all tagged the same way.

Actually I am tempted to try it. With the next email message I will:
* tag all bugs marked as duplicate of this bug with the tags 'keyboard' and
'usability'
* unmark them as duplicate

If the system is well designed, I would expect their status to change to 'New'
(duplicate bugs have 'Invalid' status) and they can be triaged again for
completeness etc.

Just to back up the links, those are
    * Bug #678929
    * Bug #679831
    * Bug #679834
    * Bug #679836
    * Bug #679841
    * Bug #679900
    * Bug #679938
    * Bug #679973
    * Bug #697649
    * Bug #697657

Yuv

 tag: keyboard usability

[Yuv (yuv)]

everything worked as planned. I'm impressed. Now let's see which bugs get attention and which ones are just a drag.

[tmodes (tmodes)]

I'm not pleased. What should this?
First you reverted the work I did to collect all tickets to one. So I'm asking myself why should I triage tickets if you revert all changes with one email. I have not the time to do the same task again and again.
Second now there are several open tickets which are duplicates of the same issue, e.g. select all Ctrl+A is now several times in the tracker.

[Bruno Postle (brunopostle)]

Marking a bug as duplicate effectively vanishes any unique information in that report, since the tracker doesn't support merging bugs.

Yuval un-duplicated the reports to fix this, but this means that there is now no connection between them. Maybe the solution is to mark the Ctrl+A bugs as duplicates of each other, but use a tag to group all these keyboard-command bugs together?

[tmodes (tmodes)]

> Marking a bug as duplicate effectively vanishes any unique information
> in that report, since the tracker doesn't support merging bugs.

What do you mean with "vanishes"? There is no information vanished. If you mark a bug as duplicate, the original bug site shows a link to the duplicate. So it's easy to follow the links to the duplicates.
I find this is easier than using the search function, which I don't like so much, because it misses some functionality, e.g. an easier filter possibility; or an further example if you search for "keyboard" (simple search) you get only 9 results; only when you search for tag "keyboard" you get all 11 bugs.

[David Haberthür (habi)]

The fast preview window on the Mac should close with ⌘+W, at the moment it doesn't, making a trip to the mouse necessary

[Yuv (yuv)]

Apology for not replying on this as soon as I should have; and for the "displeasure" caused.

First of all, an explanation of what I did with my single email. I did not undo your work, Thomas. I backed it up in comment #13 - all the bugs that were marked as duplicate are listed there. With a single email it could be re-done. Then I tagged all these reports with "keyboard" and "usability", so that if you look for those two tags, you should get that same list (plus other relevant bugs). Last, I unduplicated them.

I unduplicated them, because we are still unclear about what represents a duplicate.

If two reports say that A is missing, then they are obviously duplicates. But if one report says that A is missing, and another report says that A and B are missing, then then the duplication is only partial; and if A is more important than B, then the report saying that A is missing should not be marked as duplicate of the report that says that A and B are missing.

In this specific case, we have a bug saying that the whole alphabet is missing. If every letter of the alphabet had the same priority, then marking them all as duplicate makes sense. But here we have different priorities (some missing keyboard shortcuts are very annoying while others are a minor nuisance) and bundling them all together is the wrong decision. If users would perceive the whole alphabet as equally important, they would provide the list that Bruno asked for. Instead, they provide a list of what is priority for them, and that's fine. It helps fix some of the bugs marked as duplicate, but not this overall blanket requirement that obviously is not even important enough for the original bug reporter to follow up on. So let it expire; and let those reports that get attention be fixed.

Last but not least, "expired reports". Expired reports do not vanish. Nothing is deleted in this system, and indeed you can find and link to expired reports as you would to reports with every status. Indeed it is easier to follow a link than to use the search function which is less than perfect. Duplicates are automatically linked, so it is easy to follow the links to the duplicates. But comments links to them as well. Comment #19 does what the duplicates list does for this specific case, without preventing the more important bugs from this list to have a life of their own and be addressed and fixed on a higher priority than this bug report. I think that marking them as duplicates is the wrong solution; listing them as overlapping in a comment is what I would suggest to do, and what I did in comment #13. Let's use the duplicate mark for real duplicates?

[Launchpad Janitor (janitor)]

[Expired for Hugin because there has been no activity for 60 days.]