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
Totally agree :). Marking as NEW (and as enhancement request). Kind regards, Joren
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
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
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?
(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
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.
(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
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.
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.
(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
(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.
@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
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
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?
@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