Re: services
Re: services
- Subject: Re: services
- From: "Sven-S. Porst" <email@hidden>
- Date: Fri, 4 Jan 2002 03:22:07 +0100
>
Well, it's not really more or less ugly than other uses of the PB plist
>
editor. You could certainly suggest to the PB folks that they provide a
>
special-purpose services pane.
Well, using the PB plist editor is a royal pain especially for creating
all the dictionaries / arrays you need for the NSServices key... I guess
the PB people spending some time on implementing copy&paste or drag&drop
there would be much more useful as you could just copy things from other
projects. Right now opening one of the files in the 'pbroj' bundle in a
text editor seems to be the only efficient way of doing this and I
suppose this is considered 'bad' style.
My apologies for the following <rant>
>
Currently the various Applications and Services directories in the
>
standard domains are searched. In future we expect to be considerably
>
less location-dependent. [...]
>
Log out and log back in. Again, this is expected to change in the
>
future.
Talking about the future and more applications offering services, having
the ability to switch some of them off would be neat. Right now there are
almost 20 entries in my services menu... about 5 of which I actually want
- and I guess that we will see more applications offering services, so
we'll end up with a menu extending all over the screen offering very few
items we're actually interested in.
IMHO, ideally services would be provided in a contextual menu and only
display the items that actually work. Also I find it quite irritating
that the entries in the services menu use the current application's
language rather than the user's preferred language. This way the menu
looks differently when using an application that supports your preferred
language from what it looks like in applications that don't (because they
only provide an English localisation, say) - a bit confusing, especially
as the different items may be rearranged as their entries have different
names in different languages (e.g. the entry by 'Grab').
</rant>
>
Since there is no new documentation about services, the old
>
documentation remains the best source of information, even though it is
>
not entirely up to date.
It seems that HTML documentation has been upgraded from 'description
forthcoming' to proper documentation recently. In addition that
documentation is slightly different from previous versions of the
Services.pdf file in a few places. Most notably the current documentation
tells you to use servicesMenu.strings files for localisation where older
documentation allowed a dictionary with all localised menu entries. This
is significant as it causes the localisation for services provided via a
dictionary with localised strings to break.
Interestingly this is only true for Services menus displayed in Cocoa
applications. The Carbon Services Menu seems to be built seperately and
can hence look differently from the one in Cocoa applications (another
bug, I'd say). It seems that the Carbon Services menu is simply built in
the way the Info.plist files ask for it while the Cocoa Services menu
does some 'sanity checking' beforehand: (i) your menu entry won't appear
if the 'port' isn't your application's name in Cocoa apps [the probably
answers question 8 of the previous message], it always does in Carbon,
(ii) Your menu entry will _only_ be localised if the strings for this are
provided in the appropriate servicesMenu.strings file in Cocoa, whereas
in Carbon also localisations provided via dictionary entries for the
NSMenuItem key are used and (iii) in Cocoa apps your menu item will only
get it's desired key equivalent if it isn't used by the application
itself or any other service yet, whereas every service menu entry seems
to have its desired key equivalent in the Carbon services menu.
Sorry for being this verbose about the topic but after taking ages to
figure out why I ended up with four different menu entries for the same
service (two languages, giving different entries in Carbon and Cocoa...)
just to discover that the way things work has been changed, was a bit
frustrating.
Sven
--
Sven-S. Porst . PGP: 0x0085ABA3 .
http://homepage.mac.com/ssp
Why do they call this a word processor?
It's simple... you've seen what food processors do to food, right?
| References: | |
| | >Re: services (From: Douglas Davidson <email@hidden>) |