On Mon, 31 Jan 2005, Philipp Lohmann - Sun Germany wrote: > > Having done native widgets twice over (GTK, and then Aqua for NeoOffice/C) > > I spent the majority of my time with the Aqua stuff being frustrated with > > tying together the event model. There needed to be a couple threads: 1) > > The cocoa event loop for the NSApplication object, 2) The OOo event > > thread, and 3) The actual OOo drawing/everything-else thread. It seemed > > that even on a dual-processor machine, events took a while to get from > > Cocoa to OOo. The problem with Cocoa is that OOo tries to do too many > > things when an event is processed, including drawing and whatnot. Cocoa > > really expects the app to simply update its internal state and then > > re-draw itself when _needed_ (and asynchronously when it gets a drawRect: > > message) rather thabn OOo's method of "get a mouse click and update > > everything before returning". Or something like that. I kept running > > into really really long call-chains, deadlocks, and crashes resulting from > > this issue. > > Huh ? When you press a VCL button it should be drawn clicked. How should > aqua know that it has to send a "drawRect message" when a button got > clicked ? Should vcl call some kind of invalidate method instead ?
You got it. Some operations (like changing button state or poping up a context-menu) should be able to be done during the event loop, but Aqua really really does use MVC. Therefore, when the event comes in, the Model should get updated. You then invalidate the View, and when OS X decides to let you redraw yourself (remember, the Window Server only composites the offscreen window buffers to the actual framebuffer once every 60s or so anyway), _then_ you redraw the button based on its current state. Basically, you invalidate a portion of your window, say, the button that got clicked, when you get the event. Then, when OS X calls the drawRect: method on your NSView (inside of which is embedded an OOo VCL SalFrame) at some later date (you really don't have a guarantee when), you redraw that portion of your view based on the state of the elements within it. It makes perfect sense from a MVC standpoint, which most of Cocoa is coded to, but not much sense from a more procedural Win32/X11 standpoint. That's the real problem here, the Cocoa port had to work around the Cocoa view of event handling and updating, which OOo kind of combines into one big operation (for example, clicking the button actually calls the drawing routines to draw it depressed, rather than the Cocoa method of setting a "depressed" bit and handling the drawing asynchronously based on current state of the button's "depressed" bit some time later.) Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
