> > > > 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.
>
Yes, I agree that at least as far as 1.x goes, compatibility is good.
> > 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.
Yes, I suppose this is a good point.
>
> > 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.
Alright, you have me convinced. I'll reverse the displayed order of the
buttons. :-)
Ben
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
