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
