Re: Providing a Service without activating an app
Re: Providing a Service without activating an app
- Subject: Re: Providing a Service without activating an app
- From: Mark Munz <email@hidden>
- Date: Fri, 05 Apr 2013 11:41:26 -0700
.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
<email@hidden>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 <email@hidden> wrote:
> > On Apr 2, 2013, at 11:03 AM, Andy Lee <email@hidden> 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 (email@hidden)
> >>
> >> 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:
> >>
> >> This email sent to email@hidden
> >
> > _______________________________________________
> >
> > Cocoa-dev mailing list (email@hidden)
> >
> > 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:
> >
> >
> > This email sent to email@hidden
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
--
Mark Munz
unmarked software
http://www.unmarked.com/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden