I have read thread about FLTK 3.0 (I no answer in that thread because most of my mail includes completely new proposition).
I agree that one API for FLTK1/2 would be a great product at this moment but I also think that in longer time perspective it is not the best idea to invest time to develop it. This is mainly because both this APIs (FLTK 1 and 2) will be not enough modern in times when next (stable) FLTK can be finished and is better to think what is good to have when next FLTK will be finished, not what is good to have now. It always good to ask what next? (for example what next, after FLTK3?) FLTK1 have many users and applications, but FLTK1.3 (which I suppose will be continue) is a great release which provides support for its for long time. It also can be still used in embedded environments with old/not-full C++ compilers. I suppose that there are not too much users of FLTK2. And I write this in spite of I'm one of this user! I also think that many of this users like modern API and are ready to migrate his program to have modern API. Some (which must have stable program now) also will migrate soon to FLTK1.3 (for example I choose FLTK2 some time ago because it was only one with good unicode support, and now it is possible for me to migrate to FLTK1.3). So FLTK2 could be probably safety discontinued (but some code and conception can be take to next FLTK version). We will also have new C++ (0x) standard which gives in my opinion new possibilities in constructing API. That is why, I think that next FLTK should have new, much modern API, attractive to developers for long time in future (still having reasonable fast, light engine which not duplicate nothing from standard library) which: - using namespaces (like FLTK2) - using relative coords and canvas abstraction for drawing/printing/etc. - using std::string or even std::u32string - allows to use C++0x lambdas as call-backs - using STL or some its concepts (for example iterators and begin/end to allow use new C++0x for loop and STL algorithms) - using model/view/controller approach (FLTK2 browser allow to have separate model - fltk::List - which I found very usable... many good solutions in this area are in java swing library) - ... New API mustn't be compatible with neither FLTK1.3 nor FLTK2 (of course if compatibility layer, or layer which helps migrate would be possible to write it will be a nice future). But many concepts from FLTK1.3 and FLTK2 should be safe and easiest of migration should be consider always when making detailed API decisions. I suppose that it is possible to have modern API for which migration process will be resonable easy, without thinking to much (maybe it is good to have migration instruction witch consists of entires of type: <some code/class> can be replaced by <some code/class>). Kind regards, Piotr Beling PS. I'm also ready and willing to help develop new FLTK with modern API. Who am I? For long time I'm also developer of some FLTK2 applications (http://bcalc.w8.pl/, http://warcaby.w8.pl/) and library (http://xfltk.w8.pl/), with some experience in GUI programming in another technology (mainly Java swing, and wxwidgets). _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
