I added a bit of code in base that allows to use NSValue objects for size and point with methods for the other type. This is a bit closer to the Cocoa behaviour but will require more tweaking to have it fully correct. It will at least allow you to run this test code again.
> Am 20.05.2018 um 16:02 schrieb Fred Kiefer <fredkie...@gmx.de>: > > I spend some time to understand this issue. But to be honest it took me more > time to understand why this ever worked :-) > > The problem here is that base uses two different ways to provide concrete > subclasses for NSValue. One being GSValue, which supports generic data and > the other mechanism is to have a specific subclass for types like NSPoint and > NSSize. For the later base only generates specific methods for that types. > Resulting in different classes for NSPoint and NSSize, which are incompatible > although they have the same underlying data size. > In your demo application that animation for shadowOffset tries to set the > offset size with a suitable default value of class GSSizeValue. But the code > in GSObjCSetVal only compares the type information without looking at the > type names. That way NSSize is regarded as the same as NSPoint and the > pointValue get executed, resulting in the error you reported. Either > GSObjCSetVal has to be more careful and use a check for the actual type > first. Or we need to make the NSValue subclasses more general. > > But why did it work before? Most likely because at that time CGSize and > CGPoint, where different from NSSize and NSPoint so we did not get the > specific optimisation in NSValue. > > Hope this helps, > Fred > >> Am 20.05.2018 um 14:03 schrieb Ivan Vučica <i...@vucica.net>: >> >> Hi, >> >> Pretty much all Core Animation demos are currently broken under GNUstep with >> a variation on the following: >> >> 2018-05-20 12:54:25.464 QuartzCoreDemo[13476:13476] Problem posting >> notification: <NSException: 0x15b53b8> NAME:NSInvalidArgumentException >> REASON:[GSSizeValue-pointValue] should be overridden by subclass INFO:(null) >> >> CA is accessing -pointValue method if it determines that the passed NSValue >> matches the -objCType of NSPoint. It does not check for size values. >> >> Clearly, sometimes it is trying to interpolate size values, which will match >> the signature and it will incorrectly attempt to access -pointValue which is >> then not implemented by GSSizeValue. I am not sure where might it be >> interpolating size values, but it seems to be doing so. (Alternative bug is >> that NSValue is incorrectly ingesting points as sizes, then complaining when >> the point provided is being interpreted as a point. I can try checking this >> later.) >> >> I cannot check -respondsToSelector: because the class /does/ in fact respond >> to -pointValue; it just throws an exception. >> >> Adding a try/catch in this kind of situation would make for some very poor >> code hygiene, in my opinion. >> >> - Is NSValue supposed to be a class cluster like this? (Not on Mac at this >> time, can't check.) >> - Is there a way out? >> - Would it make sense to extend GSSizeValue and add -pointValue to it? >> (They're both 2d vectors.) >> >> Thanks >> _______________________________________________ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev