Upon further examination, I'm not sure that Fred's concern is valid. The reason the cell contents are not copied is because they don't have to be:
result = [[newCellClass alloc] initWithCoder: coder]; The above line in the method -(id)unarchiver:didDecodeObject: unarchives the proper attributes into the new instance and replaces the old instance of the cell. On Wed, Jun 26, 2013 at 1:35 AM, Gregory Casamento <greg.casame...@gmail.com > wrote: > Lubos, > > I'm not sure why you're saying it should only be used for looking up the > name. What leads you to the conclusion that this is all it's used for. > When I wrote it I did many backtraces to determine how it worked. > > If you have known object A and custom class B. "Known" classes are classes > which IB knows about (e.g. Cocoa classes) and can archive. A is what is > actually archived in the .nib file because that is what Interface Builder > can instantiate and save, but in the data structures which are saved in the > nib, there is a map which indicates that object A should be replace by an > instance of custom class B. The way this is indicated by the user is when > you select the custom class in the class inspector in IB. > > NSClassSwapper is certainly doing what it is supposed to be doing in this > case. The only fault, I believe is what Fred pointed out in an earlier > email. The cell contents and settings are not being copied and, perhaps, > they should be. > > Anyway, just adding my 0.02 to the conversation. > > GC > > > On Tue, Jun 25, 2013 at 7:48 PM, Gregory Casamento < > greg.casame...@gmail.com> wrote: > >> Wow, I really need to look into this immediately. NSClassSwapper does >> what its name suggests. It determines the custom class for a given object >> and instantiates it. >> >> It shouldn't create an object then destroy it immediately. >> >> >> On Tue, Jun 25, 2013 at 2:57 PM, Luboš Doležel <lu...@dolezel.info>wrote: >> >>> Hi, >>> >>> I've contacted the author and it seems it doesn't serve any purpose at >>> all, as is. >>> >>> "Sounds like one of the character encoding popups. The actual contents >>> of the menu are built dynamically at runtime." >>> >>> Which sounds logical, given that the item's description is "dummy" (and >>> the replacement class is "TUEncodingPopUp". >>> >>> Either way, GNUstep should somehow support it. What I don't understand >>> why isn't NSClassSwapper used only to determine the real class name. Why >>> first create a different object only to destroy it moments later? >>> >>> I also couldn't find out why -initWithCoder: on the new object doesn't >>> replace the child objects as well - which I'd guess would mitigate the >>> problem too. >>> >>> Luboš >>> >>> >>> On 06/24/2013 09:07 PM, Fred Kiefer wrote: >>> > This backtraces finally helped me understand what goes on here a bit >>> > better, at least I hope so. >>> > >>> > NSClassSwapper not only replaces a specific object, it also registers >>> > itself as the delegate of the decoder to be able to replace the cells >>> > used by that object. This happens here and the decoded cell gets >>> > replaced by a newly created cell without transfering any of the >>> > already set values. >>> > >>> > What I still don't understand is why the menu item uses its menu cell >>> > as the target. This ould be another difference to the GNUstep >>> > implementation. Could you please try to find out what the used action >>> > is? >>> > >>> > At the moment I still don't have an idea how we could work around >>> > this issue. We should try to find out more about it. >>> > >>> > Fred >>> > >>> > On the road >>> > >>> > Am 24.06.2013 um 11:49 schrieb Luboš Doležel <lu...@dolezel.info>: >>> > >>> >> Sorry for the spam, I have another backtraces providing a clear >>> >> picture, alhough they seem to be slightly different from the ones >>> >> before. >>> >> >>> >> You can see an object being set as a target, then deallocated and >>> >> then used (with SIGSEGV). >>> >> >>> >> Luboš >>> >> >>> >> >>> >> On Mon, 24 Jun 2013 10:21:18 +0200, Luboš Doležel wrote: >>> >>> What I forgot to add: >>> >>> >>> >>> Until gnustep-gui supports resource directory names like >>> >>> "en.lproj", you have to symlink English.lproj->en.lproj to make >>> >>> it work (GNUstep bug #36764). This bug also prevents apps from >>> >>> working when mounted directly from a .dmg file via my FUSE >>> >>> module, since the mounts are read-only. >>> >>> >>> >>> Lubos >>> >>> >>> >>> On Mon, 24 Jun 2013 09:52:51 +0200, Luboš Doležel wrote: >>> >>>> Hi, >>> >>>> >>> >>>> great! Feel free to contact me via Jabber (same as mail >>> >>>> address), should you run into any issues. >>> >>>> >>> >>>> Attached is the backtrace leading up to NSClassSwapper, as >>> >>>> Germán requested. >>> >>>> >>> >>>> Lubos >>> >>> >>> >> <darling-unarchiver2.txt> >>> >> _______________________________________________ Gnustep-dev mailing >>> >> list Gnustep-dev@gnu.org >>> >> https://lists.gnu.org/mailman/listinfo/gnustep-dev >>> > >>> >>> >>> -- >>> Luboš Doležel >>> >>> _______________________________________________ >>> Gnustep-dev mailing list >>> Gnustep-dev@gnu.org >>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >>> >> >> >> >> -- >> 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 >> >> >> -- >> 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 >> > > > > -- > 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 > -- 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 Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev