Bill Spitzak wrote: > ... > What I was proposing is to use the fltk2 scheme, but start over from the > current fltk1 code in order to preserve compatability. There are still > "fl/Fl_foo.h" header files, but they are compatability wrappers around > the new "fltk/foo.h" header files. Here is a typical example, the > contents of FL/Fl_Button.H: > ... > This uses a typedef to make Fl_Button be the same as the new > fltk::Button object. It also uses the enum to copy fltk:: enumerations > to the FL_ names. > ...
I understand all of this, but my real point is: what does this actually buy us? To be honest, I have 0 interest in compatibility with the current FLTK 2 API, and re-creating the/a FLTK 2 API with FLTK 1 wrapper headers seems like a poor reason to re-transition to the fltk namespace. If someone really wants a FLTK 2 compatibility layer, it would be just as easy to do the reverse - fltk namespace headers typedef'd to the Fl_/FL_ names. Seems like we will get a lot more done and have a lot fewer regressions if we stick with the FL_/Fl_ prefix... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
