Fred Kiefer wrote:
Markus Hitter wrote:
Am 24.03.2009 um 09:07 schrieb Fred Kiefer:
The other change is to give up a special behaviour in GNUstep. Apple
documents that calls to [NSView setNeedsDisplay:] (and
setNeedsDisplayInRect:) only work as expected on the main thread.
GNUstep has some code that lets these methods do their work on a
secondary thread as well.
Isn't this a serious enhancement over Cocoa? As far as I can see,
there's nothing stopping you from writing Cocoa-compatible code with
GNUstep, so I'm not sure wether it's wise to introduce limitations
just
to enhance portability slightly. Any chance for a #ifdef
COCOA_COMPATIBILITY compile time flag or even a runtime check (global
flag which NSLog()'s a warning if set and this feature is used)?
Yes, it is an enhancement in GNUstep, but it costs run time and will
results in applications not being portable. What it does is to save
programmers that make changes to gui objects the hassle of restricting
these changes to the main thread, as only there setNeedsDisplay: will
work properly on Cocoa. But then, any application that relies on this
feature will fail on Apple systems.
As Markus already suggested, the gui could just NSLog a message from
-setNeedsDisplay: when it is called for the first time on a secondary
thread, saying that this feature is a GNUstep specific extension that
does not work on Cocoa. This is just the same way Apple warns developers
about the non-portable use of some APIs (in general deprecated ones).
IMHO, the only reasons for removing the ability to call -
setNeedsDisplay:
from a secondary thread would be that it noticeably slows down the gui
or that it complicates the implementation.
Wolfgang
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
