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: Ondra Cada <email@hidden>
- Date: Wed, 12 Sep 2001 10:31:40 +0200
Michael,
[I've switched your 'delegates' to 'data sources']
>
>>>>> Michael B. Johnson (MBJ) wrote at Tue, 11 Sep 2001 21:56:24 -0700:
MBJ> One thing that bugs me about most data sources is that I
MBJ> still have to write them, even if I'm using the class exactly what it
MBJ> was designed for.
So, perhaps it sounds more reasonable now, does it not? Let's take
NSTableView as an example: does it bug you that you have to write a data
source even if you are using the table "exactly what it was designed for"?
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".
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), 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.
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];
MBJ> The natural way you would want to add images to an instance of
MBJ> WK2DImageView in IB is to just drag an image on top of it, right? Most
MBJ> natural thing in the world...
Not really, IMHO. You can make developers to d&d images not to ImageView,
*BUT* to the DataSource inspector. Although it might not look that
straighforward, IMHO it makes, from a _developer's_ point of view, *more*
sense. Actually, since the ImageSources protocol is defined well, it is quite
reasonable that some developer decides to use the DataSource object for a
_different_ task than to feed some ImageView; here's one quite practical
reason to implement the "filling" as a DataSource "attribute".
MBJ> except that it's using a data source. Which isn't connected until you go
MBJ> into test interface mode...
Another possibility is to use the NSComboBox-way (if you are willing to
accept the limitations). Then the image container code would be part of
ImageView, and no problem would occur.
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.
MBJ> a WK2DImageView has two instance variables, both of type
MBJ> WK2DImagesSource* .. One is also an IBOutlet (let's say it's called
MBJ> _imagesSource) so that a user sees it in IB, and the other is not (let's
MBJ> call it _myImagesSource). When the WK2DImageView gets init'ed, it
MBJ> makes/unarchives its own data source...
Unless I've overlooked something, it looks to me as a particular
implementation of the "NSComboBox-like" idea. Why not, looks reasonably to
me.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
private email@hidden
http://www.ocs.cz/oc