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 136077 - No way to open hidden files
No way to open hidden files
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.3.x
Other All
: Normal major
: ---
Assigned To: Federico Mena Quintero
Federico Mena Quintero
: 136775 138427 138956 148336 148339 148341 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-03-03 16:02 UTC by Peter O'Shea
Modified: 2011-02-04 16:16 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description Peter O'Shea 2004-03-03 16:02:44 UTC
Trying out the new gtk file-selector with gedit, if I want to open a hidden
file, it seems to be impossible.  

1. Hidden files don't display in the right-hand files/folders box, even if
"All Files" is selected.

2. There's no place to type in the file name, even if you know it.

So how am I supposed to open my .cshrc file for editing?  

This is using gtk+-2.3.5.
Comment 1 Federico Mena Quintero 2004-03-10 17:21:08 UTC
*** Bug 136775 has been marked as a duplicate of this bug. ***
Comment 2 Federico Mena Quintero 2004-03-10 19:50:23 UTC
In the location dialog, we need to do something like

if (is_dotfile (filename))
  _gtk_file_system_model_set_show_hidden (model, TRUE);

and *then* select the typed filename in the file list.
Comment 3 Peter O'Shea 2004-03-10 20:28:29 UTC
Is the location dialog the one you get when you type Ctrl-L?  How does
a user know about this key combination?  It seems like an undocumented
power-user feature.  

There should be a way to do this without knowing special keypresses,
shouldn't there?  It should be obvious from looking at the
file-chooser dialog.
Comment 4 bugzilla.gnome.org 2004-03-10 21:02:19 UTC
First: not beeing able to open some important files on my machine I
consider a rather critical bug. Could somebody please change Severity?


Second: Even If one figures out the CRTL+L trick one cannot just
browse through available dot files like in the old file chooser.

Imagine I want to edit a config file but I am not exactly sure whots
its name is:

In the old one I could do something like

- enter ".li" in the location bar and hit TAB
  -> the file (and directory) list updates and shows me all files
starting with ".li" Oh, so many?

- now I can continue typing ".lin" and hit TAB again to further filter
the list of available files

- continue until I have found the one file I'm looking for


With the new Popup I do have tab completion but since it does not
affect the list of displayed files I have to guess the right file name
to find it.

This happens not only with dot files but whenever I try to use the
location popup to find a file. And I always try to use the location
popup since I'm faster typing than using the mouse and scroll through
endless lists and often I have my hands on the keyboard anyway and
stopping and grabbing the mouse stops my work flow.

This is a big step backwards in usability IMHO.

Comment 5 Peter O'Shea 2004-03-10 21:20:03 UTC
I agree, changing to critical.

Tab-completion I also consider to be a power-user feature.  This
should be something that anyone can figure out, without having to read
the documentation.

How about a button or checkbox to turn on or off the display of hidden
files?
Comment 6 Morten Welinder 2004-03-12 00:39:11 UTC
"critical" is defined as involving data loss or making the whole system
unstable.  It's specifically not defined as "irritates me a lot".

In my opinion, the solution is to make a context menu that allows
turning on "show hidden".  With 2.4.0 in strings freeze, we cannot
translate that for now.

I'm not 100% sure whether such a context menu is a file chooser or
an application job, though.
Comment 7 Peter O'Shea 2004-03-12 14:37:41 UTC
I stand corrected.  I didn't open the bug, though, because it
irritates me a lot.  I know how to use a command line to get around
it.  It's the people who don't who will be irritated.

Where would the context menu be located?  IMHO, whatever the solution
is, it needs to be visually obvious in the default dialog.  Or is
there a logical way to add it to the file-types dropdown?

I.e., the dropdown might include:
Normal files + hidden
Normal files
Text files

when called for opening a text file.  Obviously that wording needs
improvement.

Comment 8 Morten Welinder 2004-03-12 14:47:46 UTC
Hidden files could have been handled via the file filter but for
reasons I don't know it is a separate layer of filtering.

Hidden directories could not have, as currently directories are not
subject to filtering beyond the hidden/non-hidden level.
Comment 9 Stephane Chauveau 2004-03-17 19:28:43 UTC
I have 2 arguments against using the filetype drop-down menu to
show/hide the hidden files.

(1) Regular filters should be applicable to hidden files as well.
That won't be the case if the only way to show hidden files is via the
filter "all files + hidden". 
   
(2) The filter "all files + hidden" would have to be the only filter
also applicable to directories. 
Changing the 'file filter' to be able to see hidden directories might
not be the obvious choice for most users (since the current filter is
likely to match the file type they are looking for).
Comment 10 Federico Mena Quintero 2004-03-29 18:39:24 UTC
*** Bug 138427 has been marked as a duplicate of this bug. ***
Comment 11 Maynard Kuona 2004-03-29 20:28:07 UTC
I have a suggestion. If I type, for example, ~/.bash_profile to open that file,
and there is a match, I think this should be opened immediately from the
location bar, rather than having to go back to the selector, then clicking open
again. Only where there is no match should it take you back to the selector with
the rest of the hidden files showing. same goes for regular (non-hidden) files.
It should just parse the entry, and take you as far as it can. i.e., if I type
~/.bash then open,  it should show the home directory in the selector box, and
show hidden files, or actually, just those files beggining with .bash.
Comment 12 Peter O'Shea 2004-03-29 20:43:17 UTC
If the location dialog (Ctrl L) is the solution for this bug, how does the
average user know that it's there?  
Comment 13 Maynard Kuona 2004-03-29 21:41:07 UTC
I think we need to find a way of adding the location dialog there in a way that
makes it simpler to discover. (Ctrl L) is very unfamiliar with anyone who used
windows for example. Not to say we should ape the windows one, but just make it
easy to find. 
Comment 14 Federico Mena Quintero 2004-03-31 19:07:21 UTC
I'm working on this.
Comment 15 Federico Mena Quintero 2004-04-02 00:37:57 UTC
Fixed on CVS.  The mechanism to handle hidden files is in place now --
right-click on the file list and toggle the "Show Hidden Files" option, or
select a dotfile in the C-l dialog.

Note that this doesn't work in gedit, because there is a bug in _gtk_fnmatch()
in that it effectively always turns on the FNM_PERIOD optio (for GtkFileSel's
purposes), but GtkFileChooser doesn't like this.  I'll file a bug about this.
Comment 16 Federico Mena Quintero 2004-04-06 15:28:04 UTC
*** Bug 138956 has been marked as a duplicate of this bug. ***
Comment 17 Vincent Noel 2004-07-24 17:19:35 UTC
*** Bug 148341 has been marked as a duplicate of this bug. ***
Comment 18 Vincent Noel 2004-07-24 17:20:39 UTC
*** Bug 148339 has been marked as a duplicate of this bug. ***
Comment 19 Vincent Noel 2004-07-24 17:20:55 UTC
*** Bug 148336 has been marked as a duplicate of this bug. ***
Comment 20 Peter O'Shea 2004-08-17 15:24:34 UTC
I still think this isn't very discoverable on the part of ordinary users.  I've
never before come across any list box the contents of which could be modified by
right-clicking.