matthiasm wrote: > ... > 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).
Yeah, well, that's what we have the handle() virtual method for, right? > ... > 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. . I'd advise taking baby steps. Let's get the display, input, and OS code separated so we can mix and match a single display and input implementation on a particular OS, then we can worry about doing the dynamic bit. > ... > ;-) . 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. Given the printing will utilize most of the same code as display on Windows and Mac OS X, and since printing is a "core" function, I'm not sure that makes sense. Regardless, I think we'll be better able to make that choice once we have an implementation... :) >>> - 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. Hmm, yeah, I guess I've never found the lack of plug-in support (in FLUID or in FLTK) to be an issue when extending either. >>> - 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. IMHO that definitely falls outside the "light" category, and is also something that could be developed independently of the core library until there was an obvious need to integrate it with the core. > ... >> 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... . Ah, the limitations of Windows. There are some things that will always be non-portable, unfortunately... >>> - 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) Sounds like a job for an add-on library for embedded systems... -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Internet Printing and Publishing Software http://www.easysw.com _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
