Re: CA broken; how do I differentiate NSValues for size and point?

[Ivan Vučica]

I added a test to the -base from May 20:

  NSPoint point = {.x = 16.0, .y = 32.0};

  NSValue *pointV = [NSValue valueWithPoint: point];

  result = !strcmp(@encode(NSPoint), [pointV objCType]);

  PASS(result, "@encoding(NSPoint) == pointV objCType");

  result = strcmp(@encode(NSSize), [pointV objCType]);

  PASS(result, "@encoding(NSSize) == pointV objCType");

with this temporarly ine:

  NSLog(@"%s %s %s", @encode(NSPoint), @encode(NSSize), [pointV objCType]);

It passes and prints out:

2018-05-27 17:27:38.823 size-point-encoding[25395:25395] {_NSPoint=dd} {_NSSize=dd} {_NSPoint=dd}

I''m annoyed at how I did not notice that I did use CGSize. I will introduce support for NSSize/CGSize.

Thanks!

On Mon, May 21, 2018 at 12:53 AM Fred Kiefer <address@hidden> wrote:

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 <address@hidden>:
>
> 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 <address@hidden>:
>>
>> 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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev