[email protected] wrote:
> I have used and been mightly impressed with FLTK over the years. I love its
> simplicity and how it makes robustly, includes visual studio project files
> and on ....
>
> However i tentatively offer some of my thoughts as a simple user who hasnt
> really earned the right to comment, but here goes anyway...
>
> One or two things have seemed weird
>
> o FLTK 2 and 1 never converging.
Agreed -- never liked the idea of a fork myself.
> o An old UTF8 version that no one picked up on.
Hmm, not sure what you mean.
FLTK 1.3 *is* the utf8 version.
> o An aborted 1.2 version.
Not sure that's weird, it was just skipped due to the advent of 1.3
> o Simple Widgets like Tree and Tables not being in the core library.
Yes, I'd like to see those get in there too..
but these both really need a peer review, as I'm the one
that developed the two contender widgets, and I don't really
think of myself as a good API designer, so before those get set
in stone, I think folks who are smart about API design should
give it a once over before committing it.
> o Lots of other Widgets developed but that have never been brought into an
> "extras" library.
I agree -- I always felt there should be a separate 'extras'
library that would have all the really advanced widgets, so
that the core library could stand on its own, and could be used
for things like embedded purposes without having to worry about
bloat caused by "high level" widgets like trees and tables.
> o All these other extra Widgets ( like FLU and FL_TABLE ) that i rely on
> going out of date if someone changes the API.
I think FLTK is going back to its roots, and sticking with the stable
1.x API, so I don't think those widgets will go out of date due to
API changes. I still maintain Fl_Table as well as others (didn't write
FLU though),
and keeping these up to date with the 1.x series shouldn't be hard.
> o 1.3 stating that it was going to include Tree abd Tables, but this was not
> the case last time i looked.
1.3 hasn't released yet.
But it may depend on how/if the idea of a separate 'extras' lib
gets designed.
I could envision the big widgets going into a separate fltk_ext.lib
(extensions) lib, similar to the image and opengl fltk libs.
> So seeing the above post about yet another version concerns me greatly !!!
I agree on most of these.. I have the same concerns.
Currently development is going a bit slowly, probably because
all of us are busy with our day jobs..
> I personally would like to see some of the above issues confronted and the
> work in version 1.3 completed before yet another fork goes ahead.
Ya, I warned about forks, and I think we all know they are bad,
2.0 being an apparent demonstration of this.
2.0 would have been interesting IF it were completed, and met the
goals of backwards portability to 1.x that were in the original
design specs, but was dropped due to 2.x being too unlike 1.x.
In the end, 2.x stalled because 1.x had more momentum. Also, I think
changes in competing toolkits like QT may have taken the wind out of
FLTK 2.x's sails.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
