GNOME Bugzilla – Bug 158009
Stock Browse
Last modified: 2013-08-14 01:46:12 UTC
(no idea if this belongs in gtk+ but I'm reasonably sure this is an appropriate place for it) Many dialogs use a Text Entry followed by a Browse Button like so [ ] [ Browse... ] Some developers have a bad habit of using only "..." three dots instead of Browse, and I believe the fact that it doesn't need to be translated is a factor in this decision. Given how often this scenario occurs I think it would be reasonably worthwhile for there to be a stock button for it.
In hindsight I really should have filded this against GTK, so moving...
http://developer.gnome.org/doc/API/2.0/gtk/GtkFileChooserButton.html I was just looking at the Gtk File chooser Button which appears to have been added for gtk 2.6 It seems to meet the required functionality I described above but I'm concerned about the user inteface. the usual way of displaying this functionality looks like: [ ] [ Browse... ] which has the advantage of allowing the user to see and copy the whole file path location if they want, and the labelled button with the ... makes it fairly clear that clicking on the button will pop a new dialog. Perhaps the FileChooserButton has advantages I'm not seeing?
The main its advantages are ease of use for developer and uniform appearance/functionality in all gtk applications, but in some cases it's invonvenient, e.g. for copy/paste; or impossible to use, e.g. for entering a path which may or may not exist (no, it's not SAVE or CREATE_FOLDER action of GtkFileChooser). An entry with Browse button can not be replaced with GtkFileChooserButton everywhere.
I should have updated this report, a gtk developer did explain to me recently that the GtkFileChooser was only intended for a few specific tasks, not a universal replacement for an entry and a selection button (so if I were to see it used inappropriately I could file bugs against the app rather than against the widget).
gtk stock apis have been deprecated.