Bug 70637 - StartCenter: select a recent used file and hit Enter ...
Summary: StartCenter: select a recent used file and hit Enter ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Start-Center
  Show dependency treegraph
 
Reported: 2013-10-19 04:36 UTC by Jean-Baptiste Faure
Modified: 2014-07-24 18:45 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Baptiste Faure 2013-10-19 04:36:30 UTC
Steps to reproduce:
- launch the master
- in the StarCenter select a file from the recent used files: do only one mouse click on the thumbnail of the file
- hit the Enter key

expected behavior: the file is opened
current behavior: the filepicker is opened 

The bug is that the thumbnail does not get the focus when you select a file. You can see that the "Open" button is still selected when you click on a thumbnail.

Fixing this bug will partially help to improve the navigability in the StarCenter. See bug 70449

Best regards. JBF
Comment 1 Jorendc 2013-10-20 08:41:58 UTC
Totally agree :). Marking as NEW (and as enhancement request).

Kind regards,
Joren
Comment 2 Jean-Baptiste Faure 2013-10-20 09:31:33 UTC
Hi Joren,

I think we should consider this as a bug because selecting a recent used file using the mouse does not really select it. I can't believe that it is designed this way. 

Best regards. JBF
Comment 3 Cor Nouws 2013-10-20 19:30:14 UTC
there is some weird behaviour in the template manager too with getting the focus. Might well be some related cause (new widget tooling)
   https://bugs.freedesktop.org/show_bug.cgi?id=70692
Comment 4 Rodolfo 2013-11-24 03:42:03 UTC
The behaviour was changed to open a recent file with a single click since 2013-11-07 .

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a29c9eff781fd6bceee5078669a53c52086b5664

Should we close this report?
Comment 5 Jean-Baptiste Faure 2013-11-24 08:17:49 UTC
(In reply to comment #4)
> The behaviour was changed to open a recent file with a single click since
> 2013-11-07 .
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=a29c9eff781fd6bceee5078669a53c52086b5664
> 
> Should we close this report?

No single click does not fix the problem, because you must be able to open a recent file without using the mouse.

Best regards. JBF
Comment 6 retired 2013-11-24 11:26:59 UTC
JBF: I'm confused. Testing with LO Version: 4.3.0.0.alpha0+
Build ID: 73342dbb82ba074d01962359dac50fb2aa36cbeb
TinderBox: MacOSX-x86@49-TDF, Branch:master, Time: 2013-11-22_07:09:14

Behavior on OS X 10.9:

* Open LO
* tab trough the options (first open / templates) then lo components
* hit tab 10 times to get into the document selection

Now I can navigate with the keyboard arrows and open a document with enter.

So basically WORKSFORME.

JBF, do you agree? Please set the bug accordingly. Setting to needinfo for now.
Comment 7 Jean-Baptiste Faure 2013-11-24 11:59:31 UTC
(In reply to comment #6)
> [...]
> * Open LO
> * tab trough the options (first open / templates) then lo components
> * hit tab 10 times to get into the document selection
> 
> Now I can navigate with the keyboard arrows and open a document with enter.

The most important information here is "hit tab 10 times" yes, 10 times : you fall on the bug 70449

> 
> So basically WORKSFORME.

I do not think that needing to click 10 times allows to say "it works" ;-)

That said, this bug report has been filed before the single click to open a recent document has been implemented in 4.2.0 version. So this bug is now linked to bug 71957.

I think that for professional use it is needed to be able to open a recent file without using the mouse and without having to hit a key 10 times before the focus reaches the recent files area.

Set back status to NEW

Best regards. JBF
Comment 8 retired 2013-11-24 12:13:49 UTC
Agreed.

So maybe a good solution would be to divide into two sections (left column and the right column with the recent documents).

Then ideally tab would do nothing more than switch between those two sections and all other navigation would be done with arrow keys.

Does that sound applicable to your ears? I think it could be a nice implementation.
Comment 9 V Stuart Foote 2013-12-17 14:04:44 UTC
Rather than adjusting TAB ad Cursor use, implementing behavior of special use navigation keys, F10 and F6 for the GTK UI Widgets would go a long way to cleaning up keyboard navigation.

F10 key toggles between the active element and the main menu, while F6 advances through the menus.  Currently on StartCenter F10 toggles from File on Menu <-> Open File on the StartCenter GTKbox.  It does not even function when in the GTK Widget based Template Manager.

Implementing F6 key to move F10 toggle amongst the GTKbox elements would allow progression through the SideBar keys--rather than 10 TABs to reach ThumbnailView.  It would also allow us to directly toggle into the Thumbnail view when that is the active box.
Comment 10 Jean-Baptiste Faure 2013-12-17 18:43:30 UTC
(In reply to comment #9)
> [...] Currently on StartCenter F10 toggles from File on Menu <-> Open File on 
> the StartCenter GTKbox.

What do you mean by "Currently" ? The StartCenter in LO 4.2 in its current state or the StartCenter in the current stable version (4.1)? When building LibreOffice 4.2 on Ubuntu / Unity, F6 and F10 do nothing (for me) in the StartCenter.

Best regards. JBF
Comment 11 V Stuart Foote 2014-01-04 16:54:22 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > [...] Currently on StartCenter F10 toggles from File on Menu <-> Open File on 
> > the StartCenter GTKbox.
> 
> What do you mean by "Currently" ? The StartCenter in LO 4.2 in its current
> state or the StartCenter in the current stable version (4.1)? When building
> LibreOffice 4.2 on Ubuntu / Unity, F6 and F10 do nothing (for me) in the
> StartCenter.

Working in both Windows, and Linux (Fedora 19 w/GNOME DTE) with both LibreOffice 4.2.0 rc1+ TB builds and current TB builds of master. Don't normally look at the 4.1 builds.

<F10> and <F6> now have their default behavior and toggle between the Main Menu (File dropdown) and the Open File GtkButton of the Start Center.

Land on the Open File button, issue a <Shift><TAB> to position backwards onto the Recently Used Documents thumbnail view list.  There, with current builds of 4.2.0 and master, the <F10> now correctly toggles between the main menu and the thumbnail view list. And cursor movement and selection with enter key works correctly.

I still believe refactoring the GTK UI to recognize the GtkBox elements for <F6> landings the recent documents would improve the UX.  At this point with 4.2.0 rc1+ and master--the only <F6> landings are the main menu and the File Open GtkButton of the StartCenter--and either a single <Shift><TAB>, or 10 <TAB>s is needed to reach the recent documents list.
Comment 12 V Stuart Foote 2014-01-04 17:57:21 UTC
@JBF -- please retest against current 4.2.0 rc1+ and master build.

On other OS, the issues of original post are resolved, and this issue should be closed.

Stuart
Comment 13 Jean-Baptiste Faure 2014-01-05 08:28:18 UTC
Indeed, it is fixed by the mean of the single clic to open a recent document.
I guess that, if bug 71957 is fixed someday, this bug should be reopened unless selecting a recent file by clicking on it (only one click) gives it the focus. That was not the case when I filed this bug report.

Best regards. JBF
Comment 14 retired 2014-01-05 09:10:27 UTC
 V Stuart Foote: Do I understand Comment 11 correctly, that you suggest tag should be moving from one box to the next and the remaining navigation should be done with the arrow keys?

If so, I totally agree with that. Special commands like "shift + tab" are barely known and won't be used a lot. So how to proceed? Should we open a separtate bug for that?
Comment 15 V Stuart Foote 2014-01-05 16:30:49 UTC
@Foss
(In reply to comment #14)
>  V Stuart Foote: Do I understand Comment 11 correctly, that you suggest tab
> should be moving from one box to the next and the remaining navigation
> should be done with the arrow keys?

Yes, the migration of GtkWidget UI based GUIs as used now for the StartCenter present new challenges for the devs as they need to implement logical keyboard navigation in addition to a mouse-driven GUI. 

A current fully implemented example would be the keyboard behavior in the GtkWidget based SideBar where landing on the Deck with <F6> movement a <TAB> enters the Title bar of the first content panel on the deck. Cursor <U,D> moves to next content panel title bar, or <TAB> enters the content panel, and additioonal <TAB> progress to command groupings, Cursor <U,D,L,R> position on specific buttons and list objects, <Enter> activates.
<ESC> -- leaves current content panel and enters its title bar, <U,D> moves to next content panel title.

This layout diagram from AOO gives an idea of the sidebar GtkWidget elements that must be navigable.
https://wiki.openoffice.org/wiki/File:SidebarNames.png

> 
> If so, I totally agree with that. Special commands like "shift + tab" are
> barely known and won't be used a lot.

In reality they are well known to keyboard based users. Because for consistency of use, keyboard navigation is fairly well standardized in the OO/AOO/LibreOfice family. 

As it is critical for support of Assistive Technologies it has to be well documented and is a major component of the QA process with each release cycle. Fortunately the norms are fairly well documented as noted in these LibreOffice references:

https://help.libreoffice.org/Common/Shortcuts_Accessibility
https://help.libreoffice.org/Common/General_Shortcut_Keys_in
https://help.libreoffice.org/Writer/Shortcut_Keys_for_Writer
https://help.libreoffice.org/Writer/Navigating_and_Selecting_With_the_Keyboard

and similar for other modules.  Divergence from these UX norms require QA actions to adjust the program or change documentation. 

>...  So how to proceed? Should we open a
> separtate bug for that?

Already open as bug 71764, I've added you to CC for it.

Stuart