On 19 Feb 2008, at 21:16, Evan Laforge wrote: > > 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).
Oh, OK... As long as the separation is clean, I guess that'll work fine... >> - 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. OK, but not forgetting the key point that, for reliability, the GUI thread has to be the main thread, and the non-GUI stuff goes in the child threads. Some time ago, I had a program that ran "fine" for a long time, then started to throw really odd errors on win32 hosts, from time to time. Turned out I was creating then destroying a widget in a child thread (doh!) and although it all seemed to be working fine, Things Were Not Right. A little switching round fixed it up just fine. What platform are you on, BTW? And are you aiming for portability to other platforms? > 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. Ah, OK. Tricky. > 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. Are lost events on exit an issue? I mean, if it's closing anyway... > 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. It doesn't have to be anything fancy, so you don't need to get into D- Bus and so forth - just hanging on the ends of a named pipe will do it, and you just send the events you are interested in, much as your EventCollector is doing, I imagine. But if your existing implementation is working, it's not obvious that would be any better. (C++ crashes aside, of course - mind you, my code doesn't crash.... ;-) _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
