Jump to content

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.


architect · designer · developer · geek
Affinity Designer 1.7.3 / Affinity Publisher 1.7.3
Windows 10 Pro, version 1909

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 ...

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

Share this post


Link to post
Share on other sites

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 ...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Hmm reminds me somehow to ...

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

osx:user$ osalang                                                                                                                                                 
AppleScript                                                                                                                                                                             
JavaScript                                                                                                                                                                              
Generic Scripting System             

 


☛ Affinity Designer 1.7.3 ◆ Affinity Photo 1.7.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.


☛ Affinity Designer 1.7.3 ◆ Affinity Photo 1.7.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.


☛ Affinity Designer 1.7.3 ◆ Affinity Photo 1.7.3 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.