Dan,
the current solar mutex and its (weird?) concept will likely be removed in OOos next major, favoring something called "UNO threading framework" instead. Hopefully addressing any current headaches regarding locking/synchronization you may have :-).
While talking about Cocoa, I hope it does not have such a strange concept as a thread affine API (as W32), does it?
Kay
Dan Williams wrote:
On Mon, 31 Jan 2005, Daniel Vogelheim wrote:
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 ?
I have seen GUI code (GDI and Swing, if I recall correctly) that uses exactly this strategy: Drawing only ever occurs at the system's request. If the app wants to redraw something, it sends an invalidate call to system and later handles the corresponding redraw event. The advantage is a) uniform redraw handling, and b) the system may optimize such events. (E.g., don't redraw hidden things, or batch small redraws into a single event.) I thought this was common, but as my initial disclaimer says: I haven't done any GUI stuff in a while, and never with OOo.
This is also how Aqua/Cocoa works.
However, I do find it rather strange that immediate redrawing could possibly cause application instability. I can't help but think that Cocoa must be at fault...
This wasn't the part causing the instability, it was the long call chains. First, when calling OOo's MouseDown function directly from the Cocoa event processing function, I ran into a lot of locking issues that I didn't really want to deal with. Furthermore, performance really sucked since the app was blocking while OOo was doing all its drawing. Worse yet, some menu calls run dialogs that would then sit in the OOo event loop and block the rest of the app since they hadn't returned to the event processing function because they called Dialog::Run().
Cocoa Event loop gets Menu Down Calls OOo menu down function for the Menu Calls Dialog::Run() Expects events, but none happen because we are no longer processing events because we haven't returned to the Cocoa event loop
The second pass I did was to have the App's Cocoa event loop in a separate thread and pass the events into a queue, that the main OOo thread would pull events from and shove them to the rest of OOo. That also proved to be quite slow and had issues with multiple windows (like Dialog::Run() which enters a completely new iteration of the OOo event loop). Dialogs were severely unstable, as were menus, since pulling down menus is controlled by the _system_ and not the application. OOo wants to control the menus, so menus were also slow as the Cocoa events were bridged to the menu system. Furthermore, since OOo wants to know stuff like "did the menu get clicked on, if yes let me modify its structure", that code would get run in the main Cocoa thread of the application and cause some of the lcokign issues. Forwarding the events to the OOo event thread would be useless since the menu was already pulled down before the OOo event thread would get the signal, and the OOo would want to modify the menu's items _while the menu was down_. Worse, Cocoa only allows each submenu to have only 1 parent, while OOo tries to pass the same menu structure around between windows because it expects each window to have its own menu bar.
Part of this is my failure as a developer, and part of it is the mismatch between Cocoa and OOo. Some of the problems were solved (for example the submenu parent problem) through gross hacks (re-parent the submenu when any of its parents is pulled down), and some were not (the menu-expose event calling OOo code directly).
Patrick and Ed seem to have made some very good progress with many of these issues with NeoOffice/J, since it uses soem of the same concepts (the Java event code is in a separate thread from the OOo event loop and they use a queue to share pass events to each other).
Dan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
