.service was also designed to allow for dynamic services where an app could write out just the info.plist in a bundle.service and the NSServices key points to services offered by other apps. You could then have services created by apps using a single entry point with different user data to take different actions.
*Unfortunately* the implementation in the last couple versions of OS X continues to have serious bugs with this. Unless you have an executable, both the Finder & the Service menu handler put a "not compatible executable" badge on your icon. And as a bonus, since sandbox apps cannot write to ~/Library/Services/ without the user specifying it (and not being able to offer help pointing them to the invisible ~/Library folder)-- there is no easy way for apps to specify dynamic services in sandboxed apps. Btw.. the solution I used to prevent Services from bringing the app forward is to have a background (LSUIElement) helper app that acts as the NSServices provider. Depending on what you need to do, you could either support the service directly in the helper app or use it to talk to the parent app to perform the necessary work (without requiring it to activate). I use the second approach. Mark On Thu, Apr 4, 2013 at 5:02 AM, Uli Kusterer <witness.of.teacht...@gmx.net>wrote: > I wrote CodingService a while ago ( > http://the-void-software.com/codingservice/), and as far I can see from a > quick glance at the sources, all a .service is, is a faceless background > application (LSBackgroundOnly == true in Info.plist) where you change the > suffix in the build settings from .app to .service. > > It has the same NSServices key in its plist as a regular application > implementing services would have, an app delegate, a main xib that > instantiates it, etc. > > Cheers, > -- Uli Kusterer > "The Witnesses of TeachText are everywhere..." > http://www.zathras.de > > > On Apr 2, 2013, at 10:43 PM, Kevin Callahan <kc...@mac.com> wrote: > > On Apr 2, 2013, at 11:03 AM, Andy Lee <ag...@mac.com> wrote: > > > >> I'm writing an app that provides an NSService. Is there a way to have > the app not activate when the service is invoked? > >> > >> Alternatively -- where can I find good docs and/or sample code for > creating a standalone .service bundle? > >> > >> --Andy > > > > Hi Andy - I ran into this same problem. > > > > When Accessorizer first came out in 2002, it was just a standalone > NSService, not an app. However, because it needed to grow into an app in > order to have settings, options and other things, I converted it to an app. > Besides, several developers actually wanted it to be an app so they could > work within the app itself. > > > > I couldn't figure out how to keep it from being activated once a > service was invoked. > > > > The solution I came up with is two-fold: > > > > 1) I inform my users to minimize Accessorizer to the dock. I also > have a preference for minimizing to the dock upon launch. So, if a service > is invoked, and if Accessorizer is not running, then Accessorizer will > launch, minimize itself to the Dock, and perform the service. At least > this keeps Accessorizer's interface from being brought to the front and > blocking Xcode. However, Accessorizer, at this point in the process, is > still the active app. To solve that: > > > > 2) I have preferences to activate the editor (Xcode or TextMate) > after a Service or Accessorizer Action (Accessorizer uses just one Service > invocation for 28 code gen actions that you can pick from a status bar menu > or floating menu). > > > > The effect is that you never leave Xcode. This works in full > screen mode as well. I have other preferences for auto-inserting the > results into Xcode at the current insertion point. > > > > So, basically, my solution was to minimize my app, do the service > work, then activate Xcode, then insert results. > > > > Maybe there's a better way? > > > > -Kevin > > > > > >> > >> _______________________________________________ > >> > >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > >> > >> Please do not post admin requests or moderator comments to the list. > >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com > >> > >> Help/Unsubscribe/Update your Subscription: > >> https://lists.apple.com/mailman/options/cocoa-dev/kcall%40mac.com > >> > >> This email sent to kc...@mac.com > > > > _______________________________________________ > > > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > > > Please do not post admin requests or moderator comments to the list. > > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > > > Help/Unsubscribe/Update your Subscription: > > > https://lists.apple.com/mailman/options/cocoa-dev/witness.of.teachtext%40gmx.net > > > > This email sent to witness.of.teacht...@gmx.net > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/unmarked%40gmail.com > > This email sent to unmar...@gmail.com > -- Mark Munz unmarked software http://www.unmarked.com/ _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
