In article <[EMAIL PROTECTED]>, matthiasm <[EMAIL PROTECTED]> wrote:
> So here are three possible solutions. Please comment and add > solutions if you have any ;-) Here are my thoughts. I like FLTK for it's incredibly small footprint, speed, interface and _minimalism_. I would _not_ like to see FLTK take the same road as QT/wx/etc, in trying to wrap every possible system feature to help programs being portable. Instead, I like the current one: just expose the _bare_ minimum to allow applications to build a portable GUI, letting the implementor choose the wrapper of it's choice (there are plenty already). Consider the threading example: 1.1.8 has now some decent interface that allows to build threaded applications, yet it does not expose portable classes or functions to build threads or mutexes. After all, I can take QT-core, and use FLTK to build the GUI with almost zero redundancy now (which I did several times). I like some of the improvements of FLTK2. It has a cleaner interface which looks more polished, and most importantly proper UTF-8 support (which is the main show-stopper for many users). But that's all. Additional widgets are nice, as long as they are not linked-in when not used, but that won't buy my move to FLTK2. Signal and callbacks? There's no clear solution, and any c++-template-based one that I've seen is limiting in some ways or the other. Again, I'm using boost::bind now, and I love the fact that I can choose without compromises/fancy "adapters". > 1. continue separate development of FLTK1 and FLTK2: > > This would mean that 1.1.8 becomes the base for a new attempt at FLTK > 1.2. We would then apply the UTF-8 patch and change the API to > finally bring FLTK 1 up to par with other GUI libraries. FLTK2 would > remain in Alpha stage until someone puts the effort in to fixing the > STR's. Like you said, there are many bugs that were fixed in 1.1 that are still present in 2.0. Continuing separate development will only get this list bigger. > 2. wrap up FLTK1 and concentrate on FLTK2: > > This would mean the end of the FLTK1 branch, leaving it in a very > stable condition, a great tool for those not needing international > text. All developers could put their efforts into bringing FLTK2 to > where FLTK1 already is, gaining the additional features that FLTK2 > already has, like better structure and internationalization. Will > FLTK1 developers change over to FLTK2? Are the compatibility headers > powerful enough for a simple switch? I never looked deeply in FLTK 2.0 because of it's instability, but that sounds the proper way. The FLTK2 interface is more polished and removes some of the rough edges of FLTK1. It would be a waste to not take advantage of it. That being said, I would not switch for a larger library. I'm in as long as FLTK2 is conceived as a "better FLTK", not a "yet another fully featured GUI toolkit". > 3. wrap up FLTK1 and FLTK2, and start FLTK3: > > This would leave FLTK1 and FLTK2 just where it is. Developers are > free to add simple fixes to FLTK2, but FLTK1 would be final. We would > spend some time listing all features of 1 and 2, combine them in a > sensible way, and then merge the source code to generate FLTK 3.0 > with all features needed for a future GUI library. Compatibility > layers for FLTK2 and FLTK1 would be designed in from the start, so > that existing apps can be converted without much trouble. I can't comment on this one, but it sounds as a departure from the minimalist approach. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
