Wiki/FLTK 3 Proposal

4 pages found.

• 1: What is FLTK 123? 1 [ View ]

  One of our biggest problems in the last years of FLTK development has been  the confusing versioning of FLTK. Bill created FLTK2 quite early when FLTK1 was widely used, but still not stable. As a result, the FLTK user base split pretty much in half between F1 and F2 fans, and so did the developers.

  We los a lot of energy that way, plus we created an extremely confusing version numbering which regularly leads new developers into using the long abandoned 2.x branch.

  This is my proposal on how to fix this.
  

• 2: How to go about it 1 [ View ]

  The all new and improved FLTK 3 needs to be compatible with 1 and 2. It must have a modern API, a complete set of widgets, lots of options, customization at run-time, but still be easily portable, fast, and, of course, light.

  FLTK 1 has evolved to be a great starting point for the first steps in GUI programming. It runs on all major platform (and on many minor ones as well), is small, compact, and easy to use. FLTK 2 was the attempt to continue the success of FLTK 1 with a clearer and more modern API and many important details improved. Unfortunately many users never made the jump to FLTK 2 and so it not only ended in a crawling slow branch, it also became instable and at last unmaintainable.

  FLTK 3 sets out to surprise FLTK 1 users and satisfy FLTK 2 junkies. It will basically be the improved FLTK 2 API combined with the proven and stable innards of FLTK 1. As an extra bonus, FLTK 3 will be compatible to 1 and 2. Just prepend your code with the "coding_style" instruction and FLTK 3 will do the rest. It is even possible to intermix F1 and F2 coding styles at any place.
  

• 3: The big differences 1 [ View ]

  FLTK 2 is based on FLTK 1 in many ways, and while the FLTK 1 API was based on the Forms Library, FLTK 2 is Bill's take on how FLTK 1 should have been. This chapter outlines the biggest differences between version.

  (1) Coordinate System: FLTK 1 child coordinates are always relative to the window, not as most would expect to the parent group. FLTK 2 does the logical thing and uses group-relative origins. This is somewhat difficult to port if we want to stay downward compatible. Fl_Widget will need an additional flag indicating absolute or relative coordinates.

  (2) Pulldown Menus: The developers of the Forms Library did not implement the idea of hierarchies all the way through. Pulldown menus, which are hierarchical by nature, were instead implemented as a list with lots of tricks and kludges to make them usable. FLTK 2 went half way by using the existing Windget/Group relation to create menus, however, menu items are still specialized widgets. For FLTK 3, I would like to allow any widget inside a pulldown menu, using the hierarchical nature of the FLTK base class Fl_Widget.

  (3) Browsers and Tree Views: Browsers in FLTK1 are implemented even worse than Pulldown Menus. FLTK 2 solved the issues in a similar way, and here again, I prefer the FLTK 2 way very mch, but also would like to extend functionality to allow arbitrary widgets as list items. A Tree-like widget comes free with the FLTK 2 concept. FLTK 1 has no such thing and even Fluid had to hack the library badly to generate a tree view. FLTK 1.3 now comes with Greg's Fl_Tree widget.

  (4) Namespaces: this is a minr issue that I include for completeness. FLTK 2 introduces the fltk namespace, renaming all widgets. FLTK 3 will use the FLTK 2 naming scheme and map FLTK 1 class names using typedefs. This is, as most things in programming are, a compromise. The "coding_style" function must be used to switch between FLTK 1 and FLTK 2 code. No worries though, it's easy and straight forward.

  (5) Layout: FLTK 1 uses a top-down approach for widget layout in which the parent widget decides about the child's size "resize(x, y, w, h)". In FLTK 2 any widget can call "layout()" which will query children for their preferred size and propagate the information up. This is a great concept that FLTK 3 should adapt, plus it is compatible.

  (6) Rectangle: FLTK uses discrete coordinates and sizes. FLTK 2's base class is fltk::Rectangle. This is nice and easy to implement. The API is pretty much the same in both versions.

  (7) Styles: FLTK 2 uses a minimal number of styles to define the basic (and often repeated) parameters of every widget. API's are similar though, so this is luckily another pretty straight-forward upgrade.
  

• Implementation Details [ View | Homepage | Download ]