After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 308326 - Expanding "Browse for other folders" expander should move focus to browsing widgets
Expanding "Browse for other folders" expander should move focus to browsing w...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
unspecified
Other All
: Normal normal
: Small fix
Assigned To: gtk-bugs
gtk-bugs
: 308331 352074 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-06-19 19:44 UTC by Thomas M. Hinkle
Modified: 2017-08-31 18:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas M. Hinkle 2005-06-19 19:44:44 UTC
Distribution/Version: ubuntu hoary

Steps to reproduce bug:

1. Choose "Save" from a GNOME/GTK application
2. Type Alt-B to open the "Browse for other folders..." expander
3. Start typing name of folder I want to browser to.
4. Discover focus has not moved! Alas, I'm typing over my file name.

Expected behavior: 
The focus should move to the treeview of filenames (on the righthand side) when
I expand the browse widget. It should go there (and not to the bookmarks on the
left) since I could access the bookmarked folders more quickly by typing "Alt-F"
and seeing the folders.

Further confusion is caused by the folder selector being desensitized.  Why
can't I use this convenient menu bar anymore? If I change my mind and decide I
want a bookmarked folder after all, I no longer have a fast keyboard way to do
so (Alt-f + arrows).

This is all a special case of a more generic bug in the file selector: there are
no mnemonics to allow me to get quickly to the treeview showing the current
directory. This is a problem because there are so many controls in the view that
tabbing between e.g. the filename and the view is not efficient as it was, say,
in the Mac OS 8 file selector.
Comment 1 Matthias Clasen 2005-06-20 03:14:10 UTC
*** Bug 308331 has been marked as a duplicate of this bug. ***
Comment 2 Federico Mena Quintero 2006-08-21 16:12:59 UTC
*** Bug 352074 has been marked as a duplicate of this bug. ***
Comment 3 gnutter 2009-07-18 17:13:50 UTC
I would suggest the bug here is that Alt-b is a short-cut to the control that causes the the chooser to change mode (dropped or not) and that the focus should transfer to that control, not somewhere else.

This would take focus off the hightlit part of the filename and prevent the stated accidental overwriting.

It is very true that there is not simple way to get to the file list without the mouse. One reason for this is not only the number and order of the controls on the dialogue but the inconsistent use of tab and up/down arrows generally.

In the initial state the tab key gains me a hint saying "No match" , alternatively a down arrow takes me to "Browse for... " control ... then the pathbar ... then somewhere where the focus is not apparent (can't work out where) ... then whoops ! ....I'm now on the first of my bookmarks and the file list has jumped to display its contents. 

The latter change is quite a surprise and it takes a while to reassess where one is.



This is all a fundamental issue in gkt+ and I should probably open another bug on that, this bug is just a consequence of it.

One way to give this easy access would be to add a label over the file list which responds to Alt-f by setting focus to the file list. This is itself a cludge and may require a pseudo label if the label cannot be made reactive.


It would seem a minimum fix is to respect the focus moving to the control that is activated by Alt-b (there are further inconsistencies here with the mouse and focus).

Comment 4 gnutter 2009-07-18 17:18:51 UTC
Mouse and focus inconsistency:

click on Browse... does not steal focus from filename input but if focus is on the file list that focus is lost. However, it does not go to the Browse control. 

In fact it seems nothing has the focus at this point. :?
Comment 5 Daniel Boles 2017-08-31 18:57:20 UTC
This is obsolete: the only reference to any Expander in the FileChooser widgets now (even in GTK+ 2.24) is an unused #include in gtkfilechooserdefault.c