Jump to content
You must now use your email address to sign in [click for more info] ×

Recommended Posts

Not to mention that if we are talking about bringing scripting capabilities to the largest amount of users, JavaScript is (and has been) the most widely used programming language in the world. And as mentioned (or implied) by @CM0 and @zixdesign, if the engine were to support wasm, you could then run virtually anything there, including a python interpreter.

But as @kimtorch said, to be honest, at the moment I'd be happy if I were able to code my own extension code even in C++.

Link to comment
Share on other sites

Good to hear scripting is on the radar. As for which language: from the perspective of a designer who doesn't mind to tinker with code, I'd prefer Python or Lua, just because of the simplicity of the syntax. Also both of them have a good track record in DCC software, like Maya, Houdini, Blender or Fusion. But really, any scripting is better than none, so I'd be happy with whatever choice the devs make.

Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...
2 hours ago, 101 said:

hopefully we old users will be able to upgrade to a version that supports js development for free

If you mean a "free" as in beer upgrade from v1, don't hold your breath. You will choke.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

22 minutes ago, loukash said:

If you mean a "free" as in beer upgrade from v1, don't hold your breath. You will choke.

No, as long as v2 adds the function of opening JavaScript api, not major version update, v1 and v2 I purchased separately.

affinity is of little use to me at the moment. I just bought affinity because I didn't want to use something as heavy as adobe

Link to comment
Share on other sites

25 minutes ago, 101 said:

v1 and v2 I purchased separately

OK. I meant because you're posting in an archived V1 feedback thread which is at this point rather pointless. ;) 

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

  • 4 weeks later...
On 9/11/2018 at 6:12 PM, kimtorch said:

As much as my preference is Applescript, I think the most practical would be javascript due to its cross platform nature. I believe either of these would be openly accepted by current InDesign scripters who already script in these languages.

There is a lot of misunderstanding here.   In order to allow *any* language to access the object model (properties, functions, data, etc...) of the affinity apps, they have to define an AppleScript (SDEF) dictionary for the app and methods.   The truth is that Serif has already made the object model for all the apps, but they have not typed the descriptions into the SDEF portion that winds up forming the scripting dictionary for the macOS environment.

I'm especially tickled at the people above that think that javascript will make it cross-platform -- totally irrelevant.  On macOS, any number of scripting language could be used so long as that language has a scripting bridge, and as long as the app has exposed its object model to apple events through defining the AppleScript dictionary..

What this means practically, is that once Affinity fills in the AppleScript dictionary, then not only AppleScript, but all these other languages, such as JXA, swift, obj-C, browser javascript, python, etc, can access the app and data model therein.

If I understand correctly, this is sort of like what MS is trying to do with powershell.  But, I have not used powershell and really don't know how it works on Windows.  What I do know is that the Adobe apps have AppleScript dictionaries, as do Pixelmator PRO and Acorn, so whenever I want to batch process images or whatever, I can use applescript, JXA, or any other language to have those apps do work on the images, but Affinity cannot, sadly.  

So if I want to automate checking minimum line widths in a large doc in order to be sure I've met printer specs, I can run an AppleScript, or javascript, or whatever -- in any of those apps with AppleScript dictionaries -- which excludes affinity at this point.

Link to comment
Share on other sites

47 minutes ago, jbmanos said:

So if I want to automate checking minimum line widths in a large doc in order to be sure I've met printer specs, I can run an AppleScript, or javascript, or whatever -- in any of those apps with AppleScript dictionaries -- which excludes affinity at this point.

But that would only work on macOS. Serif needs to implement something cross-platform for the Affinity applications. It can't be something tied to an Apple-specific implementation method.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

33 minutes ago, walt.farrell said:

But that would only work on macOS. Serif needs to implement something cross-platform for the Affinity applications. It can't be something tied to an Apple-specific implementation method.

That's funny.  I think you mean WINDOWS needs to have an exposed object model.   AppleScript dictionaries are a basic feature of mac apps.  It's a shame that the Affinity apps are half-baked on macOS because this basic feature has been omitted.  It prevents the apps from being used in automation on macOS.  Adobe does it and they are cross-platform.  Same with any other number of cross-platform apps, including Microsoft Office.  The Adobe dictionaries are fully featured, and complete -- in may ways, even better than Apple does with its own apps, in fact.   So it's difficult to see how you arrive at this conclusion, unless perhaps you misunderstand what is being asked for here.

Link to comment
Share on other sites

21 minutes ago, jbmanos said:

I think you mean WINDOWS needs to have an exposed object model.  

No. I mean that something that is Apple-specific (AppleScript dictionaries) is not appropriate. Whatever they provide needs to work on both Windows and macOS, allowing the same scripts to work on both OSes.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

21 minutes ago, walt.farrell said:

No. I mean that something that is Apple-specific (AppleScript dictionaries) is not appropriate. Whatever they provide needs to work on both Windows and macOS, allowing the same scripts to work on both OSes.

Please explain how Adobe and Microsoft do it.  I've given the explanation but you seem to have a concept of this macOS functionality that is not accurate.  What you are saying means that you don't think macOS apps should be fully native because your operating system lacks similar capacity.  Again, Microsoft and Adobe do it -- Adobe does it very well, in fact.  

Link to comment
Share on other sites

I have no idea if Adobe or Microsoft provides something that allows the same scripts to work on both platforms. But if they do, I doubt they do it with AppleScript.

I am saying that that capability is important to Affinity users, and any suggested implementation that only works on macOS, or that can work on both macOS and Windows but requires a different scripting language for the different platform, is not acceptable in my opinion.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

2 minutes ago, walt.farrell said:

I have no idea if Adobe or Microsoft provides something that allows the same scripts to work on both platforms. But if they do, I doubt they do it with AppleScript.

I am saying that that capability is important to Affinity users, and any suggested implementation that only works on macOS, or that can work on both macOS and Windows but requires a different scripting language for the different platform, is not acceptable in my opinion.

This is funny -- did you mean to intentionally shift the focus here?

Adobe and Microsoft finish their macOS apps and have fully functional AppleScript dictionaries.  Affinity so far has not and consequently has half-baked macOS apps.  I think you just don't understand what this is.

Link to comment
Share on other sites

6 minutes ago, jbmanos said:

This is funny -- did you mean to intentionally shift the focus here?

Adobe and Microsoft finish their macOS apps and have fully functional AppleScript dictionaries.  Affinity so far has not and consequently has half-baked macOS apps.  I think you just don't understand what this is.

I did not shift the focus.

I have been saying, and continue to say, that it is not good to focus on macOS so much. And it is not relevant to Affinity users (in my opinion) what Adobe and Microsoft have done for their applications on macOS.

Yes, we need scripting. But it should be scripting that works identically on both macOS and on Windows, as the applications are cross-platform and all functions are supposed to work the same on both. The last statement I saw from Serif (albeit years ago) that had any details indicated scripting would be done with Javascript. While I might prefer Python, Javascript is (to me) more acceptable than AppleScript. But we have no way of knowing if that is still their plan.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

17 minutes ago, walt.farrell said:

While I might prefer Python, Javascript is (to me) more acceptable than AppleScript.

In fact under MacOS automation/scripting can be done in either flavor here, AppleScript & JavaScript, where the later has even more capabilities in terms of available functions and the like. - Personally I would too favor Python here (or at least Lua) and then please also in an additional interactive Interpreter usable mode, which of course then has to allow to import also other third party lang modules. - What I definitely don't want to see here is, crippled stuff like the Affinity Photo Macro implementation.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

2 hours ago, jbmanos said:

Please explain how Adobe and Microsoft do it.  I've given the explanation but you seem to have a concept of this macOS functionality that is not accurate.  What you are saying means that you don't think macOS apps should be fully native because your operating system lacks similar capacity.  Again, Microsoft and Adobe do it -- Adobe does it very well, in fact.  

Well tbf, billions of dollars and virtually unlimited resources probably helps them develop literally anything.

A company of that size can pick and choose however they want their APIs designed and people will have to use basically whatever that is available if it's dominant in the market. The fact their choice would be someone's preference doesn't negate the fact there are plenty of choices for Serif to choose from and for whatever reason, they picked Javascript.

So the question of how something is done is probably not as important as asking why. Why choose Javascript over XYZ<insert language>, etc.

Microsoft Windows 10 Home (Build 19045)
AMD Ryzen 7 5800X @ 3.8Ghz (-30 all core +200mhz PBO); Mobo: Asus X470 Prime Pro
32GB DDR4 (3600Mhz); EVGA NVIDIA GeForce GTX 3080 X3C Ultra 12GB
Monitor 1 4K @ 125% due to a bug
Monitor 2 4K @ 150%
Monitor 3 (as needed) 1080p @ 100%

WACOM Intuos4 Large; X-rite i1Display Pro; NIKON D5600 DSLR

Link to comment
Share on other sites

21 hours ago, debraspicher said:

Well tbf, billions of dollars and virtually unlimited resources probably helps them develop literally anything.

A company of that size can pick and choose however they want their APIs designed and people will have to use basically whatever that is available if it's dominant in the market. The fact their choice would be someone's preference doesn't negate the fact there are plenty of choices for Serif to choose from and for whatever reason, they picked Javascript.

So the question of how something is done is probably not as important as asking why. Why choose Javascript over XYZ<insert language>, etc.

That’s missing the point also. 
 

When I started the reply here, I was trying to explain that applescript is not the same thing as what people are asking for when saying “scripting”

 

I understand what you guys want is a way to - only as a means to give example here - program macros WITHIN the program.   Let’s call that scripting.  Adobe uses JavaScript for this, MS uses Visual basic, etc. 

 

As @walt.farrellsaid above -  this sense of scripting IS cross-platform.  I agree with what he said in this context and for that use of scripting (ie within the program)

 

What I poorly explained above is that AppleScript dictionaries are a fundamental of macOS apps and Affinity has not provided even a basic dictionary for any of its apps.  Applescript is not scripting as the term is being used here.
 

in other words, let’s say tomorrow that Affinity adds scripting and it is everything @walt.farrell wants.   I’d be happy because we all can share programmatic macros and what not and those would likely not be platform dependent.   But there would still be a deficiency on the macOS apps - my complaint that the apps are half-baked would remain.    
 

we really are talking about two different things here.  

Link to comment
Share on other sites

Just for the sake of completeness, let me add that a similar degree of the external automation scripting functionality that you can achieve in Macos with Applescript and in Windows with COM,  could also be achieved with a generalistic internal javascript or python parser (to be able to run scripts from within the app), if Serif added the ability to launch the program with a command line argument to directly run a script (something like -s <script_name> <args>), which should be fairly easy to implement. Ideally also with a "background" parameter -b like blender has in order to run in headless mode. That should keep us going until they decided to implement platform specific solutions (although, since for me the above would be enough, I'd argue that it wouldn't be necessary, but maybe some people have use cases for that).

In any case the general parser should be the first step since it will allow everyone, regardless of the platform, to run scripts.

Link to comment
Share on other sites

So forgiving any nuance I am not familiar with, is AppleScript (re: support) basically a way to connect the app to OS events/handlers? In other words, instead of thinking about how our scripts work within the context of Affinity, how our scripts connect Affinity to the OS (and vice-versa)?

That might be a different support request and I'm curious what staff would have to say about possibly supporting it in the future.

Microsoft Windows 10 Home (Build 19045)
AMD Ryzen 7 5800X @ 3.8Ghz (-30 all core +200mhz PBO); Mobo: Asus X470 Prime Pro
32GB DDR4 (3600Mhz); EVGA NVIDIA GeForce GTX 3080 X3C Ultra 12GB
Monitor 1 4K @ 125% due to a bug
Monitor 2 4K @ 150%
Monitor 3 (as needed) 1080p @ 100%

WACOM Intuos4 Large; X-rite i1Display Pro; NIKON D5600 DSLR

Link to comment
Share on other sites

I agree with @jbmanos when he says we're talking about two different things.

1. is creating scripts within the Affinity applications themselves to extend or enhance the existing functionality of the apps. These 'scripts' are also sometimes referred to as macros, extensions, tools, plug-ins, etc. I think this is what most people are referring to when they talk about scripting with regards to the Affinity applications, and are similar to those scripts, extensions, plug-ins found in other applications such as Adobe Illustrator, After Effects, Blender, etc.

2. is automation of the Affinity apps from the host environment, using tools such as AppleScript (macOS, OSA Open Scripting Architecture) and Shortcuts (iOS/iPadOS and macOS). This type of scripting is often involved in creating complex automation workflows between applications, such as those used in the printing and gaming industries. This type of scripting requires app developers to provide a 'Dictionary' (API) with commands accessible via OSA, which is what @jbmanos is asking for. It's not in place of in-app scripting, but an addition that allows the Affinity applications to be utilized within much larger workflows.

Also, the newer 'Shortcuts' feature that is available on iOS, iPadOS, and macOS is a bit of a reimagining of how these workflows could not only be created, but utilized. AppleScript/OSA scripts are also supported within Shortcuts. 

It's also worth mentioning that many apps support both scripting extensions within their own application, as well as providing automation features that can be utilized to chain together much larger automation workflows between applications (including those from other companies). Adobe Illustrator, InDesign, etc. all provide an OSA automation 'dictionary' in add to their own internal scripting capabilities, which has made them indispensable to many industry workflows. 

Link to comment
Share on other sites

Yes there are two things going on here with scripting: Scripting within the app (e.g. Macros) and Automation.

IMHO (!) supporting AppleScript (or the OSA architecture) is somewhat of hitting a dead horse. It's still used in macOS but not available on even iOS/iPadOS... and very likely never will be, since Apple seems to put their energy into "Shortcuts". OSA isn't the nicest of APIs to support. Don't get me wrong - there is nothing announced yet that would call out for an end of OSA, but from a developers perspective the signs are there.

@jbmanos description about object models is a bit misleading... (I might have misunderstood him though) this is NOT something that is "just there" in macOS - it's something you need to actively implement and the application needs to be written to support this. The biggest downside is that this will only work for macOS and not even for iPadOS (not even think about Windows) so it boils down to an economic question... It works in Adobe and MS apps because they are able to throw a hundred developers on their macOS application ports who will implement this even if it will do nothing for non macOS users.

In a way Scripting _and_ Automation need an application to be opened up internally in ways to "hook" into its functions. This is the main work that needs to be done. This is something that very likely is not very dependent on the OS used. If this step is done, they can provide e.g. a scripting API using JavaScript by embedding some runtime. An alternative would be to not embed some runtime, but implement a communication/bridging layer... something similar to a "web api" and then using _external_ runtimes to communicate with the App using that communication layer. But if it is done that way, calling a "macro" in the application would then actually start an external process which then communicates back to control the app. All of this are implementation details though.

I would see OSA or Shortcuts support as an (important!) "add on" feature over the general scripting/automation support. IMHO shortcuts support would be enough... just ignoring OSA for better use of developer resources. Shortcuts support would enable to use Affinity features to be integrated in workflows written using the macOS and iPadOS shortcuts app. Which definitely would be a nice thing to have.

The equivalent in Windows could be something like a COM/OLE interface... a horrible API (even worse than OSA).

 

Link to comment
Share on other sites

Yes, I'd agree economics have to come into the equation eventually. Developing a robust scripting engine for in-app behavior is a no brainer. It being JS, it has a large enough user base across all plats and thus more preexisting code exists that could be ported in with comparative ease. That will draw value to the apps faster than OS-level implementations. At least at the moment. I still feel there's still some functionality missing that won't court those "high brow" people over to a new platform no matter how big the red carpet they roll out. As this post highlights...

So while I don't necessarily poo poo them taking strides to introduce OS-level functionality into the apps to allow them to communicate with external scripts, I feel (as a user) if I were to pick where they would put scarce time and resources, it would be into features that guarantee more usage more broadly, as well dealing with polish & immediate development woes so that they can add in solid features that will eventually court the crowds that need more large scheme solutions... basically their eyes can't be bigger than their plate.

Microsoft Windows 10 Home (Build 19045)
AMD Ryzen 7 5800X @ 3.8Ghz (-30 all core +200mhz PBO); Mobo: Asus X470 Prime Pro
32GB DDR4 (3600Mhz); EVGA NVIDIA GeForce GTX 3080 X3C Ultra 12GB
Monitor 1 4K @ 125% due to a bug
Monitor 2 4K @ 150%
Monitor 3 (as needed) 1080p @ 100%

WACOM Intuos4 Large; X-rite i1Display Pro; NIKON D5600 DSLR

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | 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.