Arrgh, 1.1.8 is *not* final just yet, but I guess we jinxed it already ;-)
So here is my opinion: We made a huge mistake when we reached version 1.1.1 or so by splitting FLTK into verison 1.1.2, 1.2, and 2.1 (well, not exactly, but I am trying to make a point). Could we have created any more confusion? My biggest criticism about FLTK is the version mess which IMHO must be fixed once and for all. But first things first. What are the plusses and minusses of FLTK1: - it looks outdated (well, GTK+ helped, but still) - internationalistaion is non-existent - FLTK1 interface is antiquated, FLTK2 still feels old (callbacks...) - some essential widgets are missing (table, tree, grid lists) + FLTK is fast and light, as advertised + FLTK is easy once you get the hang of it + it runs on many platforms (but since we are so small, we should support MobileWindows and friends too) + FLUID is really great So here is my proposal: We take the stable 1.1.8 core, the 2.1 API, a new great look, and call the whole thing FLTK 3.0 Some more details and a road map proposal: 1: close 1.1.8 as final for good 2: close 2.x as final for good 3: create FLTK 3 as the HEAD of SVN, using the current 1.1.8 3a: add UTF-8 3b: add essentail widgets (table, tree, gridded lists) 3c: apply all the ABI-changing variable size changes we always wanted 4: separate the OS-dependent layer from the rest to allow better porting (Cairo comes to mind) Up until now we have not really changed much, just moved and added stuff. Now comes the big one: 5: class by class, take the FLTK1 API and replace it with the FLTK2 API, staying compatible to 1.1 at every point. The only really hard thing here is the coordinate origin difference between 1.1 and 2.0, but this can be solved. The FLTK2 API simply is a ton better than the FLTK1 API, easy to read, and actually mosty a renamed FLTK1 API. 6: now we can copy more essential features of FLTK2 over to FLTK3 (printing, symbols, doxygen, etc.) At this point, FLTK1 and FLTK2 folks should both be very happy, having FLTK3 source code compatible *and* stable. FLTK3 should become The New FLTK, and we should let the world know. Now lets modernize: 7: widget rendering should be based on sclable images to create a sleek and modern GUI 8: the API should be modernized to support signaling 9: FLUID3 and new FLTK3 features should make it really easy to rapidly create a commercialy viable app: 9a: higher level API for applications, documents, actions, undo, and states 9b: quick assembly in FLUID 9c: full internationalisation with FLUID 9d: FLUID cooperation with common IDEs Finally: compete, have fun: 10: we should advertize our library, make it known, give great introductions and provide videos and howtos. FLUID should be the centerpiece, creating complete frameworks for other IDE's out of the box. Developers should love FLTK for its simplicity, speed, and light weight, and for the fact that they can develop cross-platform without leaving their own trusty IDE. Or on a much lower level: I want a snappy GUI library to easily write apps that look and feel great on every platform. Matthias ---- http://robowerk.com/ _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
