On 07/12/11 07:12, [email protected] wrote:
> Now, I understand that the 2.0/1.x thing has become sort of
> an ugly mess. If resources were free and infinite I'm sure
> that cleaning it up would be a Good Thing. I'd be concerned,
> however, that devoting a lot of energy to a gigantic merge whose
> end result is not a better product than what already exists may
> not be the best allocation of time and resources.
Yes, I feel somewhat the same -- some problems that were
predicted back at the 2.0 code fork are kinda still present
here in a merge, and that worries me.
Sounds like there will now be two or three ways to do
things (1.x, 2.x and possibly 3.x) which presents a wide API
support issue for the devs when it comes to what I imagine
will be twice as much docs, and twice as many examples,
Makefiles, config issues in the single lib.
Pre-release testing would I suppose involve a bit more effort;
separate 1.x and 2.x tests/issues/etc. A small widget mod might
work in one interface, but fail in the other. So tests involve
2x as much work.
What concerns me the most is the thing that attracts me to FLTK;
the small and simple 1.x interface seems to become muddy with
all the other stuff around it. Even though the 1.x docs will
probably continue to be separate, the noise from the other
API's will be there on the forum, in bug reports, etc.
I'm afraid that if 3.x becomes too heavy to lift,
a lot of 1.x folks will fall back to 1.x and entrench
as many of us did when 2.x tried to emerge.
However, if the merge will somehow magically combines
the resources of 1.x and 2.x programmers, and unifies
dev code so that we all are writing the same code,
albeit in a slightly modified way from what we're used to,
as long as my 1.x code compiles, maybe I won't mind.
Guess I'm in the camp of 'wait and see what this becomes'
and will kinda judge at that point whether I fall back
to 1.x, or join the 3.x program.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
