GNOME Bugzilla – Bug 342749
GtkFileChooserButton in the Preferences dialog
Last modified: 2008-01-15 14:06:45 UTC
I was almost going to refile/reopen bug 120600 which was about buttons labelled using "..." but then i noticed part of the preferences dialog had been updated to use the new file chooser widgets. The colour management section of the Preferences dialog makes use of these widgets. These widgets could also be used in the Folders section of the preferences dialog for setting the Temp and Swap folders. Just those two though, it wouldn't be appropriate for the rest of the Folders section, at least not how it is currently presented. These widgets are supposed to be used only for infrequently changed value (ideally only once) so they are well suited to a preferences dialog. However the can be very annoying if you need to set and reset a value frequently and I was advised the developers did not intend for them to be used everywhere. Returning to my first point the "..." buttons in the Folders section might be better labelled "_Browse..." but of course if a developer preferred he could just as easily redesign the way that whole section is presented. In summary: I suggest a small change to use two more file chooser widgets to improve consistency, but also encourage developers to consider if the folders section could be changed entirely if they prefer.
The file-chooser buttons used in the color management section are supposed to go away. Seriously, these widgets are almost unusable, especially for the purpose they are being used here. I don't think we want to introduce more file-chooser buttons. We have had a number of bug reports about the ones in the color management section and I wouldn't want to see more of these.
Changing to an enhancement request and suggesting to close as WONTFIX.
What about this change instead: 2006-05-24 Sven Neumann <sven@gimp.org> * libgimpwidgets/gimpfileentry.c: use GTK_STOCK_OPEN instead of "..." to label the "Browse" button. This makes the widget more similar to the GtkFileChooserButton and addresses bug #342749. And we might want to consider using GtkFileChooserButton but only if we can find out when exactly the widgets where fixed in GTK+ so that we can depend on that version.
To give you an idea on the usability problems with the GtkFileChooserButton, I will attach two patches. One converts the widgets for the temp and swap file locations, the other makes GimpPathEntry use GtkFileChooserButton internally. The problem is that the GtkFileChooserButton only displays the last part of the path. This makes it hard to differentiate for example between "~/.gimp-2.3/brushes" and "/usr/share/gimp/brushes". The other problem that we had with the widget (very long time to instantiate) seems to have been addressed in GTK+ in the meantime.
Created attachment 66125 [details] [review] changes to the preferences dialog
Created attachment 66126 [details] [review] port GimpPathEntry to GtkFileChooserButton
Sorry for not having replied sooner. I dont doubt the GtkFileChooserButton has problems, I also find it annoying at times. I assumed since you were already using it consistency would be a good idea to use it consistently but it is entirely up to you if you want to approach the problem differently.
Its use in the color management section was entirely experimental. We will need to implement a GimpColorProfileChooser widget for this anyway, a standard file-chooser button simply doesn't cut it. The only remaining places in GIMP where GimpFileEntry is used are the two directory selection widgets in the Preferences dialog and the GimpPathEntry widget (which is also onyl used in the Preferences dialog). If we apply the first of the two patches that I applied (attachment #66125 [details]), we could deprecate GimpFileEntry. But we should probably continue to use it from GimpPathEntry. Setting milestone to 2.4 and raising priority because this affects API that should be frozen soon.
I have removed all remaining uses of GimpFileEntry except for GimpPathEntry. Attaching a patch here that deprecates its use. We should consider to apply this before the 2.4 API freeze.
Created attachment 66137 [details] [review] deprecate GimpFileEntry
Any comments on the new configuration widgets and on the proposed deprecation of GimpFileEntry?
No comment. (Only replying so you know I'm paying attention.)
As if I would care if Alan paid attention. The question was directed to everyone who is reading this. If you have a chance to look at the changed dialogs, please do that.
Now that was just plain rude. In case you hadn't noticed I was the one who reported this minor inconsistency. I was politely encouraging you to fix it whatever way you thought best in your own good time. I was going out of my way to _avoid_ bothering you and in response you go out of your way and waste time giving out to me.
Alan, it's so much fun to embarrass you. Please don't stop feeling insulted, it would take all the fun out of it. Now if someone could comment on the UI changes, that would help to make the right decision about GimpFileEntry. It would be especially interesting to know if anyone is having performance problems due to these changes. It used to take quite a while to instantiate GtkFileChooserButton widgets but this seems to have improved a lot with recent versions of GTK+.
OK, since noone complained: 2006-06-09 Sven Neumann <sven@gimp.org> * libgimpwidgets/gimpfileentry.[ch]: deprecate the GimpFileEntry widget, use GtkFileChooserButton instead. * libgimpwidgets/gimppatheditor.c: undef GIMP_DISABLE_DEPRECATED as long as we are still using GimpFileEntry here. * libgimpwidgets/gimppropwidgets.[ch]: removed gimp_prop_file_entry_new(); use gimp_prop_file_chooser_button_new() instead.