On 10.07.2011 15:49, Matthias Melcher wrote:
>
> Dear users, dear developers,
>
> as you may have read, I have been trying to get the FLTK 1 and FLTK 2 branch
> back together into a single FLTK 3 branch.
...
> THE FINDINGS
> ==============
>
> a: FLTK 1 and FLTK 2 are still quite similar in their basic structure
> b: there are some differences that make life hard - if those features were
> used
My concerns are that there are also subtle differences between FLTK 1
and FLTK 2, so that implementing FLTK 2 completely on the existing
FLTK 1 / FLTK 3 base might be nearly impossible (e.g. Fl_Scroll vs.
fltk(2)::ScrollGroup WRT scrollbars; menus; maybe more that I don't
know about).
> c: a big search-and-replace list will get an FLTK 1 program 95% into FLTK
> 3 code
That's really handy. Personally I would want to do this with my
FLTK 1 code anyway. We should support this by publishing this
search-and-replace list or provide some tools.
> d: a big search-and-replace list will get an FLTK 2 program maybe 60% into
> FLTK 3 code
> e: the compatibility layers work, but the F1 layer is still quite buggy,
> the F1 layer will need a lot of work
This should be completed to provide compatibility for FLTK 1 users.
> 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.
> THE QUESTIONS
> ===============
>
> I want to get an idea if FLTK 3 is worth the effort, and if we need the F1
> layer and/or the F2 layer.
>
> So here are my options:
> 1: keep F1 and F2 development active, forget about F3
> 2: abandon F2, continue with F1, forget about compatibility
> 3: abandon F1, continue with F2, forget about compatibility
> 4: merge F2 into F3, forget about the compatibility layers
> 5: merge F2 into F3, continue with the compatibility layers
>
> What is it going to be?
or 6: use F3 with F1 compatibility, make transition from F2
to F3 as easy as possible.
> I think this is a really important point for FLTK. If we decide wrong, and
> split user groups even more, that would be a disaster!
Yup, IMHO this is the main point. We need consensus among the
developers which way to go, and we need an easy way for users
to *follow* the new development.
> In the end, FLTK is OpenSource, and even if we were to decide to go FLTK 3, I
> can not keep anyone from continuing with 1 or 2. So if we do decide to go 3,
> we should all be on board, and all focus on it (possibly ignoring back
> compatibility). If we ant to stick with 1 and 2, that's fine with me as well,
> but I can guarantee that I will not make another attempt at FLTK 3.
>
> Any questions and opinions are greatly appreciated,
One important point from my POV is also that we (the developers)
can manage whatever we decide in a foreseeable time. Staying
compatible for all times leads to ugly API's and semantics
(like we know from a very big software company ;-) ). Moving
forward to FLTK 3 is a step in the right direction, but I'm
afraid that this step could be too big if we tried to merge in
full compatibility (not only syntactical wrappers) with FLTK 2.
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? 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"? Will we break compatibility in
FLTK 4? When will that be?
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.
A big thank to Matt who made this possible with all his efforts!
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
