It does sound like far more people are using fltk1 than 2, and I agree that compatability between them has drifted pretty far.
I think the best solution would be to start with 1.3 and re-make fltk2 from it. We would keep the existing fltk2 code as a source of code to copy, but all changes would be made more carefully to preserve back-compatability. The first step is to get everything into an fltk: namespace and delete any fl prefix on anything in that namespace. Remove the "Fl" class and make it's methods be static functions in fltk:. Then add the back-compatability header files that map these over with typedefs and renaming the fltk:: namespace as Fl::. Don't put stuff that should not really be in fltk (such as the filename manipulations and utf8 converters) in the namespace, just leave them with their current names including the fl_. Then see what we programs cannot compile and make this set as small as possible. After that then modifications can be done. I don't think there should be switches to change behavior, so anything incompatable should be voted on. Some I can think of: Relative coordinates: I was able to fix all of this by searching for x() and y(). It certainly makes a lot of the code nicer. utf8 - enable this everywhere, with no option to avoid it. Do not mess with filenames, we should assume Windows is set so that the mb interface is utf8 and thus always call it with raw utf8 strings. Style structure: the big thing this does is let you change the general appearance by writing to one location. It also makes the widgets a lot smaller as long as they are at the default appearance. I have never needed to modify anything other than the base and the "menu" style, so I think as opposed to 2.0 there should just be a small set of static ones, no naming scheme needed. Box/Image/Symbol merge: this is a big win because it allows images to be used for boxes, and allows transparent overlays over buttons. Requires all the flag bits to be unified and defined. @-sign parser: this looks like it can be skipped. We should instead support a more html-like syntax, in order to match Pango and Qt and several other apis. layout() method: probably not like 2.0. Deferring the layout works well, but it can be done by the draw() method like fltk1 sometimes does. What we need is a virtual measure() method for widgets so more intelligent containers can be done. Associations: definatly keep this, it looks like a huge win. Shortcuts, tooltips, and as much as possible "sparse" information should be put here. Also encourage people writing type-safe callback systems to use this. Menu items are widgets, and Browser+Menu merge: this results in a huge code cleanup, especially in Fluid, but is also a big source of incompatability. Menu item generators: extremely useful but instead of being able to produce an arbitrary widget, it looks like being able to set the text, image, and callback (basically the same things as MenuItem did) is all that is necessary. These really help as you can have data-driven huge menus. is not working. We need a measure() method on the widgets I think the current one is excessivly complicated. All "style" I have ever done only modifies the bottom widget _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
