Hi Bill, Mike, everyone. Long time no see. In a nutshell (for those who care) I have done little work with FLTK over the past years. I still use FLTK 1.1 (1.1.4 to be precise) whenever I need a C++ program with a GUI, and advocate for it. A friend, however, is hooked to FLTK (what can I say, the library is awesome), and referred me to the (still) ongoing debate of how FLTK should "evolve". So I've read the newsletter for a week and decided to give my 2 cents to the discussion.
> It does sound like far more people are using fltk1 than 2, and I agree > that compatability between them has drifted pretty far. Old news. > 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. Sounds good. > 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. From what I've read, this is the biggest point of discussion, and also the least important. What changes if we do this? In the library code: loads of fl_ prefixes, Fl:: specifiers and such disappear, in all the files in fltk/src/*.cxx and fltk/FL/*.h. Loads of compatibility headers appear in fltk/FL. Possibly every single file in the distribution needs to be worked on (LOTS OF CODE CRAWLING). Compile time for the library doesn't change. Binary compatibility breaks. Library functionality is not altered. We exchange twelve for a dozen. In user code: coders who want to use the classical interface don't change anything (hopefully). People who think the new interface is nicer are free to do so. Users depending on dynamic libraries need two versions. In the long run, we have the Babel effect, more to be maintained, and FLTK subcultures - like there are not enough of them around the block already. And the library does no more and no less than it did before. I think it is a waste of time. > 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: From Bill's list: > Relative coordinates: I was able to fix all of this by searching for x() Good addition. > 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. Don't care personally, but it appears to be important. > Style structure: the big thing this does is let you change the general Get rid of this monster which almost destroyed FLTK 1.0 to begin with. Good. > Box/Image/Symbol merge: this is a big win because it allows images to be Good thing too. > @-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. I'm not qualified to talk about Pango and Qt apis. Providing different parsers with run or compile-time linkage would make for backward compatibility. Maybe just modularizing the parser would do for the core library. > 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. I did some primitive layout method for the 1.0 release, but that was way time ago. I still think (basic simple FAST LIGHT) layouts are very important. > 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. Agreed. > 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. One request heard over and over is why the tree browser in fluid is not available as a library widget. Maybe this is the time for someone to cut it clean from fluid... > 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. Agreed too. I remember sending an e-mail years ago stating what I'm about to re-state now: you guys did a great job over the years maintaining FLTK. Evolving it has been rather difficult, though. If you want to work into making FLTK more stable and more useful, I'd be happy to be allowed to contribute. But aesthetic merits such as "making the toolkit/api look more modern" or "keeping it up do date with the looks of other GUIs" just don't motivate me. Cheers! Gustavo Hime ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
