Re: an interesting delegate design issue raised by IB...
Re: an interesting delegate design issue raised by IB...
- Subject: Re: an interesting delegate design issue raised by IB...
- From: "Michael B. Johnson" <email@hidden>
- Date: Wed, 12 Sep 2001 08:46:52 -0700
On Wednesday, September 12, 2001, at 02:21 AM, cocoa-dev-
email@hidden wrote:
Message: 7
From: Ondra Cada <email@hidden>
Date: Wed, 12 Sep 2001 10:31:40 +0200
To: "Michael B. Johnson" <email@hidden>
Subject: Re: an interesting delegate design issue raised by IB...
Cc: email@hidden
Reply-To: email@hidden
Michael,
[I've switched your 'delegates' to 'data sources']
Michael B. Johnson (MBJ) wrote at Tue, 11 Sep 2001 21:56:24 -0700:
MBJ> To deal with this, it seems prudent to supply a simple
MBJ> companion class (WK2DImagesSource) that can easily act as a data
source for
MBJ> any number of image views to supply them with images.
Possibly. You might consider also a NSComboBox-like way:
- if the instance does not have any data source, it uses its own internal
data management;
- if the instance has a data source, the internal management is not used.
MBJ> WK2DImagesSource, of course, is also on the same IB palette and the
user
MBJ> can drag one out and then wire up any number of image views to it.
...the above, of course, applies only in case (which I _PERSONALLY_ think
the image view would fit) that "it is quite probable that if such things
like
sharing the data between more views occur, user would usually write his
own
data source anyway".
This is the way I had it before (before I gave the image view a data
source that could be shared/wired up). It seemed that once I had moved
the image management code out of the image view it should stay out, but
maybe not.
The NSComboBox sounds like a good example - I'll go take a look at it.
MBJ> WK2DImagesSources each have an IB inspector, and the user can drag
MBJ> images (or use the "add image..." button) to add images to them, and
MBJ> then at run time these will be viewable from any WK2DImageView that
is
MBJ> using it as a data source.
Might be nice. I haven't tried to make any palettes recently though, and
I
recall someone said that the current API is (a) completely different to
the
OpenStep one, (b) completely undocumented. If this is true (I haven't
checked)
IB palettes API has only changed for the better (i.e. the stuff that used
to work still does and there's even more supported stuff, hence my renewed
interest in drag and drop in IB). I should point out - none of what I've
talked about is theoretical - I have a working palette with all of these
objects implemented. I was looking for feedback (which I've gotten -
thanks all!) before releasing the latest rev of WavesKit (see Softrak -
latest version should go out probably next week or so) so that I had my
discussion of what and why I decided to design it the way I did.
, you might have a real problem with that, since you'd have to
co-operate not only with IB, but with PB (which actually stores images) as
well.
Like I said, I'm hoping that Apple starts to open that avenue up soon with
API we can use, and so I'm planning for the possibility.
MBJ> Also, we make WK2DImageView conform to the WK2DImagesSources
protocol as
MBJ> well, so that other objects can, very naturally, add images to the
image
MBJ> view directly, although what the WK2DImageView will actually do is
MBJ> immediately pass the message on to its data source.
I would do _that_ only in case you decide to use the "NSComboBox-way" of
internal image management. Otherwise, I would not encourage developers to
do
somewhat hackish
[view addImage:xxx]
when the clean way is almost as simple:
[[view delegate] addImage:xxx]; [view reloadData];
Actually, this is something I don't understand. My image view registers
for notifications from its data source, and the data source sends out
notifications when images are added, deleted, or updated, so a call to
reloadData is unnecessary. This seems even cleaner to me - or am I
missing something that my scheme will miss?
Or, you can place a pre-composed object to palette (an ImageView already
connected to a DataSource). I don't know, though, whether the API needed
for
that is public.
This is easy to do. I already do it for a bunch of objects in my palettes.
--> Michael B. Johnson, Ph.D. -- email@hidden
--> Studio Tools, Pixar Animation Studios
-->
http://xenia.media.mit.edu/~wave