..No multi-thread, globals: Agreed, no big deal from a practical perspective.
..No automated wrapper for callbacks to object methods: Thank you for the links. Indeed, such a layer can be built on top of the current callback mechanism. [ it would also be faster and less error prone, by using the void* "cookie", than the multiple calls to parent() found in the forwarders I saw in the samples... ] > Personally I don't care how FLTK internally implements arrays. I do think that using new[], delete[] and memcpy when a single realloc would have worked is a crime ;) -- that is, one should use a robust and maintainable C idiom, or a C++ one. There is a lot to like in FLTK, and it definitely deserves its place as an important framework option. But some design quirks do contribute to leaving me with a mitigated impression, and I was hoping to see a deeper modernization effort in the 2.0 version. But how receptive would the FLTK community be to this ? What is the interest in modernizing the interface ? And would some internal clean-up efforts be accepted ? Cheers, Ivan _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
