Re: [PATCH (revised)] -setTarget: and -setAction of NSImageView

[Kazunobu Kuriyama]

Fred Kiefer wrote:

> Alexander Malmberg wrote:
>
> > Kazunobu Kuriyama wrote:
> >
> > > --- gui/Headers/AppKit/NSImageCell.h    2003-12-29 
> > > 13:57:42.000000000 +0900
> >
> >
> > [snip]
> >
> > > +  int _tag;
> > > +  id _target;
> > > +  SEL _action;
> > > +  id _control_view;
> >
> >
> >
> > However, the general idea was to add target and action. Adding a tag and
> > a control view effectively turns NSImageCell completely into an
> > NSActionCell, it isn't required to get dragging working, and it isn't in
> > apple's docs (but then, target and action aren't, either).
> >
> > However, I think adding them now is the right thing to do. The cost
> > (amount of code) is low, it makes NSImageCell more useful, and by adding
> > all the stuff at once, we won't have to change the ivar layout/encoding
> > format twice if it turns out that we want them later (eg. because apple
> > really did add them, or will).
>
> I don't see any benefit in this additional ivars. Also the main 
> problem why there still is no patch for this is on a different level. 
> What we need to decide is wether to implement the storing of target 
> and action on the cell (as gets done by NSActionCell) or on the view 
> (as done by NSMatrix and loads of others).

(I don't understand the meaning of the second sentence exactly, though. 
A kind of insult?)
But it was you that was strongly against the idea of making NSImageCell 
a subclass of NSActionCell.
And as you already know, the implementation of target/action is usually 
left to a cell. So introducing
ivars in NSImageView, not in its cell, rather looks unnatural.  What 
kind of benefits do you see when
NSImageView itself has the ivars?  What is done with NSMatrix is based 
on the fact that it accepts
multiple cells.  On the other hand, NSImageView has only a signel cell.  
Why is such an exceptional
complexity needed for NSImageView?

> Here only a test on a MacOSX system could show how Apple did introduce 
> this partly documented feature.

To prove the patch is wrong, what kind of test do you ask a volunteer?  
Even if I were an owner of MacOSX,
I wouldn't know what to do.  Check the symbols of the binary?

> But no one with a Mac system has commented on this up to now, that is 
> why the problem may stay unresolved for some more time. 

I don't like blaming other people having a Mac because they are not 
responsible for this issue.

> There is no abstract way of telling which way around it should be 
> done. As both are in themselves valid.

This assertion itself is too abstract.  I feel you've not provided us 
your rationale enough to put off
the decision.  Do you think they are *equally* valid?

> > Anyway, unless there are any other ideas about what to do about this,
> > I'll commit this (with the above issues fixed) soon.
>
> No, please wait until this question gets answered. If we get the 
> encoding wrong once, we will have to support it for ever! 

('for ever' is too strong, isn't it?.  Who really does that?  Do you?  
If the existing implementation is
perfect, no contribution is needed.)  I wait and see how the core 
members deal with this particular Cocoa
extension.

- Kazunobu Kuriyama