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 582989 - Navigating up in the pathbar makes the view ambiguous
Navigating up in the pathbar makes the view ambiguous
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
3.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 320247
 
 
Reported: 2009-05-17 21:47 UTC by David Woodhouse
Modified: 2018-05-02 14:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Woodhouse 2009-05-17 21:47:39 UTC
I had an interesting phone call from my father this morning, who was confused
by the GTK file dialog box. Upon looking harder, I understand the cause of his
confusion.

If you go deep into a directory hierarchy, the names of the directories you've
entered are shown on the screen, each in a little box. New boxes are added on
the right-hand side as you enter new directories.

If you then come back _up_ to a parent directory, those boxes on the right-hand
side don't go away. See screenshot at http://david.woodhou.se/filedlg.png for
example -- it's actually looking at the ~/Download/ directory but you could be
forgiven for thinking that it's in the ~/Download/solos-pci-0.07/soloscli/
directory.

After returning to a parent directory, why do we keep the old subdirectory on
the screen? It's just confusing -- the fact that the actually selected
directory is a 'pressed' button, and has bold text, is really not enough of a
hint.

Ideally, those old subdirectories should go away and stop confusing the user when we leave them and navigate back up to the parent. Perhaps it's useful to be able to go back to them quickly without having them in the list again, but that could be achieved with a small right-arrow button; the mirror image of the one on the left in the above screenshot. Or anything else that isn't so confusingly prominent.

It certainly doesn't make sense for them to have the same visual status as the still-valid parent directories of the currently-selected folder.
Comment 1 Matthias Clasen 2009-05-17 22:02:02 UTC
> it's actually looking at the ~/Download/ directory but you could be
> forgiven for thinking that it's in the ~/Download/solos-pci-0.07/soloscli/
> directory.

Sure, the user is always forgiven...

> After returning to a parent directory, why do we keep the old subdirectory on
> the screen? It's just confusing -- the fact that the actually selected
> directory is a 'pressed' button, and has bold text, is really not enough of a
> hint.

This is the first time I hear this complaint. Bold and depressed is a pretty
strong and pretty standard way to indicate the current element, I'd say. 

> Ideally, those old subdirectories should go away completely when we leave them.

No. The reason we keep them around until you go down into another branch of the
tree is for visual continuity, and for allowing you to go back and forth
between a directory and its ancestors without constantly having to find the
directory again in the file list.

Nautilus has exactly the same location bar behaviour, btw.

Comment 2 David Woodhouse 2011-08-06 00:18:30 UTC
'visual continuity' means it still *looks* like you're in that deep directory, when you're no longer there, right? But hey, at least it still looks similar, so that's nice and pretty. Just misleading.

There have to be better ways of getting back to the previously-selected child directory — I already suggested one possible alternative.
Comment 3 Federico Mena Quintero 2011-08-23 01:03:46 UTC
I ran into this exact problem recently.  Now that the GtkPathBar *really* shows you where things will be saved, including in the recently-used mode, it is certainly confusing when you navigate up from $cwd and the subdirectories remain on the right of the current path component.

I kind of like the idea of "hiding" the subdirs under a right-arrow component.  We'd need to play with this to see how it feels (or write a pathbar widget that does custom drawing in a prettier way...).
Comment 4 Matthias Clasen 2018-02-10 05:00:37 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 5 David Woodhouse 2018-02-10 09:04:16 UTC
Yeah, this still happens.
Comment 6 Daniel Boles 2018-03-13 10:09:08 UTC
(In reply to David Woodhouse from comment #0)
> It certainly doesn't make sense for them to have the same visual status as
> the still-valid parent directories of the currently-selected folder.

(In reply to David Woodhouse from comment #2)
> 'visual continuity' means it still *looks* like you're in that deep
> directory, when you're no longer there, right? But hey, at least it still
> looks similar, so that's nice and pretty. Just misleading.

They don't have the same look; active (depressed) GtkButtons are meant to be visually distinct and are styled on that basis. I would say that part of the problem is that our theme does not style the active ones sufficiently different from inactive ones to make the difference in status obvious; see Bug 771204.
Comment 7 David Woodhouse 2018-03-13 11:20:47 UTC
Yeah, that would probably help. Especially if we can visually distinguish all the buttons *up* to the selected one, somehow. So it's really obvious that

 [ home ] [ dwmw2 ] [ Download ] ... 

is currently selected but not (in my original example above):

                             ... [ solos-pci-0.07 ] [ solospci] 

The ones on the right, which are mostly there to give you a quick way to get back down into the directory you just navigated up out of, could be made a lot less prominent.
Comment 8 Daniel Boles 2018-03-13 11:21:59 UTC
That's a fair idea IMO. They could get the .dim-label style class, for example.
Comment 9 Daniel Boles 2018-03-13 11:50:09 UTC
...but of course, we don't want to go too far in the other direction and make them seem insensitive, so it might need more nuance than that
Comment 10 GNOME Infrastructure Team 2018-05-02 14:42:10 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/316.