On Friday 05 January 2007 8:13, Christian Neumair wrote:
> Help,Default,User3,User2,User1,Ok,Apply|Try,Cancel|Close
>
> i.e. we would have OK/Apply/Cancel,
yes, kde keeps apply nearer OK while windows puts Cancel in the middle of
them. which is slightly odd, but traditional on the windows platf
I'm missing part of the conversation, but is this Portland Project
discussion?
I know KDE and Gnome do it differently (OK/Cancel, Cancel/OK) for their
respective reasons (ie, afaik they didnt just make it up and it didnt just
happen that way). The same for the position of Help, Defaults, App
Am Freitag, den 05.01.2007, 14:51 +0100 schrieb Sven Neumann:
> Hi,
>
> On Fri, 2007-01-05 at 14:25 +0100, Christian Neumair wrote:
>
> > I'm mainly asking because in 99% of the cases one wants the alternative
> > order to be reverse from the original order
>
> I haven't found a definitive sourc
On 1/5/07, Christian Neumair <[EMAIL PROTECTED]> wrote:
> I wonder why we don't check for the alternative button order in
> gtk_dialog_add_button
> gtk_dialog_add_action_widget
> and automatically prepend the button iff
> gtk_alternative_dialog_button_order
> returns TRUE.
>
> Developers can
Hi,
On Fri, 2007-01-05 at 14:25 +0100, Christian Neumair wrote:
> I'm mainly asking because in 99% of the cases one wants the alternative
> order to be reverse from the original order
I haven't found a definitive source for this, but as far as I know, your
assumption breaks as soon as a third bu
I wonder why we don't check for the alternative button order in
gtk_dialog_add_button
gtk_dialog_add_action_widget
and automatically prepend the button iff
gtk_alternative_dialog_button_order
returns TRUE.
Developers can still override the automatically determined order with
gtk_dialog_set
