matthiasm wrote: > 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
Yes to all of them. The abstraction layer just for drawing could be actualy done relatively fast and putting the current code within default device(s), probably splitting X, win32 quartz and carbon to separate ones. > (Cairo comes to mind) I have pretty much working cairo port on windows although with rather outdated cairo and fltk versions. Being on windows cairo makefiles were some pain because they are pkg-config dependent, but we would probably had to include cairo in the fltk tree and make own makefiles similar as recent zlib, jpeg and png libraries. The port is more-less complete, including image caching for any transformation and scalling (when image is drawn, it searches among existing caches for similar transformation to use it and builds new one only in a case when it does not exist yet for particular transformation, the caches are internally registered and reference counted within the base image). I will present this cairo port once 1.1.8 is out so I can port it to it. Font caching has yet to be done, at the moment it relies on cairo's internal 256-fonts cache and so-called "toy" api. One warning: some cairo primitives are bloody slow at least on windows so we should keep possibility to use recent code as a "standard" screen device and switch to cairo only during printing. I did nor have too much problems with switching between recent fltk drawing functions and cairo calls for the same window so it should be very possible to use standard drawing for normal user ingerface and cairo for some "document", "graphics" or "canvas" widgets/windows where you require much more rich and feature complete drawing. > > 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 I would really keep the 1.1. source compatibility as much as possible. In many cases you can have compatibility headers between 1.x and 2 easily done but such changes are more-less just a syntactic sugar. But when I had a look in FLTK2, the really interesting things would break the compatibility and would be difficult to have 99% compatible. If you jump to 2.0 api you will make the same mistake again. Better making small steps keeping the code in "nearly production quality" all the time. This is proven approach with fltk 1.1 where svn was good quality at any moment. I think breaking binary ABI more often is not a problem but source compatibility should be kept quite strictly. Although making some cleaning and defining some functions in the headers only when some FLTK_1_1_x_COMPATIBLE macro is defined is good. One thing which is little bit mess are global functions, some implemented as static in Fl class (probably supplying namespace encapsulation). I though that the ones in Fl are those which somehow influence on the fltk state but there are too many exceptions in both ways. The other thing is the enumerations and some changes within images would help too... > 6: now we can copy more essential features of FLTK2 over to FLTK3 > (printing, symbols, doxygen, etc.) To allow printing in the future without breaking ABI, for now we need only to abstract the drawing primitives (probably by having them as virtual functions in a device class, it is a good and simple enough approach), leaving the particular other-than-recent implementations for later. For printing devices I would not be affraid to be cairo-dependet (with cairo PS, PDF, SVG, PNG, Win32printing eare comming for free which would take ages to implement). You can use standard device for the screen and swap it to the cairo one only for printing. Symbols require some generalisation, maybe defining some class below Fl_Image which would unify these two can be handy so it could be used at places where Fl_Image can be placed for now (and vice versa). > 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 This would come if we use cairo rendering. But for the compatibility for drawing primitives between different devices, we should: Assure that all the core FLTK widgets, images, fonts etc are always drawn during unitary transformation (or maximum with some integer translation) to have correct drawing with recent implementations and declare that if the transformation is more complicated, the behavior of these primitives are uncertain and depend on the device implementation. But for cairo the situation is completely different and you could get scalable GUI - nothing is perfect though, you will get very good result if you scale things by an integer number otherwise some things can look so-so on lower resolution devices even if you have all the antialiasing switched on. > 8: the API should be modernized to support signaling Nah, this will always be a subject of conflict and many users (like me) will never be happy with particular implementation. Better to make some simple "plugin"-like system which could destruct this callback/signal/whatever oject (it could be also a list if you want multiple callbacks). Natural placement of this object(or object list) is the user_data pointer so what I would do is to add additional method to assign a callback like Fl_Widget::destructed_callback(Fl_Callback * c, void * data = 0); which would indicate that the callback should be be called not only like standard callback but also when the widget is destructed. The widget would make the last deadly call with NULL as a widget argument(the widget is probably partially destructed anyway, so it is not much use for it) and such NULL parameter would inform the callback function that it is not the regular call and this function should ie rather destuct the passed data object than perform the regular call. To assure compatibility we would need just a single additional bit in some flags within widget informing that this is such a suicidal callback and it should be called in such a way in widget destructor. Anyway a single user data is enough to construct powerfull type-safe signal or callback system with any degree of sophistication using that pointer. And instead of having a widget method like connect(...) you can have a global highly templated function like fl_connect(Fl_Widget * w, .....) which would do all the work for you. But that I would leave to third parties and maybe include the best implementation in /contrib directory - Hey, why not to have a competition here? You can do that even now without such a "plugin" just by writting simple templated class although it can bring some bloat comming with the class specialization during the compilation. > 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 That would be nice but lot of work. The ftlk-library source is easy to understand but I have been quite lost in fluid source. It works pretty well for what it is supposed to do but I have impression that substantial modifications would break it into pieces and you would be starting from scratch. But maybe I am wrong here... Roman _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
