[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) |
All,
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
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?)
2) Do we know what the behaviour is on MOSX?
Thanks, GJC
--- Kazunobu Kuriyama <kazunobu.kuriyama@nifty.com> 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
> Bug-gnustep@gnu.org
> 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:
http://www.petitiononline.com/pasp01/petition.html
-- Main Developer of Gorm (featured in April Linux Journal) ---
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/