Re: [Skim-app-develop] path for pdfsync

[Christiaan H. <cmh...@gm...>]

On 28 Apr 2007, at 8:29 PM, Adam R. Maxwell wrote:

>
> On Apr 28, 2007, at 09:29, Christiaan Hofman wrote:
>
>> But what do you do with the bundle? What is relevant is the command
>> line tool, like 'mate'. Sure, in some cases this can be (also) found
>> in the Resources.
>
> I'm only suggesting this course for TextMate, BBEdit, and
> TextWrangler, where we know they bundle the tool.  Emacs is a special
> case, since it's really a separate operating system masquerading as an
> app :).
>
>> But in other cases it's somewhere else, e.g. for
>> Emacs. Also, the 'NameOfAppInPopUp' is not registered anywhere, only
>> the name (path) of the tool, which btw also might be some custom
>> script written by the user. The link to the app is only made in the
>> pref controller by matching the known preset values to the registered
>> pref values.
>
> The way I'm suggesting would require an additional preference
> (possibly; last time I looked at the prefs code in detail was when the
> app paths were hard-coded).
>
> - in the launch code, first check
> CustomScriptCommandForPDFSyncPrefKey; if non-nil, it's the full path
> to a command, and must be used as-is
> - if the result of the previous check was nil, use the preset app name
>    - the app name has to be stored in prefs
>    - for TextMate, BBEdit, and TextWrangler, find the app with LS and
> either use NSBundle or a relative path to get the tool
>    - for Emacs, find the app with LS and append the relative path to
> emacsclient
>    - relative path or tool name could be dictionary values, keyed by
> app name
>
> So in prefs, if a preset is used, CustomScriptCommandForPDFSyncPrefKey
> is removed from defaults, and the arguments pref are set based on the
> preset.  It's similar to your original approach, but uses LS to find
> the app instead of using /Applications.  Does that make any sense?

I did something like this.

Christiaan