GNOME Bugzilla – Bug 796003
Show full path in pathselection
Last modified: 2018-05-11 14:41:08 UTC
Created attachment 371895 [details] shows only last path component 'tmp' in button Some path selection widgets only show the last component of the selected path. This is of no use if multiple paths exist in the file system with the same base name (which is the reason to have a hierarchical file system in the first place). One example: Menu Edit > Preferences > Folders. Shows `tmp`, but which one is it? `/tmp` or `/home/sk/tmp`? You can't tell from the UI because only the last component is shown. Solution: Show entire path in the a text field instead of a button. This also allows quick cut'n'paste from or to this field.
Thanks for the report. We are using GtkFileChooserButton here, and that's what it does. GTK+ moved to gitlab, so I can't just reassign the bug to GTK+ until we move there too. Can you file a GTK+ issue at gitlab.gnome.org please? Closing as INVALID for the current lack of a better resolution.
> We are using GtkFileChooserButton here, and that's what it does. Then use something else or file the bug yourself Himmelherrgott! I'm really fed up with devs using Gnome/Gtk with its controversial (to be nice) design choices, and than not being willing to take the blame. “Oh, this is not a bug, it's a Gnome Feature” — Fuck this! This bug is neither invalid nor closed.
@Michael Natterer > We are using GtkFileChooserButton here, and that's what it does. Bonjour, I have this problem on versions for Windows GimpEval since April 5, 2018. The file selector was working with the GimpEval version of March 31, 2018. I thought it was a Gimp problem but your answer encouraged me to do more tests. My conclusion is that the problem is not Gimp or GTK. The problem is the GLib: - GLib version 2.54.3 = Good - GLib version 2.56.0 = Bad My test is to replace the binaries of the GLib version 2.56.0 by the binaries of GLib version 2.54.3 for proper operation of the file selector in the version of April 5, 2018. GimpEval versions are compiled in an MSYS2 environment (32 and 64 bits). :o)
Stefan, you are out.
Sylvie, thanks for letting us know, Can you please file a separate bug report for this issue? This bug is unrelated and closed, nobody will read any comments here.
(In reply to stefan from comment #2) > > We are using GtkFileChooserButton here, and that's what it does. > > Then use something else or file the bug yourself Himmelherrgott! > > I'm really fed up with devs using Gnome/Gtk with its controversial (to > be nice) design choices, and than not being willing to take the blame. > “Oh, this is not a bug, it's a Gnome Feature” — Fuck this! > > This bug is neither invalid nor closed. Stefan > I think you are misunderstanding Mitch. He is not telling that all is fine and there are no problems, but that we can't do anything on our side, code-wise, to fix it. As for why we often ask people to open bug reports to other projects (or similar tasks), it is because we are short on time. We are about 3 or 4 to code on GIMP regularly and we are already not able to do a tenth of what we want to achieve. So when we have people nicely reporting bugs to us, we are just assuming they are cool with the process of reporting bugs and would therefore save us some time by continuing doing it. This is only a way to share the work voluntarily (since reporting bugs is also a way to contribute). As for "taking the blame", we are already spending a lot of time to contribute Free Software for everyone to use. Should we also be "blamed" for it, really? Anyway, I am just hoping you can be a bit more understandable. :-) > My conclusion is that the problem is not Gimp or GTK. > The problem is the GLib: Thanks for the tests, Sylvie. Maybe something changed in glib. This said, I just had a quick look in the implementation of GtkFileChooserButton and it looks to me like it does what it is supposed to do. It shows the "display-name" of files, and from what I gather, the "display-name" is the filename/base folder, not the full path. Of course something could be done with the popover bubble, but this is all automatic code (syncing with a config property), and I don't think changing this is worth it. It would better if GtkFileChooserButton would add some property to choose to show the full path (optionally with ellipsis when too long) instead of the display name. This way, a software can choose what to display. So we are back to proposing to open bug repots at GTK+.
s/understandable/understanding/