I'm not certain. I'm currently trying to build Darling with the latest GNUstep
in order to test.
My current hypothesis is that there have been changes in how some classes are
archived in later nib versions and the current code isn't reading some
properties correctly.
Gregory Casamento
On 08/09/2013 10:02 AM, Gregory Casamento wrote:
I'm not certain. I'm currently trying to build Darling with the
latest GNUstep in order to test.
My current hypothesis is that there have been changes in how some
classes are archived in later nib versions and the current code isn't
reading
On 08/09/2013 11:05 AM, Luboš Doležel wrote:
Is it possible that there are two different selectors with the same name
in the system, one invokes the superclass' implementation and the other
one invokes the the subclass' implementation?
Okay, this is now confirmed.
This code works as
On 9 Aug 2013, at 11:18, Luboš Doležel lu...@dolezel.info wrote:
Which is quite interesting, because I never stated that obj is of type
NSView*, it is still just id. Is it legal for compiler to assume that?
The compiler has to know the types of the arguments to be able to create the
call
On 08/09/2013 12:30 PM, David Chisnall wrote:
On 9 Aug 2013, at 11:18, Luboš Doležel lu...@dolezel.info wrote:
Which is quite interesting, because I never stated that obj is of
type NSView*, it is still just id. Is it legal for compiler to
assume that?
The compiler has to know the types
On 9 Aug 2013, at 11:44, Luboš Doležel lu...@dolezel.info wrote:
Signature of initWithFrame: (NSRect) with GNUstep is: @16@0:8
That doesn't look right. That's the signature for a method that returns an
object, but takes no parameters other than the receiver and selector.
David
-- Sent from
On 08/09/2013 12:46 PM, David Chisnall wrote:
On 9 Aug 2013, at 11:44, Luboš Doležel lu...@dolezel.info wrote:
Signature of initWithFrame: (NSRect) with GNUstep is: @16@0:8
That doesn't look right. That's the signature for a method that
returns an object, but takes no parameters other
On 9 Aug 2013, at 12:22, Luboš Doležel lu...@dolezel.info wrote:
Right, sorry, it is @48@0:8{_NSRect={_NSPoint=dd}{_NSSize=dd}}16
So I assume the right solution is to create a substitutes table to
rewrite CGRect-_NSRect etc.
That would certainly work, although the correct solution is