Anton Novikov wrote: > I propose the following way of developing: > 0. Create new lib fltk-base as a part of fltk project. > 1. Make both fltk1 and fltk2 build with it.
Please look at the "basic" code from FLTK1 and FLTK2 (x, osx, Widget/Fl_Widget). It's inherently small, and coupled with base classes. Moreover, FLTK2 uses a different style. This would make both FLTK1/2 inconsistent with fltk-base and/or hinder FLTK2 c++ support. > Since I don't know any of developers in person, I can only write something > on this ML: Reliable developers! Are you motivated? If yes, write about > it. If not, write about it, make clear your point. > I myself will contribute on fltk2 part when I have time. I tried both FLTK1 and 2 for a short time, and I like very much FLTK2. I find that the API gets cleaner each time I take a small peek at it. I find it exquisite that this kind of refining is still in progress and I'm absolutely certain that _this_ experience is NOT wasted at all, and it will come back at full speed in 1.3 (because we already know what to do). The API designing phase takes very long, and often requires large rewrites. You don't want to do that while tracking bugs (well, you COULD, if you had a huge amount of blind manpower). To me, it would make much more sense to generate header wrappers to expose FLTK2 api while using 1.3 once we have good api consistency. We will get stable code and good APIs without wasting time. That's why I'm working with 1.3 while I praise for those that still file RFEs and smooth/out FLTK2. Also, please look at the code. Really. FLTK1 and 2 have diverged very much. It's almost impossible to backport a fix easily from 1.1.x. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
