I don't know if it's possible to implement them using GNUstep. It should be possible in general, but I'm not certain. I thought that Apple as deprecating Carbon anyway.
There's something screwy going on with how the nib is being read when it's happening from your loader... I'm not sure why. I tested locally and a similar nib file loads just fine. I will try it with your loader and see if it fails in a similar fashion ASAP and let you know how that works out. GC GC On Wed, Mar 6, 2013 at 9:50 AM, Luboš Doležel <[email protected]> wrote: > Awesome, thanks! > > By the way - and this is a general question to anyone in the know - how > reasonable/feasible do you think it is to reimplement Carbon APIs on top of > Cocoa/GNUstep GUI? > I did some research of my own, but since I still lack the years of > experience in OS X development, I prefer to ask. > > The bad thing about the state of OS X APIs is that people still haven't > let go of these now decades old Carbon & other APIs... I'm not talking > about reimplementing all of it, but rather the basic stuff to get something > working. > > Luboš > > > On Wed, 6 Mar 2013 05:55:58 -0500, Gregory Casamento wrote: > >> Now that the release is done I'm going to take another look at this. >> I believe that if an NSCustomView is being encoded it should >> probably be converted into an NSView when it is decoded by the nib >> loader. >> >> I believe that this change will solve your problem. I'm going to >> make a change to GUI and send you a patch to see if that helps. >> >> As an aside, I recall you suggested I test in Gorm. I have come to >> a conclusion on this as well... >> >> Flat nib files like this one can't currently be loaded in Gorm >> because the loader doesn't have access to the metadata it needs to >> determine custom classes and other information which is normally in >> classes.nib and info.nib in older, pre XIB nib files. >> The classes.nib and info.nib files both contain certain mappings >> which are needed by Gorm to do the editing. Without them Gorm has no >> way of knowing what the superclass of the custom class is. The >> keyedobjects.nib file contains a pointer to the className of a custom >> class, but it will not provide the super class of that class. This >> is what the classes.nib file is for. >> >> Because of this I don't think that Gorm will be able to edit newer >> nib files beyond those created with 10.4/10.5, which is unfortunate. >> So the course of action in Gorm should be to perfect XIB handling >> in Gorm and also perfect the nib handling for the above mentioned >> versions of Mac OS X. >> >> All of that said, gui, since it doesn't require the same metadata >> that Gorm does since the above mentioned files are only for editing, >> should be able to load these files just fine once I've made my >> changes. >> >> I will report back here and post a patch for you to try. >> >> Thanks, GC >> >> On Tue, Dec 11, 2012 at 8:16 AM, Luboš Doležel wrote: >> >> Hi, >>> >>> as part of my OS X loader, I'm not trying out various Cocoa apps, >>> one of them being Bayon. >>> >>> https://itunes.apple.com/us/**app/bayon/id532348700?mt=12<https://itunes.apple.com/us/app/bayon/id532348700?mt=12>[1] >>> >>> >>> When starting the application under GNUstep/Linux, I get the >>> following error: >>> >>> 2012-11-06 12:57:34.728 Bayon[10234] NSView.m:4685 Assertion >>> failed in NSSplitView(instance), method initWithCoder:. >>> NSInternalInconsistencyExcepti**on >>> 2012-11-06 12:57:34.729 Bayon[10234] Exception occured while >>> loading model: NSView.m:4685 Assertion failed in >>> NSSplitView(instance), method initWithCoder:. >>> **NSInternalInconsistencyExcepti**on >>> 2012-11-06 12:57:34.729 Bayon[10234] Failed to load Nib >>> 2012-11-06 12:57:34.730 Bayon[10234] BNMainWindowController: could >>> not load nib named BNMainWindowController.nib >>> >>> The assertion in question is: [sub class] != [NSCustomView class] >>> >>> The problematic .nib file is attached. For obvious reasons, I can >>> mail the whole commercial app here. >>> >>> I can't absolutely rule out a bug in my loader (I do have unit >>> tests though), but Gorm not being able to load the file either >>> >> hints >> >>> at a possible bug in GNUstep. >>> >>> Could someone in the know please quickly take a look at it? >>> >>> Thanks a lot! >>> -- >>> Luboš Doležel >>> >>> > -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
