On Tuesday 29 May 2007 07:45:36 Greg Ercolano wrote: > No, the folks that are currently working on 2.x will continue > to work on 2.x, whether 1.x freezes or not. > > The question seems to be whether the continued maintenance of 1.x > has any effect on 2.x's development or not. If it doesn't, continuing > it past 1.1.8 shouldn't affect 2.x.
But that's the point, by dividing forces you weaken remaining positions, and right now I think that FLTK 2.x needs a lot more attention than FLTK 1.x, after all as I've mentioned, FLTK 1.x is now in stable phaze. You cannot look at those two like they both need equal attention. For example, as an automechanic with ten workers, and if you need to fix two cars where first has only one broken wheel while second has all four wheels broken, broken engine, broken fenders... would you assign your workers (attention) equally, five to first and remaining five to second to work on each for one month? Here, with FLTK as it seems, in best, 80% of attention is given to FLTK 1.x and only remaining 20% at FLTK 2.x. > This being a volunteer effort, I don't think there are actually > folks being pulled away from 2.x because they're forced to maintain 1.x. > I perceive folks work on 2.x or 1.x as they please, and are driven > by their own whims. The decision to continue 1.x or not should > (hopefully) not deter 2.x dev, and only be driven by a need for > its continuance. Of course, I understand that, but by this you negate all the project coordination, and all this discussion becames needless if all developers act uncoordinated. What I try to say is, if someone has agreed to work on this library than he/her should take responsibility, and try to help even if he/her does'nt like the current issue that needs work. Offtopic, personally that is why I don't agree with GNU ideology, it has no hierarchy whatsover and anyone acts like in some anarchy. > You may be thinking of toolkits that draw directly to the hardware, > where one can take advantage of DMA and fast memory moves. But these > are all hardware specific; FLTK is not trying to be a hardware toolkit. Then I reject what I said earlier, and it should have been a little ironic :)) I was saying that, if you only care about small footprint and speed and neglect some other important aspects of FLTK library, as you said something earlier about sticking with low level design, than you might as well reject C++ completly and turn to C/ASM :) IMHO one of the main purpose of the (GUI) library is to be easy to use (there are a lot GUI libraries for Win32 that are not portable and they all tend to make some developing taks easier), and in that name, cleaner API, more (GUI) features covered so user does'nt need to go "back" to Xlib/Win32 and do something, some undoubted adventages in C++ over C... and so on, helps a lot. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
