Re: Two gui ABI changes
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)? just $ 0.02, MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Two gui ABI changes
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Two gui ABI changes
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
Re: Two gui ABI changes
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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Two gui ABI changes
Fred Kiefer wrote: 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? I guess you mean the implementation of -beginSheetModalForWindow:modalDelegate:didEndSelector:contextInfo:. Yes, this is outright broken. The other point I noticed is the unusual memory handling of the private _GSAlertPanelCreation class w.r.t its panel attribute. This attribute is initialized in the -makePanel method but not released in -dealloc, which in principle means asking for a space leak. A more idiomatic solution would be to release the panel in _GSAlertPanelCreation's -dealloc method and retain the panel in the private getSomePanel function (which is the only place where _GSAlertPanelCreation is used). And probably it would be a good idea to use _GSAlertPanelCreation also when getSomePanel is called on the main thread (if only to ensure that any future fixes or changes to this code will apply to the main thread as well as to secondary threads). Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
