Re: GNUstep on 64 bit Windows - Patch for gnustep libobjc submitted
Hi Lars [EMAIL PROTECTED] wrote on 11.11.2008 19:12:34: It would be great of you if you could submit those patches also to the GCC mainline via http://gcc.gnu.org/bugzilla/ so that both forks don't diverge even further. Select libobjc as component in bugzilla (and be prepared for some follow up comments by others) regards, Lars In the meantime we have already submitted the patch to gcc mainline, too. We already got an permit to check it in, so expect to see it merged there soon, too. Regards, Roland ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep on 64 bit Windows - Patch for gnustep libobjc submitted
Am 20.11.2008 um 10:18 schrieb Roland Schwingel: Hi Lars [EMAIL PROTECTED] wrote on 11.11.2008 19:12:34: It would be great of you if you could submit those patches also to the GCC mainline via http://gcc.gnu.org/bugzilla/ so that both forks don't diverge even further. Select libobjc as component in bugzilla (and be prepared for some follow up comments by others) regards, Lars In the meantime we have already submitted the patch to gcc mainline, too. We already got an permit to check it in, so expect to see it merged there soon, too. That is great news! Regards, Roland Thanks, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Double initialization of custom (text) views in Gorm files
The -initWithCoder: method of GSTextViewTemplate in GSNibTemplates invokes the -initWithFrame:textContainer: initializer on self if the custom subclass of NSTextView implements that method. Unfortunately, this leads to a double initialization of instances and, in particular, any customization applied to the text view in the Gorm file will be lost. If anybody is relying on this weird semantics, I just wanted to inform you that I intend to remove that code, since it is definitely wrong (and neither compatible with the Cocoa documentation nor Apple's implementation). The correct way to initialize custom subclasses of NSTextView loaded from a nib file is either via -awakeFromNib or by providing a palette for Interface Builder so that the additional attributes of the custom class can be changed and archived. (Is this possible in Gorm?) Similar code is present in GSViewTemplate, GSTextTemplate, GSMenuTemplate, GSControlTemplate, and GSObjectTemplate and I intend to remove that, too. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Double initialization of custom (text) views in Gorm files
Wolfgang, These are what are known as designated initializers they are called on objects when a nib is instantiated on instances of custom classes only. This is what is described in Apple's documentation and fits with observed behavior on OpenStep and on Cocoa. If we can find a cleaner implementation for this, then I would suggest that we do that rather than removing the code. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Wolfgang Lux [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 4:25:05 PM Subject: Double initialization of custom (text) views in Gorm files The -initWithCoder: method of GSTextViewTemplate in GSNibTemplates invokes the -initWithFrame:textContainer: initializer on self if the custom subclass of NSTextView implements that method. Unfortunately, this leads to a double initialization of instances and, in particular, any customization applied to the text view in the Gorm file will be lost. If anybody is relying on this weird semantics, I just wanted to inform you that I intend to remove that code, since it is definitely wrong (and neither compatible with the Cocoa documentation nor Apple's implementation). The correct way to initialize custom subclasses of NSTextView loaded from a nib file is either via -awakeFromNib or by providing a palette for Interface Builder so that the additional attributes of the custom class can be changed and archived. (Is this possible in Gorm?) Similar code is present in GSViewTemplate, GSTextTemplate, GSMenuTemplate, GSControlTemplate, and GSObjectTemplate and I intend to remove that, too. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Double initialization of custom (text) views in Gorm files
Actually, sorry... from looking at this it seems that you're correct: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/SubclassingNSView/chapter_6_section_2.html I don't think that anyone is currently relying on that functionality within GNUstep. I might make some of these changes as well so that I can test them a bit and make certain that they reflect what is on Cocoa. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Gregory John Casamento [EMAIL PROTECTED] To: Wolfgang Lux [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 7:44:03 PM Subject: Re: Double initialization of custom (text) views in Gorm files Wolfgang, These are what are known as designated initializers they are called on objects when a nib is instantiated on instances of custom classes only. This is what is described in Apple's documentation and fits with observed behavior on OpenStep and on Cocoa. If we can find a cleaner implementation for this, then I would suggest that we do that rather than removing the code. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Wolfgang Lux [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 4:25:05 PM Subject: Double initialization of custom (text) views in Gorm files The -initWithCoder: method of GSTextViewTemplate in GSNibTemplates invokes the -initWithFrame:textContainer: initializer on self if the custom subclass of NSTextView implements that method. Unfortunately, this leads to a double initialization of instances and, in particular, any customization applied to the text view in the Gorm file will be lost. If anybody is relying on this weird semantics, I just wanted to inform you that I intend to remove that code, since it is definitely wrong (and neither compatible with the Cocoa documentation nor Apple's implementation). The correct way to initialize custom subclasses of NSTextView loaded from a nib file is either via -awakeFromNib or by providing a palette for Interface Builder so that the additional attributes of the custom class can be changed and archived. (Is this possible in Gorm?) Similar code is present in GSViewTemplate, GSTextTemplate, GSMenuTemplate, GSControlTemplate, and GSObjectTemplate and I intend to remove that, too. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Double initialization of custom (text) views in Gorm files
Wolfgang, I've commited a fix for this. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Gregory John Casamento [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED]; Wolfgang Lux [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 8:04:11 PM Subject: Re: Double initialization of custom (text) views in Gorm files Actually, sorry... from looking at this it seems that you're correct: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaViewsGuide/SubclassingNSView/chapter_6_section_2.html I don't think that anyone is currently relying on that functionality within GNUstep. I might make some of these changes as well so that I can test them a bit and make certain that they reflect what is on Cocoa. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Gregory John Casamento [EMAIL PROTECTED] To: Wolfgang Lux [EMAIL PROTECTED]; gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 7:44:03 PM Subject: Re: Double initialization of custom (text) views in Gorm files Wolfgang, These are what are known as designated initializers they are called on objects when a nib is instantiated on instances of custom classes only. This is what is described in Apple's documentation and fits with observed behavior on OpenStep and on Cocoa. If we can find a cleaner implementation for this, then I would suggest that we do that rather than removing the code. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Wolfgang Lux [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Thursday, November 20, 2008 4:25:05 PM Subject: Double initialization of custom (text) views in Gorm files The -initWithCoder: method of GSTextViewTemplate in GSNibTemplates invokes the -initWithFrame:textContainer: initializer on self if the custom subclass of NSTextView implements that method. Unfortunately, this leads to a double initialization of instances and, in particular, any customization applied to the text view in the Gorm file will be lost. If anybody is relying on this weird semantics, I just wanted to inform you that I intend to remove that code, since it is definitely wrong (and neither compatible with the Cocoa documentation nor Apple's implementation). The correct way to initialize custom subclasses of NSTextView loaded from a nib file is either via -awakeFromNib or by providing a palette for Interface Builder so that the additional attributes of the custom class can be changed and archived. (Is this possible in Gorm?) Similar code is present in GSViewTemplate, GSTextTemplate, GSMenuTemplate, GSControlTemplate, and GSObjectTemplate and I intend to remove that, too. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
