gga wrote:
> matthiasm wrote:
>> 1. continue separate development of FLTK1 and FLTK2:
>
> -1 for this. The support given to FLTK1.0 still seems like a waste of
> time to me.
If you don't have mountains of code dependent on FLTK1,
I can see why you'd vote -1.
I'm strongly +1 for continued evolution of FLTK1 because
IMHO it still has many directions to evolve, and the code
is still very much 'alive'.
On this group even recently when new folks ask whether they should
use FLTK1 or FLTK2, everyone still recommends 1 for prod software,
and 2 for R&D or far off projects.
Given the history of 2, I don't think we can even start talking
about discontinuing 1 until 2 is actually ready.
Otherwise a whole bunch of people will be left in limbo waiting
for 2, and during that time there'd be a lot of strife to app
developers who'd angrily feel forced elsewhere.
When I heard 1 was going to be dropped, I thought hell, this is
bad, maybe I should be looking at something else. But after doing
the rounds for a week or so, I decided it would be easier to just
stick with 1 and maintain it myself if I had to.
2 has taken a while to come up, and I think it still has some ways
to go. And once ready, and the docs are all there, it will still take
some time for production programmers to accept it.
I'm not about to jump on X.0.0 versions of anything for production code.
I'd wait for a X.0.3 at least, just as a general rule, before even
starting to use it for prod code.
>> 2. wrap up FLTK1 and concentrate on FLTK2:
>
> +100 for this. FLTK1.0 needs to die a hopefully not painful death at
> this point.
You're ignoring a lot of app developers who are actively writing
and maintaining existing projects large and small.
I know you Gonzalo ;) You like high level stuff and the right way
of doing things, and have strong opinions (+100!) about code that's
too low level and not forward thinking from a high level perspective.
FLTK1 is still a great thing, and a lot of man years have been invested
in FLTK1, both by core devs and app programmer/end users.. there's a lot
of code inertia there, and it's not something you can just cut off
at the knees IMHO.
This whole drop FLTK1/focus on FLTK2 has come up before years ago,
and the consensus was to continue with FLTK1's dev, and then once
FLTK2 is up and ready, revisit FLTK1's future. And this has served
us well I think, having prevented holding the app developer community
in a 'wait for 2' holding pattern.
I perceive that today we're still in pretty much at the same situation,
so I can only envision the same outcome; continue FLTK1 until FLTK2
has really taken hold with the community, and has more or less made
FLTK1 obsolete. Not there yet though, it seems.
> Fluid should be killed as a C++ project and rewritten in a scripting
> language.
From a high level perspective, I can see the stimulus for this,
code generation complexities are likely easier to implement in
higher level languages.
A ruby-fluid might make a great separately developed project.
But until that tool has seen the light of day, and has generated
acceptance, I don't see the benefit at all of dropping all the
existing effort in the current functional fluid.
And as far as the core is concerned, No, I don't think any of the
core FLTK code should be dependent on high level libs or languages.
The FLTK core would have to tie itself to that language
by tracking its evolution, versions, compilation/install
problems, etc.
End users would have to install that scripting language as a
prerequisite just to use fluid on eg. windows, which would be bad.
It would also require FLTK's scripting language support would
first have to be successfully installed before fluid could be used.
And there'll always be folks saying 'why did FLTK adopt scripting
language 'X' when you could have used my favorite language 'Y'?'
No, I can't see any good in this; it also goes against many of the
core design philosophies that have done well for FLTK's acceptance
and development, and I don't think we should break that now, if ever.
> Finally, Bill needs to get a his hands tied behind his back to not check
> in stuff in 2.0 that will break other people's code from now on or
> worse, leave the code base uncompilable :(
Yes, I think Mike addressed this issue head on in fltk.development
on 5/13, the strong recommendation to Bill being to start a new
branch in these cases.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
