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 154388 - gtkfilechooserbutton default button
gtkfilechooserbutton default button
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.5.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2004-10-03 17:58 UTC by Christian Persch
Modified: 2011-02-04 16:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Persch 2004-10-03 17:58:25 UTC
The GtkFileChooserButton's GtkFileChooserDialog's default accept button text is
"OK", which is contrary to the HIG.
I'm not too sure if it should say "Select", or if it should depend on the mode
of the file chooser ("Open" in ACTION_OPEN mode, etc.).
Comment 1 James Cape 2004-10-05 05:44:55 UTC
Every other selection dialog in GTK+ uses OK/Cancel, so I'm thinking that if
we're going to change this we should also change the other selectors as well.

The issue with "Open" and "Save" is that the app may or may not immediately open
or save the file represented by the button, so hitting "Open" or "Save" won't
actually open or save anything when the user clicks it. "Select" is generic
enough, but the user is already "selecting" something when they pick the
file/folder from the treeview in the actual GtkFileChooserWidget.

Another alternative is to simply ditch Ok/Cancel and just use "Close" -- which
should simplify the code a bit internally, and is the real HIG way (if the app
want's to hold off on instant-apply, the button should be in something with a
$NO/$YES pair of it's own anyways).
Comment 2 James Cape 2004-10-26 04:38:04 UTC
Fixed in CVS HEAD ("Save" for SAVE/CREATE_FOLDER, "Open" for OPEN/SELECT_FOLDER).