[dizm]

Pretty obvious that whoever was working on that was mostly trying to reverse engineer UIKit vs. update GNUStep for touch. There are even commented out lines that are what would be output by class-dump.

I wonder if the straight reverse engineering/possible decompiling is why it was pulled so fast. Also, it's subtle, but there is a reason Apple didnt simply graft touch onto AppKit like this project is/was attempting.

[postfuturist]

I didn't see that at all. The gesture recognition stuff all looks written from scratch and the integration code doesn't match anything from UIKit. There are thousands of lines of code added by Sony with only a few commented out sections, mostly well-commented code also. The only thing I could see that remotely looks like what you are talking about is this

    // Adding and removing targets and actions
    //- (void)addTarget:(id)targetaction:(SEL)action;
    //- (void)removeTarget:(id)targetaction:(SEL)action;


    // Adding and removing targets and actions
    /***
    - (void)addTarget:(id)targetaction:(SEL)action
    {
    }

    - (void)removeTarget:(id)targetaction:(SEL)action
    {
    }
    ***/

This is an unused interface in SNGestureRecognizer. The name of one of the methods, addTarget, is the same as something from UIKit's UIControl. It's hardly a smoking gun, as it is unused and doesn't even match the method signature of the one from UIKit:

    - (void)addTarget:(id)target action:(SEL)action forEvents:(int)eventMask;

It's certainly not the result of a reverse engineering dump. If anything, Sony engineers thought for a second that they would mimic UIKit's interfaces and then quickly scrapped the idea. The other commented regions look like you might expect from a normal codebase:

    /*** Cannot assume touches will come simultaneously
    // Not a valid pan if # of touches on view doesn't match
    if ([touches count] != numberOfTouchesRequired ||
        //[_view touchCount] != numberOfTouchesRequired)
        [_hitTestedView touchCount] != numberOfTouchesRequired)
    {
       if (_state == SNGestureRecognizerStatePossible)
          [self changeState: SNGestureRecognizerStateFailed];
       else
          [self changeState: SNGestureRecognizerStateCancelled];  

       return;
    }
    ***/

[panic]

I believe dizm was referring to the header and class interface, not the source. The header is more or less ripped directly from UIKit, with some puzzling additions. What is the point of adding a "vulture" without also adding an "obstacle", for example? It seems like these methods should be private, not exposed in the public header.

[dizm]

SNTouch.m is one example with stubbed out class-dump methods.

The naming in every place that it can is lifted directly from UIKit, and then their changes use different naming conventions. For example the new instance variables in NSView.h.

[postfuturist]

Which methods in this SNTouch.m ( https://github.com/deliciousrobots/gnustep-gui-sony/blob/mas... ) are stubbed out class-dump methods and what UIKit class do they come from?

Where were the new instance variables in NSView.h copied from? I've been comparing them to class-dumps ( http://code.google.com/p/iphone-dev/source/browse/#svn/trunk... ) of Apple's code and I don't see anything like what you are describing. Care to show some examples?

[saurik]

//- (struct CGPoint)locationInView:(id)fp8;

That line (and the one later for previousLocationInView:) is straightforward "class-dump output". Did you bother to look at the file? :(

[postfuturist]

Yes, that's a comment, not a stub, but I get it now. :)