On May 26, 2007, at 7:47 PM, Michael Sweet wrote: > 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?
The first is really only a callback witch slightly more syntax. The second can be everything up to a rather complex messaging system. The advantage is some kind of listener system, so you can tell the widget A that someone is interested in "LEAVE" events. widget A never has to know the slightest thing about the receiver(s). >> - menu structures based on groups and children (already in FLTK2) >> - abstraction of underlying OS libraries > > Specifics? I would like to have a very low level interface for drawing, surfaces, windows, and events, so that we can separate the OS specific code entirely form the core. A nice feature would be if we could support multiple rendering surfaces (so we could render FLTK widgets into an OpenGL widget, or into RAM, or into a video overlay, etc. etc.). The same would exist for different inputs, so we can directly support different game pads, tablets, etc. . >> - 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...) Yes, I have it partially running on CE already. Very neat! >> - modularization of additional feature groups > > ??? ;-) . I had to think for a few seconds myself what this meant. I like the separation into FLTK core, FLTK OpenGL, and FLTK images. If we add all these other features, printing, for example, should go into its own module as well. >> - plugin support from within FLTK > > For FLUID, or ??? Yes, that would be the first use. But looking at the previous point, I dream of a way to add features to the library by using binary plugs. It is just one of those features that are repeatedly dropped because the initial steps are difficult (just like with Fluid ;-). Once an app has plugins working, new ones usually pop up like mushrooms after rain. >> - documentation via Doxygen >> - built in scripting via Python > > Bindings for FLTK, or the ability to run Python scripts in FLTK > apps? Binding already exist. I would suggest a module (there is that word again) that makes it easy to call Python, but also gives the Python script a way to manipulate back into FLTK. "Python" is just a place holder here. The main goal is that internal and global scripts can control FLTK applications. A bit like AppleScript, or ARexx back then on the Amiga. If it was built-in, all FLTK apps would benefit greatly. >> - 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. True. This one was very low on my list anyways. It would probably be much better if we could get a great designer interested and have a new FLTK theme developed that woudl be acceptable on all platforms (dreaming again, am i ;-) >> - 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. Yes, true. I will post that eventually as a third party widget. >> - 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. That's what I meant. I have a somewhat working Fl_Quicktime_Widget that I used in an app. > 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... Hmm. Nice. >> - 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. OK, granted. I just wish that the Fl::add_handler function would handle all file types on WIN32, not only sockets... . >> - built-in support for tablet PCs > > For what, handwriting recognition, ??? Nope. That is far too complex and I would leave that to the OS entirely. I think of a keypad popup windows fro numeric Fl_Inputs, keyboards for the text widgets (optionally using the OS provided one), and pen support (using the rubout end of a pen to delete text, receiving the pen pressure), and a widget for freehand drawing mixed with text (yeah, I am a big Apple Newton fan) >> - 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. Granted, yes. > 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. I do have the code for some of the navigation stuff already. It takes a lot of load of the programmer when handling all the keyboard focus stuff (something that is simple for us, but difficult for many outside developers), the trackball interface including quaternions, so that all the user has to do is draw the OpenGL objects themselves. A point could be made that navigating a 2D image should then also be possible. But Yuri had a great comment: he's using FLTK because it is minimal - and I am abviously overshooting the goals here. Matthias ---- http://robowerk.com/ _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
