On 2013-01-15 16:54:05 -0500, Ian MacArthur said: > One trivial observation is that the use of FLU / flu as a namespace > confused me, since there is already a (fltk-1.1) third-party add-onn > lib called FLU, that I used to use quite a lot!
I was inspired by a moderate fever at the time, and evidently didn't check thoroughly enough for existing uses. I'm open to suggestions for other names. > Indeed, and I have no issue with using new features in my own code, too. > > But for the core lib it is a problem; indeed I still support some > embedded devices for which the only tool chain is based on gcc-2.95, so > C++11 features are perhaps a bit beyond it! I'm sure other users are in > the same situation, hence my caution about new features in the lib. Might be a good idea to stick a disclaimer in the documentation to make the implications clear. As there currently isn't *any* documentation, that's a few entries away from the top of my to-do list. And I've been avoiding such depenencies for the OpenGL driver. > Oh, now that's a thought - for the embedded targets, an EGL driver > rather than a GL one, might be really neat too... That reminds me...with an OpenGL driver, widgets can be drawn in any OpenGL context, from GLUT, SDL, etc. Event handling is another matter, though. Is there a simple way to feed FLTK events from an outside framework, rather than using its internal native code? Some of these other frameworks have rather more sophisticated and complete interfaces for setting up OpenGL contexts. (BTW, I noticed multisampling support was lacking from the OS X code...it's straightforward to add, see https://github.com/cjameshuff/fltkstuff/blob/master/src/pixfmt.cpp) Also, it seems that fltk3::gl_visual() has no effect on the settings GLWindows use...this was not what I expected. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
