gEDA-dev: Patches for x_fileselect.c, "discard_changes" bug, separate button ordering patch

[Peter Clifton]

On Sun, 2006-09-10 at 22:58 -0400, Ales Hvezda wrote:
> Hi Carlos,
> 
> >A while ago, I spent some time looking for an automatic way to do it
> >(GTK, or whatever), but I found nothing. Now I looked for it again and I
> >found it:
> >http://developer.gnome.org/doc/API/2.0/gtk/GtkSettings.html#GtkSettings--gtk-a
> >lternative-button-order
> >
> >so it can be done. I filled bug #1553483.
> 
> 	Interesting.  I wouldn't be opposed to this, as long as:
> 
> 1) it doesn't drag in any gconf, registry thingy, or any additional 
>    hidden gnome dependancy.
> 
> and
> 
> 2) It doesn't create/require yet another config file.

>From example at
http://developer.gnome.org/doc/API/2.0/gtk/GtkDialog.html#gtk-dialog-set-alternative-button-order
(Blank lines removed)

"
cancel_button = gtk_dialog_add_button (GTK_DIALOG (dialog),
                                       GTK_STOCK_CANCEL,
                                       GTK_RESPONSE_CANCEL); ok_button
= gtk_dialog_add_button (GTK_DIALOG (dialog),
                                   GTK_STOCK_OK,
                                   GTK_RESPONSE_OK);
gtk_widget_grab_default (ok_button); help_button =
gtk_dialog_add_button (GTK_DIALOG (dialog),
                                     GTK_STOCK_HELP,
                                     GTK_RESPONSE_HELP);
gtk_dialog_set_alternative_button_order (GTK_DIALOG (dialog),
                                         GTK_RESPONSE_OK,
                                         GTK_RESPONSE_CANCEL,
                                         GTK_RESPONSE_HELP,
                                         -1);

Looks like we set the button order in the default "HIG" ordering, and
then specify an alternate ordering which is used if the
"gtk-alternative-button-order" property is set.

There is a default GtkSettings object, and presumably, the
"gtk-alternative-button-order" property is set in that depending on
what platform the app is running under. (Or parsed from the gtkrc)


This doesn't cover all eventualities well in my opinion, as it doesn't
say which OS you're defining the alterernate ordering for.

Do we assume that all dialogs should eventually be moved to the Gnome
HIG ordering, with alternate ordering set to be the reverse (current)
behaviour? We might then get the old behaviour back by simply
over-writing the "gtk-alternative-button-order" property.


Regards

Peter Clifton