Testing OmniGraffle 7.3's built-in JavaScript automation

Sorry, I forgot that Discourse doesn’t let me link to app URLs. I’ve made those URLs plain text now (rather than nonfunctioning links), and you should be able to simply copy and paste them into the location field of your web browser.

1 Like

The need for automation is universal, and so it is immensely gratifying to see an iOS app respond to scripts the way macOS apps do! Kudos to the Omni Group for having the insight and determination to make this a reality.

2 Likes

The bugs that I listed yesterday for Edit > Copy As > JavaScript are now fixed. Please let us know if you encounter any others!

1 Like

Just updated the example plugin to include a new library: CanvasLib

// Call libraries like this:
aPlugin = PlugIn.find(“com.NyhthawkProductions.OmniGraffle”)
canvasLib = aPlugin.library(“CanvasLib”)

// get a list of the library’s handlers
canvasLib.handlers()

// get a bit of documentation about the library’s handlers
canvasLib.documentation()

2 Likes

Added examples of Alert() to online documentation: https://omni-automation.com/shared-alert.html

Sensational job Omni team! I am very excited with the introduction of scripting function in OmniGraffle with javascript (aka OmniJS). I have referred to the documentation and played with it a bit and I think I’ve got a handle on the basic direction you’re taking thus far:

1.) The ability to manually launch the OmniJS terminal window and enter code on-the-fly.
2.) The ability to develop functions as libraries in downloadable/installable plugins.

Suggestions for some amazing enhancements:

1.) When I had the beta installed I think the menu for the terminal at the top was “scripts” or scripting". Just name it OmniJS -it would look sweeter.
2.) You have Stenciltown for your community of stencils. This might be a good time to register a domain to start a community surrounding the incredible extensibility of OmniJS. Hmmm, looks like somebody beat me to the punch to acquire omnijs.com. Darn it.
3) It would be extraordinary for those of us in the print industry to have a way to do a glorified mail-merge via javascript into OmniGraffle. Could you please have your team bake in textReplace into omniJS? I know you can identify textboxes in OmniGraffle…let me replace that text with a self-developed data source (aka plaintext CSV or some other delimited format) so I can script a merge and export the resulting document in the various file types you support.
4) Closer to launch, please add auto-completion to the OmniJS terminal window.
5) The ability to save the script entered into the terminal.
6) Some basic debugging would be nice. Basically anything a traditional JS developer would need I’d appreciate in OmniJS.

i found this implementation extremely interesting using Swift. But I’ll keep on eye on both the OmniJS and Swift fronts to accomplish what I want.

Thanks for the consideration.

2 Likes

The ability to embed OmniJS in links and URLs is another important feature as well. Web-based documentation and data sharing become really useful. More will be revealed.-- SAL
OMNI-AUTOMATION.COM

2 Likes

New documentation on the Alert() object. https://omni-automation.com/shared-alert.html

Cheers,

Sal

1 Like

And if you have any questions, please don’t hesitate to ask!

Will JXA (JavaScript for Automation) scripts developed in Script Editor “just work” in OmniJS too?

SG

We’d love to have things be familiar to people who are already using JXA to script our apps, but there are certainly differences. The scripting model we’re building is designed to work on iOS as well as Mac, whereas JXA is designed around Mac-only Apple Events.

(The good news is that OmniJS scripts are not only cross-platform, they’re also much much faster than Apple-Event-based scripts.)

1 Like

Thanks. I was guessing there might have to be differences. Can you give a simple (specific if possible) example of a difference we might commonly encounter when doing relatively straightforward scripting of the app (in my case OmniOutliner) itself?

I don’t want to spend too much time getting down in the weeds now with JXA if the differences might turn out to be substantial. I do like the possibilities of cross-platform!

SG

Maybe a tiny bit off topic - though I don’t think so. :-)

Will the x-callback-url support on iOS evolve to match the capabilities of OmniJS? Personally I’m most interested in OmniFocus but using OmniGraffle also I’d love this to be the case there. I can think of plenty of diagram generation scenarios in my (shockingly misnamed) :-) “day job”.

@kcase

Reposing my question above on differences between JXA and OmniJS:

Would appreciate any light that can be shed on this.

Thanks,

SG

The most obvious difference between JXA and OmniJS is the “Every…Whose” clause support in Apple Events is not in core JavaScript. The result is that scripts must have iteration routines using for… and forEach… to locate the desired objects.

Also, in most Apple Events implementations, you can address an object by index or name. The name addressor is not supported in core JavaScript.

But these differences shouldn’t hinder you in creating very useful and powerful OmniJS scripts. Myself, I use script templates to quickly insert the routines I use often :-) – SAL

Not quite the same thing, but check out this page http://omni-automation.com/shared/url-app-to-app.html about App-to-App communication (under construction). OmniJS scripts can execute scripts targeting other Omni apps and then process the results of the calling script.

1 Like

@Sal

Thanks. I’ve learned enough JXA to think it shouldn’t be too hard to get along pretty well without using what I’ve been calling ‘whose’ filter and (I think) without addressing by name.

Interesting about url schemes. Won’t be limited to targeting just Omni apps? Or will it?

It’s great to hear more integrated automation is coming to iOS!

SG

Interesting about url schemes. Won’t be limited to targeting just Omni apps? Or will it?
It’s great to hear more integrated automation is coming to iOS!

When it comes to productivity automation, especially on iOS, the Omni Group is leading the way. So for now, the URL schemes are integrated in Omni applications on both macOS and iOS. Best of all – it’s fun! – SAL

First posted example of App-to-App scripting with OmniJS: http://omni-automation.com/shared/url-app-to-app.html

w00t!

2 Likes

Very nice example of the call and response pattern – thanks

A couple of questions about URLs and plugins:

  • In the URL approach, is there a known limit to the length of the url-encoded script ?
  • If there is a length constraint on the URL channel, can larger scripts return values from an application through the plugin architecture ?

Glad you found the example useful :-)

As far as the length of a URL, I’m not aware of an existing limit on the number of characters in a URL. The AppleScript URLs support built-into the Script Editor in macOS, accepts some very long encoded script URLs, like some of those on https://iworkautomation.com. However, if your script is that long, you may want to rethink the strategy and break it down into smaller pieces.

With regard to calling into plugins: external scripts can call functions within an installed PlugIn’s libraries (Documented on this page: http://omni-automation.com/libraries). Using plugin libraries can dramatically reduce the size and complexity of your scripts!

The OMNI-AUTOMATION site documents how to create libraries and how to call them from plugins and external scripts.

1 Like