Duncan Gibson wrote: > > Just curious, what do you do with this obscure FLTK2 fork?
I've been thinking about making a post on it (FLPTK - Fast Light Plugin Toolkit - for lack of a better name) for some time now - a new one, that is; I made one during the early stages of the project about four years ago: (the list of differences from FLTK2 is outdated) http://fltk.org/newsgroups.php?gfltk.development+v:3682 That old post tells of the original problem in more detail; for what's happened since, the page at http://flptk.sf.net summarizes the present state. Right now, I - still - simply use it for the GUIs of my set of DSP plugins, though now also under X11. On the subject of FLPTK in general, there is mainly one thing on my mind in connection to FLTK right now: If the added functionality of FLPTK would find its way into some version of FLTK, then FLPTK would basically become obsolete and could be retired. No idea if it's relevant to FLTK, though. The main two things are: 1. In addition to run(): start() and stop() functions to start and stop the running of the main loop in a separate thread. Also, a call() function taking a function pointer and argument that ensures the call takes place in whatever the main thread is (and waits and returns the value). There's some changes to the lock/unlock/etc. system to make it possible to change "main thread" at any time and to remove the requirement of doing a lock() at the beginning of a program to enable threading. 2. This is the hard one - very tricky (and still not completely solved), in fact: Move global data that differs between multiple GUIs using the same instance of the library into a class, the instance pointed to by a global pointer being the present "context" (and each widget being assigned a context from this upon creation). There's also some smaller things, including a few valuator widget extensions. 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. But FLPTK also has bugs and issues of its own - in the parts that go beyond what I've largely been using it for. Recent thoughts have gone into planning to replace increasing portions of internals with FLTK1.3-derived ones. But perhaps FLTK3 could provide a way to go the other way around: Once up to scratch with FLTK2 functionality, perhaps an un-forking of FLPTK functionality (without compatibility stuff) could take place. That is, if said functionality is relevant for FLTK. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
