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. > > 2. wrap up FLTK1 and concentrate on FLTK2: > +100 for this. FLTK1.0 needs to die a hopefully not painful death at this point. FLTK2's code base is much better. It still suffers from a lot of bugs fixed in fltk1 not having been ported over. Currently, the killer for me is the X11 font listing crashing on Ubuntu. I think this is an issue present in 1.1, too, but for some reason 1.1 does not trigger it. I think with even just one month of bug fixing as it was done for 1.1.8, most issues would be addressed. The backwards compatibility layer is NOT 100% seamless currently. It probably never will totally be. But it should take you in a worse case scenario almost 90% there. For the most part, it can be made more seamless. I've been doing the same in Ruby and right now, I can take all the ruby-fltk (1.0) code and run it on 2.0 with close to no changes. However, ruby-fltk1.0 did use namespaces correctly (unlike the c++ fltk1.0), so it does make things a tad easier. For custom widgets, the biggest headache comes from the change in resize/layout. All the #ifdef FLTK_1_WIDGET stuff polluting 2.0 should be moved to the Fl_* compatibility layer, as it is polluting 2.0 classes. Fluid should be killed as a C++ project and rewritten in a scripting language. Its code base is unmaintainable as it is. I started porting it to ruby and realized it was not worth it ( a Ruby fluid written from scratch is easier). This will make maintaining it much easier (plus it will allow other, non-core nor non C++ developers to do it). .fl files should also probably be killed. Scripting languages come with a lot of binding to popular ascii formats that can be used to marshaling (the super simple YAML and the super mess that is XML for example), so it makes no sense to develop and maintain your own. Writing a .fl -> yaml converter later on is easier for older projects. This will also make supporting "skinning" very easy (which in turn will bring lots of other people to maintain this). Also adding support for your own class (plugin support) then becomes a matter of SWIGing it. Threading should be made compatible with boost (which is probably the best C++ threading framework right now), and most of the threading classes in FLTK2 should go away and be made private (as they are incomplete and less well thought out). Just the hooks to make the toolkit thread compatible -ie. locks- should be left. autoconf/configure should be killed FLTK's footprint needs to be made smaller by proper use of Makefiles. 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 :( > > 3. wrap up FLTK1 and FLTK2, and start FLTK3: > What would the main point be for this? You are still going to run in the same issues, regardless, mainly because fltk1.0 suffered from not using namespaces and the layout mechanism of 2.0 should probably be kept as it is a better approach. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Kubuntu Edgy _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
