On 17.03.2011 10:47, Ben Stott wrote:
> > > 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...
Yep, we should (better: *must*) keep things compatible to existing code,
we can only change the innards, such that keyboard navigation does what
users expect.
> 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.
Now that we think of a fusion of 1.x and 2.x we shouldn't make too many
incompatible changes. And, BTW, changing APIs/ABIs/functions too much
in the development of FLTK 2 was IMHO something that made FLTK 2
lose many users over the time.
> 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.
The problem is not the order in the UI itself, but in the code that
leads to a particular order in the UI. If we reversed the mapping of
code order to display order, then we would break existing programs.
I just added a /very/ simple patch to STR #2591 that changes the
button order in the group, but does not change coordinates or anything
else. Please see and test this [1]. I'm not sure that there is no
change in default focus though, when I'm now thinking about possible
side effects. We should check this...
Albrecht
[1] http://www.fltk.org/strfiles/2591/button_order.patch
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
