Re: GWorkspace.app Feature Request-- Tabbed Shelf

[Richard Frith-Macdonald]

On Friday, June 27, 2003, at 09:32  am, Nicolas Roard wrote:

> On 2003-06-27 02:08:47 +0000 "Vaisburd, Haim" <HVaisbur@Advent.COM> 
> wrote:
>
> Hi,
> > @protocol GSThumbnailRepository
> > (NSImage *) -thumbnailForURI: (NSString*) uri Size: (NSSize) size;
> > // (NSEnumerator *) ??
> > (NSArray *) -thumbnailsForDir: (NSString*) dir Size: (NSSize) size;
> > @end
>
> hm... I'm not sure, NSApplication iconForFile: is already there and
> used for getting a representation of a file. I think it's simpler to 
> use it.

That's an NSWorkspace method, not an NSApplication method, but
I agree ... using an existing API is much better than adding a new one!

> What I think is interessting is that the thumbnails are used 
> everywhere (well on each application using -iconForFile:),
> while if we relay on a service for that, only the application which
> explicitely wants thumbnail will ask for them. I duno, I think
> it's better to have a coherent behavoir between app ?

Would it not make sense for the existing iconForFile: method to ask a
service provider for the thumbnail transparently ...
eg. internally it might call [NSPasteboard 
+pasteboardByFilteringFile:ofType:]
where the type is a new one produced by 
NSCreateFileContentsPastebaordType(@"thumbnail")
Then any application (or other service provider) offering a standard
filter service of that type would be automatically invoked to provide
the thumbnail.

> > That spec tells about thumbnails for spreadsheets,
> > text documents, etc. I got an impression that only
> > the program that understands the file format can create
> > a thumbnail. That's the reason I liked the service idea
> > in the first place: the service could launch a process
> > that creates a thumbnail image if it's not there.
>
> hm... yes that's right, we ideally need that the applications
> themselves creates the thumbnails.
> For getting the thumbnails, I prefers to stay with
> NSApplication iconForFile; for creating them, in the
> first place a simple service could do it, for common
> (images) files. But effectively, having applications
> registering for creating thumbnails is interessting.

Yes ... they could do that using the service/filters mechanism.

> In fact, it leads to a more broad problem, it would
> be cool to have a way for an application to register
> themselves for doing some actions (DO's methods)
> Sort of services, but  more general, and directly
> callable by an application ...

I'm half enthusiastic, half dubious about that.

The standard services/filters mechanism provided by OpenStep
fits this particular usage very well.  Indeed, it provides such a
simple, easy mechanism that doing anything else to provide
inter-application services is probably foolish.

On the other hand, this mechanism does not fit well to a situation
where one application wants to send a lot of messages to another
to control it in detail (scripting etc).  Another more fine-grained
mechanism, with greater efficiency for lots of calls passing small
items of data (ie not going via the pasteboard) is needed for that.

The question is ... how could a registry of available methods be
managed and used in a simple way ... without a plan to make
that simple, we may as well just use protocols and DO directly.

>So an application could for example register and advertises themselves 
as capable of doing
>the two methods of GSThumbnailRepository; (but for a defined type of 
file);
>a potential calling application will then ask which apps
>understand the defined protocol and then call the app by DO.
> In fact, it joins what Stefan Urbanek discussed
> earlier in order to have a full scriptable environment...

Not really ... generating a thumbnail from a file is precisely
the sort of thing the standard services/filters mechanism
was designed for ... its really quite different from scripting,