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 519015 - the filename should be selected
the filename should be selected
Status: RESOLVED DUPLICATE of bug 458188
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.12.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2008-02-27 09:32 UTC by Sebastien Bacher
Modified: 2011-02-22 19:45 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Sebastien Bacher 2008-02-27 09:32:26 UTC
The bug has been described on https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/195598

"When you bring up the gtk_open dialog the location bar gets by default the first item on the list which can be opened. This can be very handy if that file happens to be the same one you want to open,
however if you wanted to open something else, you have to manually erase the location bar and then retype whatever you wanted.
An easy fix for this, would be for the content of the location bar to be selected by default, that way if you want to type something else
the text would be automatically replaced, without requiring the user to press backspace repeatedly.

This bug is especially annoying if you happen to be a keyboard only user (being it by choice or necessity).

Steps to reproduce this bug execute the following code on the console:

mkdir ~/somefolder
echo "some text" > ~/somefolder/firstone
echo "some text" > ~/somefolder/secondfile
echo "some text" > ~/somefolder/yetanother
echo "some text" > ~/somefolder/lastone
gedit ~/somefolder/firstone

1. In gedit press Ctrl-O to bring up to open-file dialog
2. If there is a location bar go to point 4, else go to point 3
3. Press Ctrl-L to bring up the location bar, then press escape to close the dialog and go back to point 1
4. The item "firstone" is in the location bar, however lets say you were actually interested in opening "secondfile",
    you need to delete the text and then press "s" for the location bar to complete "secondfile" for you, if the
   text were selected by default then you would only need to press "s" (no need to delete the text).

I hope this explanation was clear enough, although this bug might seem unimportant to some, it slows down
a lot one's workflow, especially if working with keyboard only, for example in kiosks where there is no mouse
and frequently not even home/end keys, so you have to delete character by character."
Comment 1 Kalin Agrawal 2011-02-18 18:42:17 UTC
Terminology: Pre-selection of file is when the file in the scrollable file list is already selected.  Pre-entry of filename is when the text name of a file is already entered in the location bar.

*** This bug also contradicts expected behavior that is provided with the autocomplete (auto-complete) in the location bar.  The dialog box should not have any pre-entered filename in the location bar, nor should it have any pre-selected file in the file list. ***

* Furthermore, as far as I can tell, the pre-entry only occurs when there are NO DIRECTORIES in the current directory.  However, the very first directory IS pre-selected in the file list below.  This is inconsistent behavior.  My suggestion above would do away with this issue, too. *

...

When the location bar is empty and you start typing, then it starts guessing what you want, along with tab-completion.  Good.  Standard workflow should be that you press Ctrl-o and then start typing the filename or path to filename as if you were typing in a terminal, for example, with the drop-down tab completion available.  

However, this bug is that there is a pre-entered filename in the location bar initially.  In my opinion, there should be NO file pre-selected, and NO filename pre-entered in the location bar.  As far as I can see, the ONLY reason one would want that pre-selection/pre-entry is if one repeatedly opened the VERY FIRST file of directories that have no subdirectories, for every time one pressed Ctrl-o.  That is very unlikely!  :-)  (As far as I can see, there is no other method for choosing which file is pre-selected/pre-entered, such as MRU.)

***  So, my suggestion would be that we simply do away with having any files pre-selected or filenames pre-entered at all -- why even bother?  Skip the "select-all" by default, because that's just a workaround for the main issue. ***
Comment 2 Federico Mena Quintero 2011-02-22 19:45:06 UTC

*** This bug has been marked as a duplicate of bug 458188 ***