Ivan Vecerina wrote: > - no multi-thread compatibility (use of static members/global vars)
Both fltk1 and fltk2 support multithreading in allowed contexts. Just like the window managers themselves, there are some contexts you can do calls in threads, and many that you can't. Usually accessing the global resource such as drawing to the screen, or changing window attributes are limited to a single thread at the window manager level, and FLTK follows suit. In order for FLTK to be a true cross platform lib, the code people write has to work correctly across them all, threaded or not, so it follows there's a certain catering to the lowest common denominator window managers in FLTK's API. This is mainly for both FLTK and the apps that use it to support as many platforms as possible. > - C-style callbacks seem so painful as seen in the samples > ( i.e. cb_x_input + cb_x_input_i pairs of functions ). > Some use of a lightweight C++ template forwarder function > to provide automatic wrappers of member function calls > seems overdue. Yes, I think back in 2003 a vote was cast whether to use templates or not in fltk. I thought it was voted down because FLTK's target platforms included embedded controllers that have limited compiler environments (handhelds, cellphones, one-board computers). But looking at the polling page: http://fltk.org/poll.php?l ..it would appear the votes 'for STL' far outweigh the 'against'. As a side note, separate add-ons like 'CallbackBase' and 'FLTKCallback++' appear to do what you want: http://fltk.org/links.php?V314+Qtemplate http://fltk.org/links.php?V9+Qtemplate Quoting their blurbs: "[CallbackBase is a] Simple template based callback system that accept member function pointers as callbacks. Just a single include file. For Fltk 1.1.x and for Fltk 2.0.x." "FLTKCallback++ is small package which adds more C++ in fltk callback system. It uses templates which are now full supported by leading compilers. Idea was to extend current callback system with possibility to use nonstatic member functions in your callbacks. This enables you to use class members directly." I don't use them myself, as the double-callbacks don't bother me, since that's what's going on anyway, with or without templates. But admittedly, this is probably something I do more out of habit than anything else. If there was a 'pleasanter way' that was in the core, I'd probably use it. Possibly FLTK2 can include one of the above mechanisms in the core, without it affecting FLTK's ability to build. I suppose all that's needed would be a caveat in the docs indicating its use might not port to some lesser platform compilers. > - why not use some containers (even lightweight custom ones!). > Manual resize of array_ in Group.cxx seems so weird: > Why not just use realloc if not a C++ container ??? The use of STL was avoided mainly for portability, IIRC. Personally I don't care how FLTK internally implements arrays. I think Anonymous put it best on the polling page for templates: "I consider it to be far more important that FLTK should work together well with STL than that it should use it." _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
