Re: Problem with NSColorWell

[Philippe Roussel]

Le vendredi 25 février 2011 à 00:00 +0000, David Chisnall a écrit :
> On 24 Feb 2011, at 23:37, Fred Kiefer wrote:
> 
> > Am 24.02.2011 21:14, schrieb Philippe Roussel:
> >> Le lundi 24 janvier 2011 à 12:58 +0100, Fred Kiefer a écrit :
> >> 
> >> [snip]
> >> 
> >>> This seems to be the problem here. There actually are two versions of
> >>> GSColorSliderCell loaded. One from loading the wheel picker and one from
> >>> loading the standard picker. It is exactly the same class coming from
> >>> the same file. But of course your code is correct about warning when a
> >>> class gets replaced by another one.
> >> 
> >> Just a reminder so this problem won't be forgotten.
> >> 
> >> I would like to help on this but my only idea is to move the
> >> GSColorSliderCell class to gui as a helper but I don't think you would
> >> like this...
> > 
> > You are right, I don't like this idea too much. The code in these class
> > would need a bit of rework to have it directly in the main gui code. But
> > if this is the only way to get GNUstep gui working for you with libobjc2
> > we will have to do that step. I was hoping for David to resolve the
> > issue in a compatible way in libobjc2.
> 
> In the current version, I've simply disabled this check.  I'd like to
> reenable it in the future.  Currently the Apple runtime logs a warning
> when you load a class twice and tells you that the one that will be
> used is undefined.  One of my aims with libobjc2 is to remove cases of
> undefined behaviour and turn them into hard errors.  It's easy for
> libobjc2 to ignore this, but -gui is definitely doing the wrong thing
> by loading two copies of the same class, so it is worth fixing.

Ok, I'm confused. Is this supposed to work with libobjc2 trunk, or some
released stable version ?

In trunk, objc_load_class still does abort() when loading an already
loaded class, maybe dumping a backtrace would be enough ?

Philippe