I just have to mention regarding this thread; perhaps I'm missing something but if I were confronted with the task of writing a plugin to an existing app that uses a different GUI toolkit than the one I'd be using in the plugin, I'd almost surely try to design the plugin such that my GUI runs in a separate process, and communicates with the plugin side via pipes/mmap/etc.
Or, I'd try to use the toolkit the app uses. Mixing GUI toolkits in the same process is almost sure to invite strange behavior, as the two will have conflicting interest over almost all events, as there's no clear delineation between events that toolkit A vs. toolkit B should ingest. For instance, a key down event might go to one toolkit which opens a window and causes the up event to go to the other, such that both toolkits might get confused about why it received one event without the other, and things like shift-states, window events, etc might all get into strange unexpected states that cause erratic behavior depending on mouse placement/focus, etc. Or so I would think. It just seems like it's asking for trouble to try to run two GUI toolkits in the same process. Using separate processes would at least ensure a clean delineation between events managed by one or the other, so that event pairs don't get split somehow between the two message queues. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
