[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: Sat, 27 Dec 2003 20:26:17 -0800 (PST)


We should remain the same as MOSX, and leave the class heirarchy alone. 
NSImageCell is, according to Apple's latest docs, a subclass of NSCell.   Why
they did it this way, I'm not sure since NSActionCell would make more sense.

I realize that this assertion might get some ires up, but here goes: For any
and all classes which are part of the GNUstep API which have the NS* prefix and
are therefore intended to be compliant with the OpenStep standard OR provide an
implementation of a Mac OS X class we should at all times maintain
compatibility  with the spec (where the spec is either the OpenStep
Specification or the MOSX Objective-C Developer Documentation for Cocoa).

Before applying any patch, we should also verify the behavior of MOSX against

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?)
2) Do we know what the behaviour is on MOSX?

Thanks, GJC

--- Kazunobu Kuriyama <address@hidden> wrote:
> Hi,
> Attached are revised patches to make NSImageView receive -setTarget:
> -setAction methods and invoke the action when an image on another view
> is dragged and dropped onto an NSImageView in question.
> According to two suggestions I got so far, each of whic by Alexander
> Malmberg and Fred Kiefer respectively, I offer two solutions. This is
> because I'm not sure which is better and think decision should be made
> on the basis of broader point of view, which I can't say I have. I
> appreciate it very much if someone could do it.
> I hope, at least, these patches help further discussion on the
> issue by virtue of saving someone's labor.
> Solution01: Make NSImageCell is a subclass of NSActionCell
> ----------------------------------------------------------
> Changed Files: NSImageCell.h, NSImageView.m, and ChangeLog
> (pros) Only few lines of code to modify the behavior of NSImageView.
> (possibly) Doesn't require recompilation of applications.
> (cons) Doesn't conform to doc.
> Extra methods inherited from NSActionCell proper.
> According to the suggestion by Alexander Malmberg, -performSelector
> is replaced with -sendAction:to:. However, no changes are made
> in -initWithCoder: or -encodeWithCoder:, because the modification
> doesn't add new ivars. Also, because -initWithCoder: and -encodeWithCoder:
> of all relevant classes look fine to me, I'm wondering if they really need
> to be modified.
> Solution02: Keep NSImageCell a direct subclass of NSCell and
> ------------------------------------------------------------
> and add new ivars to it
> -----------------------
> Changed Files: NSImageCell.h, NSImageCell.m, NSImageView.m, and ChangeLog
> (pros) Conforms to doc.
> (cons) (possibly) Requires recompilation of applications.
> Though NSImageCell is a direct subclass of NSCell, it receives
> -setTarget: and -setAction: without raising an exception.
> A little bit confusing, raising another question, "What is
> NSActionCell for?"
> This solution owes to Fred Kiefer's suggestion. Because some new ivars are
> added to NSImageCell:, -initWithCoder and -encodeWithCoder: are modified so
> that they can deals with the new ivars properly. The class's version is
> changed to 2 from 1 to guarantee backward compatibility to some extent. New
> methods relevant to target/action are also added: most of them are
> duplication
> of those found in NSActionCell.
> The target/action ivars are held in NSImageCell. They are explicitly invoked
> with -performDragOperation: of NSImageView. This method sets a given new
> image only if the view is editable.
> Now an action is in NSImageCell, it might be accidentally/unexpectedly
> called, dependening on a given situation. If so, this requires
> another fix on the patches or somewhere in -gui. Some tests on this
> is highly likely to be needed.
> - Kazunobu Kuriyama

> ATTACHMENT part 2 application/x-gzip name=Solution01.tar.gz

> ATTACHMENT part 3 application/x-gzip name=Solution02.tar.gz
> _______________________________________________
> Bug-gnustep mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-gnustep

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]