> 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).
>
As far as menus go, from what I can *tell* (note: this may not be the actual
case) a lot of the API was intended to be similar to FLTK 1 code, with the
exception that it was attempted to add generic Widgets to a Menu rather than
only Menu_Item's. Of course, this wasn't *entirely* realised, hence fltk::Item,
but IIRC Matthias had a similar idea (in either one of his articles or one of
his posts to this mailing list - I forget which) w.r.t adding Widgets to Menus.
In terms of differences, it seems to me as a non-1.3 user that Fl_Menu_Item
attempts to emulate a big part of Fl_Widget (for instance, the image()
functions, etc.) -- and thus given the API overlap it shouldn't be too hard to
provide compatibility to both. Plus, fltk::Item only has all of 4 useful
functions (draw, layout, handle and a c'tor), which will aid in the attempt to
provide API compatibility to both.
I don't know much about Fl_Scroll, but I feel as though chances are a lot of
these problems are going to iron themselves out in due course if we attempt the
compatibility layers, if only due to the lack of work on the 2.x branch
> > [snip]
> > 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.
I think Albrecht raises a good point here - beyond "What do we (as developers)
do w.r.t
compatibility", it's also pertinent to discuss "what to we (as
developers and users) want from FLTK 3"? Obviously, getting the user
base back together is one of these aims, but perhaps more concrete aims
can help put us all on track as far as compatibility layers go.
As for FLTK 4, my thoughts are as follows: I personally see little point in
joining in on what seems to be an ongoing version war and adding a new major
version every fifteen seconds because a new component was added - I'd rather
see a list of some number of goals, both short and long term, work on all of
these one at a time (and, of course, release) and then move to the next major
version. I feel this will help cement the push to get both users and developers
on board; users will have new features in the FLTK3 branch (and thus have the
motivation to switch, with the compatibility layers) as well as stability and
developers will have a concrete todo list -- being frank, something both
versions are currently lacking.
It also means each major version has a list of 10 (or whatever number is
decided upon) new API + core features - gradually evolving the FLTK core and
API over time with necessary degradation happening naturally and with a
transparent plan. This ensures enough back compatibility between major versions
to force only minimal changes between user upgrades, whilst at the same time
giving the developers enough freedom to keep FLTK a modern toolkit.
> A big thank to Matt who made this possible with all his efforts!
Definitely seconded!
Regards,
Ben
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
