Duncan Gibson wrote: > Looks like this runs almost, but not quite, in parallel with FLTK. > FLTK has only needed to consider one thread with Fl::run() in it > because that relates to a typical limitation in GUI handling by the > common operating systems.
The basic idea, because of this limitation, is to keep a single GUI updating loop by being able to move what run() does to a common, separate thread managed by the library. If you then have multiple plugins dynamically linking to the library, all loaded in a host of some sort (doesn't really matter), the first plugin can start() up this thread. Count is kept of the number of Context instances, so when the last plugin destroys its GUI, it knows to call stop() accordingly, shutting down the common "main loop" thread. (which can be restarted if a GUI opens up again) > However, your addition of a Context class might echo what has been > implemented recently for printing support. Maybe there's some common > ground. I'm not the best person to comment. I don't think there's so much common ground at present; were they both put in the same library, they would coexist each in its own area without overlap, I think. But there could be some potential for future development with the current device becoming context-specific... No idea exactly what could become possible in that case, though. Having several GUIs running the same instance of the library decide methods of rendering (native, OpenGL, etc.) independently and on the fly? If that worked, no idea what the use would be, though. > > I've also recently - in git repo - ported the UTF-8 API additions > > from FLTK1.3 and renamed and refactored some of it to make the API > > more consistent and get rid of some TODOs in the code. > > Do you have a summary of what you did? Could be useful, as FLTK-1.3.x > is trying to incorporate and harmonise the old O'ksi'D code from 1.2 > and UTF-8 code from 2.0. The utf.h header file, based on the one from FLTK2, is here: http://gitorious.org/flptk/flptk/blobs/raw/master/flptk/utf.h There you'll see the function prototypes and naming and how it differs in a few places (and how some things - a in functionality duplicate function, the commented-out ones, and a pair WIN32-only that was unused - are missing compared to the FLTK1.3 header). And the modified source file originally from FLTK1.3 is here: http://gitorious.org/flptk/flptk/blobs/raw/master/src/utf8.cxx For the string comparison functions there were \todo notes to "Correct incorrect logic where the length of strings tested"; this I did, mostly by removing code. Also clarified the length in one place where there was a \todo to do this. Also, with the FLTK2 API, conversion functions take two length parameters - a srclen and a dstlen - so for consistency I changed the added functions taking length that came with a warning that destination length must be three times the source length to instead also take a destination length. And all functions that had "utf" in their name are now named "utf8"-something. Then there was the removal of some duplicated code; Toupper was removed as XUtf8Toupper already exists in xutf8/case.c. All the deprecated, commented out functions and those things removed in addition from the header also removed. FLTK2 also has this file: http://gitorious.org/flptk/flptk/blobs/raw/master/src/x11/xutf8.cxx Which it #includes in x11/run.cxx It implements two things quite shortly, and keeping it (and adjusting as I did the name of one function to XKeysymToUcs) allowed the removal of the following files: xutf8/imKStoUCS.c xutf8/Ximint.h xutf8/Xlibint.h xutf8/keysym2Ucs.c xutf8/utf8Input.c ..which reduces bloat a little bit. Finally, the file xutf8/utf8Utils.c reimplements some things already in the utf.c file originating with FLTK2, and changing xutf8/utf8Wrap.c to this: http://gitorious.org/flptk/flptk/blobs/raw/master/src/xutf8/utf8Wrap.c (replacing calls to one function with a function originating with FLTK2) ..allowed me to remove xutf8/utf8Utils.c also. > You never know. Matt has been working on a Plugin architecture for > 1.3.x, but I don't know whether that would fit your needs, and it > may be desirable to have some sort of Context functionality. Only > time will tell once we have 1.3.0 out and can look at 3.0 and beyond. > > D. The Plugin stuff is more for having a FLTK host to a FLTK plugin; my case on the other hand is that the host could be using anything, the plugin APIs are varied and not based on the library, and the GUI stuff is a mostly independent thing that the plugins manage "on the side" to allow controlling their parameters. Time will tell, I guess. The overall direction of recent FLTK development is looking quite interesting... _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
