GNOME Bugzilla – Bug 328095
pathbar: Up button should not be hidden/confusingly replaced by root button
Last modified: 2018-05-02 14:15:06 UTC
When the dlg first opens at /home/user the first (square) button in the bar is the left-arrow scroller and home is not seen. If I click it home appears without a change of directory and the button changes to the disk icon (representing / ). In fact from being a scroll tool that simply moves the pathbar, this screen item has become a directory shortcut that will invoke a change of directory two levels up. Since the mouse is over this rather small button the image change is to a large degree masked by the mouse cursor making it easy to not see the change. Now a second click will jump us to root directory , user reaction: "what happened , where am I?" It is very helpful in guiding the user, to ensure consistancy of funtionality of any screen element. It would be better if the scroll tool remained visible and got greyed out at the end of the run. If the lack of space issue on the path bar means this space must be reused then the form and colour of the button should be notably different to represent the change of funtion. In general this multiple use should be avoided. Other information:
It seems that this behaviour is an artifact of the "fake_root" bahviour. The code would normally walk back to fs root if there is sufficient space but there if a trip if we are playing fake_root . scrolling back then brings us to normal behaviour, the scrolls get hidden and get replaced , hence the confusing interface. By all means open the dlg at the users home dir (if the caller does not privide a dir), but I feel this fake_root is going against the grain and will be a constant source of anomalies. The scrollers themsleves are fine and I would like to see them permanently dispayed. This will be more realistic once I code a patch for Bug 327733.
Yes, the "scroll to the left" arrow should not disappear. It should just get disabled when the user reaches the scrolling limit. This is easy to fix in GtkPathBar - care to write a patch?
*** Bug 331334 has been marked as a duplicate of this bug. ***
I'll try to find time. It would have got fixed last year when I was working on gkt+ annoyances if I'd had a positive responce to my comments. Shame it took so long. At least we're agreed it could be improved.
Marking as duplicate of bug 320247 as the pathbar in Nautilus already does this. I'd assume the public pathbar would be pulling in these changes from Nautilus. *** This bug has been marked as a duplicate of bug 320247 ***
Reopening and marking as blocker instead
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.
this report is still valid for gtk3 3.22.26+161+g60750b3ffd-1 on Arch Linux.
-- 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/254.