Scripting

[mcglk]

4 hours ago, fde101 said:

I've never seen ANY evidence supporting this common theory.

Sal Sogohian (one of AppleScript's leading evangelists) had his position at Apple eliminated a few years ago, and as Apple has been generally withdrawing its support for AppleScript, I'd say the writing has been on the wall for a few years. JXA is a viable alternative, but Apple hasn't really been clear about what its future is. There doesn't seem to be much enthusiasm for OSA at Apple anymore. It's a real shame, because OSA was a brilliant accomplishment, and it made tying together various applications into a relatively easy, fun exercise.

Apple's apparent lack of enthusiasm for AppleScript these days has been leaving a number of developers uncertain, and that in turn is reducing their enthusiasm for providing scripting support as well. Nobody wants to invest in a lot of effort for a product which could just evaporate—and that, in turn, might well prompt Apple to say, "hey, people are supporting this less, let's go ahead and drop it."

Which is stupid, of course, but I can't pretend to comprehend the corporate politics at Apple. I never would have thought of gluing the RAM and the disk into hardware just to keep users from upgrading, for example, and alienating their customer base seems to be what Apple is into right now.

Now, personally, I think Lua is a fine language for this purpose—as you say, it's designed for this sort of thing. I'm not crazy about EJCaMvAaScript. I certainly wouldn't mind being able to drop 

import affinity

into a Python script, either. But I would like some solution at some point.

Of course, this isn't the most urgent wish I have about the Affinity suite—but it's up there, certainly.

[RM f/g]

Wouldn't it be nice if the good folks at Serif would lift a tip of the veil so we know what to expect?

Can we, indesign users, still use applescript/javascript in the future with AP or had we better started learning Python or whatever other option?

[Lmpessoa]

On 8/16/2019 at 11:40 AM, Raphael Santos said:

One more vote for python as the future scripting language for the affinity suite.

Sorry but I would vote you down. I'm much more fond of Javascript/Typescript than Python.

It will be much hard for Serif to choose one language that will please everyone so I wouldn't be bothered by whichever language they choose (even if they were to introduce one of their own). I think the choice in the end will be which one will be easier to incorporate into the apps.

[fdelaneau]

Javascript seems the obvious choice but support for AppleScript (and the equivalent on Windows) seems a must since the print industry relies a lot on cross applications automations.

Until then, it will only suit the needs of creative graphic designers.

[fde101]

JavaScript (more correctly called ECMAScript) is something I'm kind of learning out of necessity right now for a project I am working on which will run in a web browser.

It is unfortunate that yet another horrible language has become so entrenched in supposedly-modern applications that are designed to run in a web browser that it will be difficult if not impossible to get any kind of agreement on replacing it with something more legitimate.

One of the issues is that in spite of attempts over the years to "modernize" the language, it still has too strong a need to maintain compatibility with legacy code that was written in earlier, more primitive versions of the language that did things differently, so you wind up with some features using one approach to doing something, and others using a completely different approach to do almost exactly the same thing, but neither approach works in both places.  It is a language that has been haphazardly layered on top of itself by competing groups trying to pull it in different directions and the result is just a mess.

Couple that with the prevalent "C"-like syntax and it is not even remotely a fun language to work with, though admittedly there are a few interesting aspects to its design that are at least partially redeeming compared to other languages in the general "C-like" language family.  First-class functions and closures are a definite plus, and prototype-based inheritance makes it interesting from a theoretical standpoint anyway.

Never would I recommend further propagating it however.  We are kind of stuck with it for code that runs in a web browser, and I for one would prefer that it stay locked up in that cage until such time as we can replace it with something better there too.

 

For the record, I'm not the biggest fan of AppleScript as a language either, but it, like JavaScript, is the only real option in its domain right now for some use cases.

[angelhdz12]

Yup. After reading all comments, TypeScript and Javascript are the most obvious solutions. TypeScript for the ones who love static typing, and Javascript for the ones who want to type less. But also, Serif should consider choosing TypeScript as default, but allowing BINDINGS to other languages so everyone is happy.

[tmmls]

Any progress/updates on this issue? I'm really fed up with the arrogant bastards from Adobe. We really need an alternative to the scripting features of Indesign, as well as the Indesign Server solution...  My list with Adobe frustrations  is getting way to long... Life is to short for that crap ...

[MikeW]

42 minutes ago, tmmls said:

... We really need an alternative to the scripting features of Indesign ...

Serif will likely not definitively respond until the first beta with such a new feature. 

42 minutes ago, tmmls said:

... as well as the Indesign Server solution ...

Ya never know, but I don't think this will ever happen. If it does, it won't be for many years after there is scripting. 

[fde101]

23 hours ago, tmmls said:

We really need an alternative to the scripting features of Indesign, as well as the Indesign Server solution...

https://www.simplicity.be/article/indesign-server-alternative-open-source/

http://www.viva.de/en/solutions/developer-and-it-service-companies

http://www.quark.com/Solutions/Content-Automation/Content-Automation-Software.aspx

[hi-ko]

It's a very long thread and most aspects have been already said but my 2 cents to add:

I bought Affinity Publisher for occassionall internal usage. To be used as a real live publishing App producing a lot of pages it definitly lacks an API for automation and for replacing/updating parts of the content. Publishing should't be seen as a mouse / human task only. Publishing is in many cases just one channel (of many) for content.

The discussion which language would fit best (JS, TS, Python, AppleScript) has not the same priority as the scope and coverage of that API. AppleScript should be seen as a nice to have since it is locked on MacOS but it shouln't be too much effort to provide additional bindings like JS, Pyhton, AppleScript once there is a robust and more or less complete C++ API. So it is not only a question of Scripting Language choice but also a question of API/SDK and PlugIn-Support.

Since there is no concept for SDK/Integration available by today I'm wondering if there will be (object oriented) Scripting-Support available at all outside the marketing discussion ...

[fde101]

3 hours ago, hi-ko said:

AppleScript should be seen as a nice to have

Some users are integrating multiple applications.  A single-application scripting solution, no matter what the language, will not provide that level of integration.  The only way to accomplish that meaningfully is with an external scripting solution, and for the Mac, that will generally be AppleScript.  The ones on M$ OSes will similarly not carry across to the Mac.

This is one area where it is not feasible to have a cross-platform solution and still cover all of the bases.

Thus I think at least two scripting languages will be needed to cover all needs: one internal to the application (and thus cross-platform) and support for the common OS scripting language on each platform, for integration of multiple applications together within a workflow.  For those users, AppleScript support is critical, not just nice-to-have, since any other option will not provide what is needed.

[TonyB]

17 minutes ago, fde101 said:

Some users are integrating multiple applications.  A single-application scripting solution, no matter what the language, will not provide that level of integration.  The only way to accomplish that meaningfully is with an external scripting solution, and for the Mac, that will generally be AppleScript.  The ones on M$ OSes will similarly not carry across to the Mac.

This is one area where it is not feasible to have a cross-platform solution and still cover all of the bases.

Thus I think at least two scripting languages will be needed to cover all needs: one internal to the application (and thus cross-platform) and support for the common OS scripting language on each platform, for integration of multiple applications together within a workflow.  For those users, AppleScript support is critical, not just nice-to-have, since any other option will not provide what is needed.

How about Affinity supporting AppleScript but only for for coarse grained functions with execute JavaScript snippet as one of those functions?

[fde101]

13 minutes ago, TonyB said:

How about Affinity supporting AppleScript but only for for coarse grained functions with execute JavaScript snippet as one of those functions?

Yes, I was actually just thinking about that, and that could work as long as there is a suitable mechanism for arbitrary data in/out (pass parameters to the in-application script and obtain a return value, or provide for file I/O or similar) and the implementation allows for syncing the execution of the script inside the application with the one running outside the application (ex. does not "return" to the AppleScript until the application's script completes).  Definitely can't say I'm a fan of JavaScript (should really be ECMAScript if using that) but whatever that language is, from the standpoint of making it possible to interact with other applications in a workflow, it should be do-able that way.

Similarly with VBScript or whatever the Windows equivalent is.

[v_kyr]

Hmm reminds me somehow to ...

• osascript -- execute OSA scripts (AppleScript, JavaScript, etc.)

Quote

osx:user$ osalang                                                                                                                                                 
AppleScript                                                                                                                                                                             
JavaScript                                                                                                                                                                              
Generic Scripting System             

 

[fde101]

17 minutes ago, v_kyr said:

Hmm reminds me somehow to ...

• osascript -- execute OSA scripts (AppleScript, JavaScript, etc.)

Yes, technically the scripting architecture in MacOS is not limited to AppleScript and can support the use of other scripting languages at the OS level as long as a proper bridge is created for them.  AppleScript is the most cleanly integrated one, but there are a few others around.

I believe the same is true for WSH, where VBScript and JScript are the "bundled" options from what I am seeing.

[v_kyr]

23 minutes ago, fde101 said:

I believe the same is true for WSH, where VBScript and JScript are the "bundled" options from what I am seeing.

Yes WSH is a similar MS Win approach in contrast to OSA, though more used for plain OS based automation tasks (batch replacements) and so not by third party (non-MS) applications for their app automation.

However, a scripting support for whatever scripting language has to be platform/OS independent here, thus it shouldn't be firmly OS coupled, in order to offer the highest compatibility between system architectures. Aka the write once run everywhere principle.

[fde101]

38 minutes ago, v_kyr said:

a scripting support for whatever scripting language has to be platform/OS independent here

I wonder how many times I might need to repeat this before it sinks in...

 

Scripting languages which are built-in to the application cannot readily interact directly with other applications.

Particularly in a sandboxed security environment such as MacOS apps from the app store.

 

As a result, a 100% cross-platform implementation cannot support workflows that interconnect multiple applications - you must use a mechanism provided by the OS to support that, and those mechanisms by nature tend to be OS-specific.

Refer to the post by @TonyB above for one possible option for dealing with this.  It would provide an in-app scripting language which would be cross-platform for those scripts which do not require interaction with other apps, but allow the OS-provided scripting architecture to hook into it just enough to make it possible to interconnect multiple applications for those who have the need to do so.

 

46 minutes ago, v_kyr said:

the write once run everywhere principle

Sounds great in theory, but doesn't always pan out in practice.  HTML, ECMAScript, CSS are supposed to be open standards to allow for consistent interpretation between browsers, but look at how many sites work well on one browser and not on another...  and different operating systems and environments are by nature different.  In many cases, something that is intended to work well on all of them is doomed to work poorly on all of them unless it is separately optimized for each one.  Same thing with SQL code transported between database engines, etc.

[v_kyr]

29 minutes ago, fde101 said:

Scripting languages which are built-in to the application cannot readily interact directly with other applications.

Particularly in a sandboxed security environment such as MacOS apps from the app store.

As a result, a 100% cross-platform implementation cannot support workflows that interconnect multiple applications - you must use a mechanism provided by the OS to support that, and those mechanisms by nature tend to be OS-specific. ...

What has that to do with the apps own internal offered portable scripting support here?  As far as an Affinity app would offer some well defined console-mode invocation processing, it can be used from any other OS related service, no matter if invoked/used by other OS related scripting capabilities, a dedicated scripting languages, or custom programs. - What you are instead suggesting is another more OS related and dependent access layer here.

 

59 minutes ago, fde101 said:

Sounds great in theory, but doesn't always pan out in practice.  HTML, ECMAScript, CSS are supposed to be open standards to allow for consistent interpretation between browsers, but look at how many sites work well on one browser and not on another...  and different operating systems and environments are by nature different.  In many cases, something that is intended to work well on all of them is doomed to work poorly on all of them unless it is separately optimized for each one.  Same thing with SQL code transported between database engines, etc.

Competing implementations by webbrowser- and database engines aren't good examples for this, since they all cooked first of all their own favorite soup, standardization or not. - Better look on some other portable apps from the graphics domain, which already offer the one or other scripting capability here.

[fiëé]

About what are we talking here? Automating single tasks from within the application? Remote controlling the application(s), possibly headless (i.e. in server mode)?

The first doesn’t necessarily include the second, and it might be a political/commercial decision to not allow remote access. (Like i.e. Adobe made it hard to remote control their applications because they wanted to sell their server products. Wrote a Python remote control for Distiller on Windows over COM once; I guess it’s illegal.)

In most “controllable” GUI programs that I know, automation is quite limited or stuck to a limited range, because scripting was never an important development goal.

I doubt most of you JavaScript enthusiasts ever worked with JavaScript without a DOM and a basic library of functions, like in Acrobat. It’s a developer’s nightmare. So “JavaScript” doesn’t really mean anything, it depends a lot on the environment – similar to working with big libraries like .NET or Qt, you need more time (and documentation!) for learning the DOM and the library than for the language. Good documentation is key, and I don’t think we’re paying Serif enough to provide that – for only a few users, mind you.

AppleScript has (had?) these nice introspection tools, but if nobody put an effort in the application library’s metadata, you can just guess which parts are usable at all and how. I left AppleScript behind decades ago mostly because it couldn’t do what I needed. Or I was too stupid to convert C data types in AppleScript...

I did projects in BASIC, Turbo Pascal, Perl, AppleScript, PHP, VB.NET, Delphi, Shell, and Python, with parts in JavaScript, PostScript, XSL, Lua and several markups. I prefer Python, and Lua is good as an integrated scripting language. I just don’t trust PHP or any JavaScript variety from outdated experience (Unicode!?). (If I’d be intelligent enough maybe I’d prefer Lisp or Haskell...)

Let’s be serious: In applications like the Affinity series, only a minority will use scripting at all. We’re already getting a lot for our money, and if Serif will offer any scripting, it’s nice. JavaScript is the most probable choice, and we can just hope to get an usable DOM and some documentation (that doesn’t contradict the implementation, like we know from Adobe and others).

If I need something automatical, I’ll probably continue to use LuaTeX.

[Graeme W]

I can't speak for others but I would definitely want scripting automation within the Application. I am looking at what InDesign offers in this regard - Acrobat is woeful in comparison. 

My main use case is a custom import/export tool which can handle several versions of a custom XML document format we use. It does do a few other things with some custom GUIs and stuff that InDesign offers (even if it's implemented them poorly). It does have a sub-feature that calls out to Illustrator but that is only because scripting in Acrobat and Illustrator directly are so poor in comparison. 

I also have a few utility scripts doing a few things, have previously written a companion app for an asset management tool which processed and submitted data. Plus there is an awesome script I found a while ago called Calendar Wizard which can automatically setup pages with the dated squares for every month with a whole bunch of configuration options. 

So, without an alternative with scripting, I have to keep my old mac book with CS4 going for a while yet.

[ChrisVB]

+1 for scripting support.

Not only within the application, but especially outside the application.

I'm a bit flustered by the discussion on the programming language. I've done some automation of Microsoft Office. Yes, inside Office you can use VBA, but outside Office you can use almost any language.
You can use PowerShell, VBScripting, VB, C#, Python.  I don't know what the technical terms are to describe that sort of implementation, but that is what I want!

My main use case would be to fill/expand a Publisher template with my specific data.

If a single language would need to be chosen, I would have a personal preference of Python over JavaScript.

[HarryK]

+3 for scripting support (also)

- I totally agree with other members: publishing is not only human & mouse but also often system driven. 

- I totally agree that the scope of the API is more important than the scripting language (best for modern / most used language)

If an API is available I can happily say goodbye to the A**** suite. Can't wait for this to happen

Can someone from Affinity disclose if there is ANY change of an API coming to life?

[garrettm30]

Actually, I have been wondering about this since a recent post about an issue in the Publisher 1.8 beta that I was having and that Serif staff was having trouble replicating. In the course of that discussion, a Serif rep said (emphasis mine):

On 2/25/2020 at 8:07 AM, Jon P said:

Let me know if it happens again. I could never reproduce it to begin with (even after writing a script to change the export preset a lot of times and checking the size was always the same)

I hated to bring up a tangent in that thread, but I was wondering how it was he wrote that script. Is there already available some basic scripting in 1.8 that I didn't know about?

[walt.farrell]

2 minutes ago, garrettm30 said:

I hated to bring up a tangent in that thread, but I was wondering how it was he wrote that script. Is there already available some basic scripting in 1.8 that I didn't know about?

I'm sure he was referring to some kind of special testing tool that they can create scripts for, which simulates users clicking on the screen. Thats really the only way they'd be able to run regression testing.

[Jon P]

Walt is correct