Re: Two gui ABI changes

[Fred Kiefer]

Wolfgang Lux wrote:
> 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.
> 

OK, so I will forget about this second change and only do the other one.
Fine for me, I will also add that warning message Markus suggested,
similar to the way we do in in NSCell setStringValue:, that should do.

I just had a look at the only other place where we try to handle
graphics calls from a secondary thread, NSAlert, and the code there
looks wrong to me. Could somebody else please give a second opinion
before I start to clean that up?

Fred