search

nate-parrott / Flashlight

The missing Spotlight plugin system
http://flashlight.nateparrott.com
Other
5.39k stars 411 forks source link

Multiple Language support #42

Open zhenyuchen opened 9 years ago

zhenyuchen commented 9 years ago

Thanks for the excellent work.

I'm not familiar with python but I wanna develop the plugin with Ruby or other language(Javascript...).

What do you think?

:+1:

henrikbjorn commented 9 years ago

:+1: would be great to use something like node or just ordinary shell scripts.

nate-parrott commented 9 years ago

It'd add a little overheard b/c you'd have to manually serialize all your plugin input/output in and out of JSON manually, but I'll certainly consider it. The other alternative is for someone to write a python plugin.py that just invokes a script in another language — then anyone who wants to write a plugin in that language could just drop that script into their plugin.

rcarmo commented 9 years ago

Yosemite supports JavaScript for automation, so that would be arguably as native as AppleScript. It might even be slightly more efficient than PyObjC, although I'm fine with using that because the runtime goes way beyond what JS can do out of the box.

xremix commented 9 years ago

@nate-parrott I saw your i18n prep commits. Are they already working or is this really just preparation?

nate-parrott commented 9 years ago

It's pretty much ready (for now)—I'm just planning to write up a doc about how to do i18n before soliciting translations. But feel free to get started now if you want! On Mon, Nov 24, 2014 at 3:17 PM xremix notifications@github.com wrote:

@nate-parrott https://github.com/nate-parrott I saw your i18n prep commits. Are they already working or is this really just preparation?

— Reply to this email directly or view it on GitHub https://github.com/nate-parrott/Flashlight/issues/42#issuecomment-64256853 .

xremix commented 9 years ago

Awesome!!! This makes my day. So all based on the computers localization? I'll start translating my most used plugins into German.

nate-parrott commented 9 years ago

Yeah — also, if you want to translate flashlight.app too, that'd be awesome.

I'm planning on writing a whole doc about this, but you'll want to have a separate examples.txt (examples_de.txt), and separate keys in info.json (description_de). For localizing plugin text, you can use the i18n module, which is in the 'useful modules' folder. On Mon, Nov 24, 2014 at 3:25 PM xremix notifications@github.com wrote:

Awesome!!! This makes my day. So all based on the computers localization? I'll start translating my most used plugins into German.

— Reply to this email directly or view it on GitHub https://github.com/nate-parrott/Flashlight/issues/42#issuecomment-64258187 .

hhas commented 9 years ago

@rcarmo - The OSA language component system was originally designed so that application developers could implement powerful, language-agnostic plugin systems. Unfortunately, OSA is also arcane, archaic, flawed, sandbox unfriendly (scripts run in-process, but sandboxing needs out of process), poorly documented, and generally problematic to languages not designed from the ground up to support it (i.e. anything other than AppleScript).

As to JavaScript for Automation, its OSA implementation is completely borked in 10.10, so you can pretty much forget doing anything non-trivial with it. I don't think it can handle anything other than run, open, idle, and quit events, and that is just a kludge. 10.11 may or may not see some of JXA's more egregious faults patched over, but it'll never be a competent alternative to AppleScript, plus there's all the pain of working with Apple events and OSA APIs in general. (I've been kicking up a stink on the AppleScript-users mailing list recently about both JXA's implementation and Apple's failure to provide any user support.)

Another way to provide JavaScript support is be to embed JavaScriptCore and have talk directly to the app's own Cocoa APIs, which was the original plan before the AppleScript team got involved. See the "Integrating JavaScript into Native Apps" session from WWDC13. The only missing functionality in JSCore I'd have really liked to see was direct support for running scripts out of process via XPC Services, but that's the sort of reusable feature third-party devs could probably build themselves. Also see third-party work like JSCocoa/ObjectiveJ/etc, and apps like Gus Mueller's Acorn which has both Python and JS plugin support.

rcarmo commented 9 years ago

Like I said, I'm fine with PyObjC. Even prefer it, actually, all things considered.