> > WRT to the labels, it seems to make the most sense that calling
> > choice("<message here>", "option 1", "option2", "option3"); would
> > display choices in that order, as well as setting the default
> > choice to
> > the first one (in the absence of any other overrides like the "*"
> > character).
>
> I'm not sure about this - it always seems a bit backwards to me (the
> ordering of the dialog buttons) but it is documented IIRC, and any code
> that's out there will likely expect this ordering now.
>
> For example, HIG guidelines usually specify where the "cancel" button of
> the "default action" button ought to be, and this change may flip things
> about. That might be a Bad Thing.
>
> > If it violates the HIG though, I'm happy to change it back.
> > It's only a
> > 2 character change!
>
> Rather than just changing the order the buttons are drawn, if we change
> the drawing order and the co-ords so that things *look* the same on the
> screen, that might be the "least surprise" option for the users?
> It's what I'd favour for the fltk-1.x change, anyway...
Oh, I was referring to the labels. Changing the label order only requires
changing a couple of characters - the buttons will still be draw in the same
order as they were. When I hack up a 1.x patch, I'll keep them in the same
order given how close it is to release.
As for code out there - I need to rebuild the docs (...once I work out how), so
I can change that if needed. However, 2.0 is really only alpha, which should
mean that APIs/ABIs/functions in general should be allowed to be modified
slightly. On that note, however, I'm now in two minds about this; having things
in reverse order seems a tad backwards, but by the same token it seems to be
the the new thing for modern UIs.
Ben
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
