[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gregory John Casamento
Subject: Re: [PATCH (revised)] -setTarget: and -setAction of NSImageView
Date: Sun, 28 Dec 2003 13:42:36 -0800 (PST)


See below...

--- Kazunobu Kuriyama <address@hidden> wrote:
> Hi,
> Gregory John Casamento wrote:

<... my assertion from previous email about maintaining compatibility ...>

> In addition to the comment above, if someone could give another
> one on how an implementation using NSActionCell is technically
> inconvenient, I think it would be definitely decisive.

It's inconvenient for a number of reasons:
1) It is in conflict with the documented hierarchy for this class (in both the
docs and in the header NSImageCell.h).  

2) It will complicate decoding of previous versions of this class from .gorm
files since you will need to call the initWithCoder for NSCell instead of the
one for NSActionCell for all older versions of the class.   It is *NOT*
acceptable at all to simply allow the older .gorm files to break.   

As the maintainer of Gorm, the encoding of the classes in both gui and base are
critical to .gorm files and are under my purview. 

> The difference of the responsibilities between NSCell and
> NSActionCell is so obvious that Apple's engineers should
> know it. Nonetheless, they decided to make NSImageCell a
> subclass of NSCell (assuming the present document is still
> correct.). Because the decision appears utterly illogical
> to me, I think it is possible that the present document is
> incorrect.  If I knew the techical reason of the decision,
> I could easily withdraw my first view on the issue, i.e.
> use of NSActionCell.

I don't know why they did it that way either, but lacking that I don't think
that not knowing the reason is sufficient cause for changing the parent class
especially when it's documented this way and it's in the headers.

> >
> >
> >Before applying any patch, we should also verify the behavior of MOSX
> against
> >GNUstep.
> >
> >Two questions should be answered before we proceed:
> >1) Does NSImageCell need to have an implementation for the target/action
> >behaviour? (i.e. is the currently situation acceptable?)
> >
> As pointed out by Alexander Malmberg, this is clear from
> the documentation found at
> http://developer.apple.com/documentation/Cocoa/Conceptual/ImageView/. 
> For your convenience, I quote part of the article here:
> <quote>
> Using an Image View to Specify an Image
> ----------------------------------------
> You can use an image view as an image well, which lets a user specify
> an image by dragging an image to it. Just use setEditable: with an
> argument of YES.  When the user drags an image to the image view,
> the image view replaces its old image and sends its action to its
> target.
> <end of quote>
> However, according to Fred Kiefer's comment, this is not included
> in the OpenStep specs.

True, NSImageCell was not present under the OpenStep spec.  GNUstep isn't,
however, limited to the OpenStep spec and should not take liberties with the
classes which aren't specified there.

As I said before, we should follow the MOSX Cocoa Documentation.

> >
> >2) Do we know what the behaviour is on MOSX?
> >
> Unfortunately, I have no access to MOSX.  If there's someone having
> access to MOSX, I would appreciate it very much if she/he could try
> a sample program to see what happens on the MOSX with NSImageView
> having target/action.

I do have access to MOSX. :)  It is in the MOSX documentation for Objective-C
and Java with NSCell as the superclass.  It is also in the header as a subclass
of NSCell.  The idea that it's a "mistake in the docs" is soundly defeated

> The sample program is in CocoaProgramming-20021010/Chapter 9/Image Viewer 2
> in a freely downloadable compressed file.  You can download it from
> http://www.cocoaprogramming.net.  -setTarget: and -setAction methods
> used with an NSImageView can be found in an init method of MYDocument.m.
> Needless to say, if the program is linked against GNUstep, it terminates
> immediately after it begins running, due to an exception raised
> from either of the methods.

Well, that sounds like a problem which needs to be fixed, but changing the
class hierarchy in a way which is incompatible with MOSX isn't the answer.
> Thanks.
> - Kazunobu Kuriyama

Later, GJC

Gregory John Casamento -- CEO/President Open Logic Corp.
-- bheron on #gnustep, #linuxstep, & #gormtalk ---------------- 
Please sign the petition against software patents at: 
-- Main Developer of Gorm (featured in April Linux Journal) ---

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]