On 12.07.2011, at 12:19, Albrecht Schlosser wrote:
>> f: merging F2 features into F3 will also be a lot of work
>
> Yes, I'm afraid that it is a lot of work. Some of this might make
> it impossible to keep *both* compatibility layers without a lot of
> work and maybe horrible code like "if ((a && !b) || (a && c))" or
> similar.
Ah, but that is supposed to happen in the wrapper.
Let's say for example we have Fl_Browser, fltk::Browser, and fltk3::Browser.
Now, fltk3::Browser is currently a renamed version of Fl_Browser, so all
entries have a base-1 index. Let's simplify the FLTK 2 example and say it has
the same API, but a base-0 index as it should be.
Now the F1 wrapper is:
Fl_Wrapper::select(int i) { fltk3::Wrapper::select(i); }
And the F2 wrapper is:
fltk::Wrapper::select(int i) { fltk3::Wrapper::select(i+1); }
Should we decide that a base-0 index is better, we modify FLTK 3, and the fix
the wrappers:
Fl_Wrapper::select(int i) { fltk3::Wrapper::select(i-1); }
fltk::Wrapper::select(int i) { fltk3::Wrapper::select(i); }
So FLTK 3 stays free of "if (F1) { } else if (f2) { } else {...}"
>
> or 6: use F3 with F1 compatibility, make transition from F2
> to F3 as easy as possible.
> So my questions are: what can we manage in, say, half a year?
> Do all *current* (active) developers follow the route we decide
> to go?
That is very important.
> If we try to make a fully compatible FLTK 3 version, what
> is the future? Can we still improve the kernel and the API, or
> are we stuck to this "forever"?
I would keep FLTK 3 as close to FLTK 1 as possible, very carefully adding what
we believe is great in FLTK 2 (for me, that would be arbitrarily shape windows,
tablet support, widget base pulldown menus, and styles).
> Will we break compatibility in
> FLTK 4? When will that be?
Yes. FLTK 4 would be the point where we need to figure out how we want to deal
with the new UI standards and what they mean for us. Do we need to have touch
display support? Multi touch? Android? iOS? etc. etc. . But I would not touch
(hihi) that subject until FLTK 3 is fully functional and accepted.
> Sorry for all these questions, but I believe that we must think
> even further than "only" getting FLTK 1 and 2 together, although
> I do appreciate this vision very much. If we can do it, I'll be
> on board.
We need to find a solution that we all like. FLTK is too small to survive
another code fork.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
