GNOME Bugzilla – Bug 476154
gtk-alternative-button-order doesn't work
Last modified: 2007-09-14 10:48:49 UTC
Please describe the problem: After set gtk-alternative-button-order=1 in ~/.gtkrc-2.0 I cannot get alternative button order in GTK+ dialog (for example, in gedit and synaptic). Steps to reproduce: 1. Append gtk-alternative-button-order=1 in ~/.gtkrc-2.0 2. Run gedit 3. Open file 4. Look at button order Actual results: Expected results: Does this happen every time? yes Other information:
Just to make sure: did you reaload the Gtk theme whose gtkrc you adjusted before looking at button order?
How to reload Gtk+ theme?
Switch to another theme and back using any of the available theme managers out there
I launch Gtk+ applications under KDE. Is it enough for this?
Probably yes. I've just tried this on several applications. Open/Save dialogs: GIMP: works Conduit: works Evince: doesn't work Gedit: doesn't work Leafpad: doesn't work Inkscape: doesn't work Font Selection dialog: GNOME terminal: works
Apps that create their own custom dialogs have to support this in the app, it isn't something that gtk does automatically (you'd have to check old list archives if you want to know why it works this way). So, you have to file bugs on specific apps and dialogs.
It is up to the application to support this. It works in GIMP because we added the relevant code snippets all over the place. Please file enhancement requests for the applications that don't support this yet.
It does NOT work in GIMP 2.2.15 (Gtk+ 2.10.6). Well, Gtk+/GNOME architecture is really bad and has not any trend to make more user-friendly. Thanks for your answers.
Andrey, this is not linux.org.ru. This is bugzilla, not flameodium. People either make sensible comments here or noone listens to them. BTW the latest version of gimp is way higher than 2.2.x
Please close this bug report. We know the reason for issues now, so we better work on fixes for standalone applications now which will require separate bug reports + subsequent patches.
Instead of patching each and every application, why doesn't GtkFileChooserDialog simply default to setting up the button order itself if the user doesn't do it? There is a big inconsistency here - GtkFileChooserButton calls the dialog with a set button order, but most applications that don't set it up properly (and I believe they shouldn't have to care for a stock dialog and it should just work) will get the GNOME HIG button order - two different button order for all the same GtkFileChooserDialog in the very same application if the application utilizes both a GtkFileChooserButton and a GtkFileChooserDialog directly. I do agree with comment #6, but I'm talking about stock dialogs, not custom dialogs, just like the original reporter talked about a stock dialog - the file chooser dialog
Oh, this enhancement request is covered by bug #170137, of which this bug is really a duplicate of, it seems, not a standalone INVALID bug.