Re: GNOME CVS: gnome-core mmclouglin
- From: Owen Taylor <otaylor redhat com>
- To: jacob berkman <jacob ximian com>
- Cc: Havoc Pennington <hp redhat com>, gnome-2-0 <gnome-2-0-list gnome org>, gtk-devel-list gnome org
- Subject: Re: GNOME CVS: gnome-core mmclouglin
- Date: 15 Nov 2001 18:01:57 -0500
jacob berkman <jacob ximian com> writes:
> On Thu, 2001-11-15 at 16:23, Havoc Pennington wrote:
> > jacob berkman <jacob ximian com> writes:
> > > if the latter, this is not the right place to do it as GnomeDialog needs
> > > to switch them around (if it hasn't).
> > I don't think GnomeDialog _can_ switch them without breaking a bunch
> > of stuff - the way the API works relies on button positions.
> ugh. i just looked at what the gtk patch did.
> i had thought it did something to the hbbox to make it pack in the other
> direction. if it had done this, the gnome one can easily be fixed, as
> it uses its internal button list and not anything from the hbbox to do
> there isn't a way to get an hbbox to go in reverse-language order (RTL
> for LTR langs, LTR for RTL), is there?
> and also, with the patch, if you add more buttons they actually end up
> being on the right, not the end (how i figured it would work). this
> seems contrary to the point of the patch :/
Remember, the change here is _not_ just flipping the buttons around.
We don't change
[ Help ] [ OK ] [ Cancel ]
[ Cancel ] [ OK ] [ Help ]
So, what's being done here is completely different from LTR/RTL flipping,
cannot be done automatically, and (also) must be _combined_ with RTL flipping.
We could could easily have a GtkSetting that picked a binary choice
between the two styles, and make the standard GTK+ widgets obey
that, but applications would still have to get the setting and
also obey the setting for their own custom dialogs. Which isn't
exactly going to happy uniformly.
There is possibly some use in having this setting at the GTK+
level so if people are writing GTK+ apps where fitting in with
non-GTK+ apps (Mozilla/KDE/Windows) is more important than
fitting in with the GNOME style guide.
But I don't think there is any alternative to picking the way of
handling it that we think is correct for GNOME and implementing that.
I'm still quite concerned that we are deviating from the rest of the
free software platform here, but making this choice configurable
doesn't help inside the GNOME framework.
] [Thread Prev