On 2 May 2007, at 05:55, Yen-Ju Chen wrote:
> Another thing I notice is that Jabber like to resize itself.
> Unfortunately, the GNUstep UI is different from Cocoa UI.
> While it is optimized for Cocoa, it actually breaks on GNUstep.
> So I really think for practical purpose, it may be easier to let
> users
> do the resizing.
Hypothesis: This is caused by the window receiving a resize message
while it is in the middle of resizing (which happens a lot during
initial roster loading).
The way GNUstep currently does the resizing is to schedule a load of
periodic events. It doesn't seem to do it in another thread (that I
can see), so it seems like it ought to block during the resize. The
use of periodic events seems slightly odd, since using usleep here
would have a lower overhead and not interfere with other parts of the
system.
Since I'm calling the resize method from the same thread both times,
this should work. I am a little confused that it doesn't, to be
honest. I'd be interested to see what happens if you modify
NSWindow.m to remove
[NSEvent startPeriodicEventsAfterDelay: 0 withPeriod: 0.02];
and
[NSEvent stopPeriodicEvents];
and replace
NSEvent *theEvent = [NSApp nextEventMatchingMask:
NSPeriodicMask
untilDate: [NSDate distantFuture]
inMode: NSEventTrackingRunLoopMode
dequeue: YES];
if ([theEvent type] == NSPeriodic)
with:
usleep(20000);
and add:
#include <unistd.h>
At the top of the file.
This should get rid of the NSInternalConsistencyError, and if it does
then it would probably be cleaner, and worth submitting upstream
(unless GNUstep has some pathological objection to using usleep, but
since it's POSIX, and GNUstep is pretty POSIX-dependent in general I
don't see what this would be).
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
