Re: System contextual menus
Re: System contextual menus
- Subject: Re: System contextual menus
- From: Ondra Cada <email@hidden>
- Date: Thu, 31 Jan 2002 16:03:23 +0100
Rainer,
>
>>>>>> Rainer Brockerhoff (RB) wrote at Wed, 30 Jan 2002 19:34:02 -0200:
RB> I strongly disagree about the utility of these services. Obviously a
RB> service menu item buried two or more levels down in the application menu
RB> is enormously less convenient to use than a contextual menu.
That's only a reason to press Apple to
- return the Services menu to the top level where it always was;
- bring back tearoff menus!
Otherwise, there is a strong ergonomic advantage of main menu compared with
contextual menu, caused by "all things are always on the same place", in
short.
OTOH, I do agree that installable contextual menu items in some cases would
be great, but more of that below.
RB> Also, using a service means that an application must be started; a
RB> contextual menu runs as a plugin. Much faster.
Nope, that's not true. The thing always has to be loaded and run, whantever
you do it; if your main app is heavy enough so this is a problem, just
implement the service in a lightweight companion app.
Besides this is actually unimportant, for unlike OS9 Mac OS X (actually,
NeXTStep) is designed to run any amount of applications for long long time.
Therefore, you truly might be annoyed by a long service response, *BUT* only
the first time after reboot -- which should mean roughly once a year, as soon
as the stupid installation packages which want reboot instead of sighuping
just those relevant daemons are fixed!
RB> Finally, the Finder supports only the "obsoleted Classic way". The Finder
RB> does not support file services at all.
Well, that' right. But why is that?
Actually the cure's simple -- use a decent filemanager instead of Finder.
RBrowser is what quite happily use yours truly; others are satisfied with
SNAX, and there's also MarshmallowMode, though it is rather a future promise
than useable thing now...
RB> it's still the standard. I have published two old-style contextual menu
RB> plugins and need to support them in my Cocoa applications; there seems to
RB> be no way to do that.
Now, this is and will ever be utterly impossible!
The thing is that there is *NO* system-level API related to this; there
perhaps is a *FINDER* API which supports that, but that's all.
Primarily, it should be pointed out explicitly what I had to grok from
context, that you want menus with file-related services.
The contextual menu _system-wide_ API (we are not speaking of an particular
Finder application anymore) though is just, as I've said, view-based. *IF* a
developer of a file-manager wants to use one for those views which represent
files, all right, there will be a file-bound contextual menu; if he does not
want, there won't be any. For example, RBrowser does not have a
file-contextual menu, and I, as its user, am *VERY* happy that it does not.
So, there is not, and unless API is seriously changed, will *NEVER* be, such thing.
The proper support for file-based services is Services.
Again, a developer of Cocoa application *can* find programmatically those
file-relevant Services menu items, and present a contextual menu over files
which would feature them.
That's the one and only one standard way how to support this. You can write
a piece of code which does this trick for your own applications; you can
press Apple to offer such code as a standard part of AppKit, and to document
it as The Good Thing for anyone who writes a file manager. I would opposite
that, but here it comes to personal GUI preferences.
Anyway, the *important* thing is that to provide file-based services you are
about to use Services -- so that any standard application written properly
(eg. Finder is not such an example, triple alas) can use them seamlessly.
RB> Hopefully, in some distant future, when the Finder becomes a Cocoa
RB> application, we'll be able to write Cocoa-based (instead of Carbon-based)
RB> system-wide contextual menu plugins, and have a Cocoa API to add them
RB> (optionally!) to our specific contextual menus.
So, once again, WE ARE ABLE TO WRITE THEM JUST THE VERY NOW: they are called
file-based Services.
The thing that they are *not* shown as a contextual menu (unless the
developer of an application himself decides so), but as part of the main
Services menu, is just a general system-wide UI decision. A very definitely a
bad decision from yours point of view, a very definitely good one from my
point of view; regardless personal preferences, it is the one which currently
applies.
RB> Now the question is: can I get at the Services API in a way that allows
RB> me to collect only the enabled services for my current context, and put
RB> them into my contextual menu?
Yep, see above. Actually I did not tried it myself, and there can be some
caveats (eg. I am not sure how and when the Services menu is filled, and thus
it is possible that if you try to read it in applicationDidInit: it would be
still empty, or so -- there might be some experimenting involved here).
Though, as soon as you solve this problem, you can easily programmatically
construct your own contextual pop-up menu, and fill it by all the relevant
Services. Of course, if you feel like, you can the very same way add the
text-based Services into the over-text-views pop-up menus, if you happen to
present sounds in your app, you can using the very same pattern add all
sound-based Services into contextual menus bound to sounds, the same applies
for images, etc, etc, ad infinitum.
Actually, since Cocoa is dynamic a object-oriented, you _CAN_ do that
_relatively_ easily even for 3rd party applications (provided they use
standard classes to display files): write an input manager similar to Mike
Ferris' TextExtras (or mine OCSmart Hacks). Do find (eg. using gdb) which
view class is used there to present files and how. Then add (or change) the
appropriate class' menuForEvent: by way of using category or poseAsClassing,
and implement the very same behaviour there.
RB> (Even so, there's still the serious
RB> limitation of having to start an application....)
It is not, see above.
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
2K Development: email@hidden
http://www.2kdevelopment.cz
private email@hidden
http://www.ocs.cz/oc