> > > > Also, since I am only ever calling FLTK from one thread, > > I don't think > > > > I need all the locking and unlocking. Is there a simpler way to > > Hmm, from your description it sounds (to me) as if there is more than > one thread in your process, so you do need to use the lock/unlock > methods - the fltk gui is one thread, and I imagine your haskell code is > (at least) one other thread.
Yeah, they're separate threads, same process, but I'm always calling fltk from the same thread, which is what the channels (called queues in other languages) are for. When someone wants to trigger a gui action, they drop the action on action_chan and wake up the fltk thread. When fltk has an event, it drops the event on evt_chan and goes back to wait(). So no gui action gets executed outside the fltk thread (in fact, I'll set up the types so that it's impossible to do so). > So, anyway, I (now) imagine that you have some complex piece of code in > haskell, and are wanting to stick a GUI front-end onto it - or is that > too much of a simplification? That's the idea, except that the haskell part isn't written yet. > Given that's the position, a few points: > > - You might want to switch around the order of your threads; There's a > basic problem that many hosts are not all that happy if you > create/destroy graphics objects from any thread in a process other than > the primary "main" thread (some OS/windowing systems have workarounds to > allow that, but fltk uses a "lowest common denominator" approach and > pretty much assumes all widgets are created/destroyed from the primary > thread, as do many other toolkits.) So, you maybe want to look at making > the fltk thread the primary entry-point thread, and have your haskell > code run in the child thread(s). Well, this is what I was hoping to achieve by shipping all gui actions over to the fltk thread to execute. > - Why does the haskell code have to get the gui events at all? What I do > is have the fltk gui run in the main thread, then it can handle all gui > interaction directly. Any gui interaction that has to be propagated to > the child threads is handled in fltk callbacks which send messages on to > the child threads. The child threads never see the gui events at all, > just the messages that the GUI thinks they need. The child threads can > (of course) use Fl::lock, unlock and awake to update GUI objects. Well, the haskell is actually going to interact with the gui on a fairly low level, to handle stuff like remappable keyboard shortcuts and chording in an application specific way. It is a balancing act between exporting a simple interface and exporting a flexible one. Anyway, it's up and running and seems to basically work, using my windows-as-event-collectors hack. It requires a dynamic_cast to get an Fl_Window to an EventCollectorWindow, but I can't really see a better way. I'm losing a few events when the windows shut down, but that's probably a bug in my code. I had also thought of running the gui as a completely separate process communicating via IPC, as a way to insulate the main application against c++ crashes, but the need to come up with an RPC protocol to ship the data over seems like a hassle. Has anyone done that with fltk? I know there are things like D-Bus and other RPC thingies out there that are meant to help with this kind of thing, but I don't really have any experience with them. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
