matthiasm wrote: > > Adding to my previous mail, here are a few features I would like to see > in the next FLTK: > ... > - callbacks for member functions > - signals
Aren't these two ways of doing the same thing? > - menu structures based on groups and children (already in FLTK2) > - abstraction of underlying OS libraries Specifics? > - support for embedded systems, WindowsCE I think it would be useful to ensure we can run on embedded Linux with a stripped-down X server. WindowsCE support should be fairly easy too, as long as we stick with the wide (Unicode) APIs and drop support for Win9x/WinME (yes, I know about the Win9x Unicode stuff, but it doesn't implement everything in WinCE or Win2k...) > - modularization of additional feature groups ??? > - plugin support from within FLTK For FLUID, or ??? > - documentation via Doxygen > - built in scripting via Python Bindings for FLTK, or the ability to run Python scripts in FLTK apps? > - layout files generated via Fluid, interpreted at run time > - shaped windows (already in FLTK2) > - labels containing images (already in FLTK2) > - plugin themes and styles I'm +0 on this; it can be useful, however I don't see a huge use case for this now. I'd be more interested in providing an easier theme/style API that can be easily extended, like we talked about for 2.0 about the time Carl dropped out... The advantage of focusing on the static case first is that we can get it working really well, and then experiment with different loaders to see which works best. > - typed drag and drop > > additional widget stuff: > > - higher lever application support > - direct support for communication like TCP/IP and serial ports -1, BSD sockets are universally available, and there are several good (C++ and C) libraries for doing serial I/O that are compatible with FLTK. > - built in multimedia support (sound, video) +1 for sound, +0 for video. There is a lot of extra stuff you'll need to synchronize audio and video - I'd guess it would be more useful to have a "Fl_Video_Window" or "Fl_Plugin_Window" widget that could be hooked up to XINE, Quicktime, etc. to provide the audio and video content. It might be interesting to provide support for simple animations (array of images, animated GIFs, MNGs, etc.), which might eventually lead you to a generic video/animation widget that could be used... > - simple OS support (threading, pipes, locks, messaging) -1 threading -1 pipes -1 locks +1 messaging (which we already have) I'm voting against the threading, pipes, and locks mainly because they are highly system and application dependent, and there are already many FLTK-compatible libraries that provide them in a cross-platform way. > additional device support: > - plugin system for additional devices like tablets, 3D mice, extended > keyboards +1 > - built-in support for tablet PCs For what, handwriting recognition, ??? > - screen drivers to support output to any kind of frame buffer This kindof falls under the embedded support... > OpenGL: > - built-in widget with full navigation > - maybe even a simple scene graph I think the scene graph scenario is already well-covered. As for "full navigation", do you mean flying/translating/rotating a scene? You could probably write a widget with a "draw" callback which handles drawing the scene with the viewport, viewing matrix, and modelview matrix initialized appropriately. I'm not sure how useful that would be for non-trivial applications, however. I've thought about adding a simple widget with navigation and animation that displays different canned shapes - cubes, cones, teapots, etc. - for use in fluid and prototype applications. I haven't done it, however, since I'm still not convinced of its usefulness aside from the "coolness" factor. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Document Software http://www.easysw.com _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
