Re: System contextual menus
Re: System contextual menus
- Subject: Re: System contextual menus
- From: Dan Crevier <email@hidden>
- Date: Thu, 31 Jan 2002 10:45:36 -0800
On 1/31/2002 10:13 AM, "David Catmull" <email@hidden> wrote:
>
on 1/31/02 8:37 AM, Ondra Cada <email@hidden> wrote:
>
>
> So it is a Carbon-specific API. Any way, it would be *QUITE* *BAD* to
>
> exploit it instead of the file Services, which are *THE* system-wide API for
>
> providing file-based services in OSX.
>
>
Services can't be considered "system-wide" until Apple makes it work in
>
Carbon apps. The current Carbon Event based implementation leaves something
>
to be desired, even aside from the fact that it's broken.
Contextual menu plugins and Services are very similar, and I wish Apple had
found a way to unify them into a single UI/API. Both have the basic goal of
letting you select something in an application and having an extensible
mechanism for other apps to operate on the data. Here's some differences:
Contextual menu plugins:
* Only available to Carbon apps
* Easily accessible from contextual menu when control clicking on something
* Data about selection is passed via an AEDesc
* Getting data back into the app has to be done via AppleEvents, so it's
much less standard
Services:
* Very limited support in Carbon apps (but getting better)
* You have to dig to get to the Services in the menu
* Data is passed in and out via a clipboard/PasteBoard mechanism
I think it's very confusing to the user to have these completely different
UIs for the same thing. I wish Apple would just show the Services at the
bottom of contextual menus intermixed with the contextual menu plugs. And,
contextual menu plugins should show up in the Services menu. Why should the
user have to know the difference?
It also seems like Apple could pretty easily support contextual menu plugins
by putting the copy types that would go a Service into an AEDesc and pass it
on to the Contextual Menu Manager.
Dan