On 27.06.2008, at 07:40, Michael Sweet wrote: > 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.
1: the advantage of using name spaces apart from naming conflicts can be less typing. For example: Fl_Box *b = new Fl_Box(1, 1, 10, 10, "Hallo"); b->align(FL_ALIGN_LEFT|FL_ALIGN_INSIDE|FL_ALIGN_WRAP); would be: using fltk; Box *b = new Box(1, 1, 10, 10, "Hallo"); b->align(ALIGN_LEFT|ALIGN_INSIDE|ALIGN_WRAP); Sure, it may also become more confusing, but that all is a matter of taste, coding sttye, and possibly coding discipline. 2: there is much more to the new API than the new namespace. Widgets are named much more consistently (Fl_Tabs became TabGroup, Fl_Pack became PackGroup to indicate that they are groups, etc. etc.). FLTK2 sticks with one single naming scheme (almost) all the way through to keep the interface easy to understand. 3: there are are few logical changes modifying inheritance. Fl_Image, Dymbols (you know, the @circle stuff), and boxtypes are now derived from the same base class, so where ever you can use a box in FLTK1 ow, you can just as well use a collection of images, and wherever you insert symbols into a label, you can now insert an image as well. That is really neat for prepending a little icon in front of a Browser entry. Is that enough of a big deal to make it worth an API change for FLTK1? I don't know if it is worth it for the old crew, but it sure makes the API look more modern and cleaned up for new users. Matthias ---- http://robowerk.com/ _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
