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

Recommended Posts

Well, since this is (or was) all about scripting support for Affinity Publisher, I think we are getting far beyond here. 

As long as the scripting language is easy to access and that scripts are easy to run inside an Affinity application, we should be fine. Reasonable choices would be Python, Javascript and the like. Maybe Swift could be made into some scripting extension of some kind, I don't know where Apple put the limits. But in my head at least, Publisher would be the run-time environment for the code, and it would not need to be compiled or packaged or built in any way to be run. Running it from within, say, a panel window inside Publisher, should be enough.

Link to comment
Share on other sites

14 hours ago, v_kyr said:

In contrast to that, modern languages like Rust/Go/Swift/Kotlin/C# etc. do partly already address certain of the weaknesses of older prog languages like C/C++

None of them really address the readability of the code, so it continues to be much more difficult to maintain than code written in languages such as Ada or even (to a lesser extent) Pascal.

Any language feature that makes code harder to understand is also going to make it more likely that errors will be introduced during any maintenance of the code (after having already slowed the maintenance by forcing the programmer to spend more time trying to understand what is already there so that it can be extended or modified as desired).

JavaScript is among the absolute worst languages I have seen (better than C from a security issue perspective but much worse in terms of overall language coherency), and I thoroughly dislike Python.

 

1 hour ago, zixdesign said:

Publisher would be the run-time environment for the code

We have been over this many many times in this thread already.  This is fine for scripts that are limited to the Publisher or Affinity ecosphere, but there is also a use case for scripting to be able to integrate multiple programs together from across different vendors.  For that an OS-level solution is required, or at least something that can communicate outside of the application(s) the script is running in.  Running a script (of whatever language) within Publisher is a good start, but it is not a complete solution.

Link to comment
Share on other sites

@fde101 I somewhat agree with you. I learned a bit of Pascal in high school, it was fun. I've never used Ada but I read through the introductory pages and I kinda like it, but I noticed that many of the features it boasts exist in Swift.

Of course, Swift doesn't have a clear distinction between declarative and imperative code as does Ada, but also nothing is stopping you from organizing your code that way. Descriptive block statements (like if ... then ... end if versus if ... { ... }) can be nice but that could be remedied with inline hints in modern code editors if you really needed it (don't know of any examples though) like they already do for type inference.

I don't think Ada would be a bad choice for Affinity. There are surely some things that it's simply the best at, and that's not necessarily limited to industrial / safety-critical applications. But if we're going to eschew weakly-typed and popular "scripting" languages like Python, I would submit Swift for consideration as a balanced middle-ground, with its bidirectional type inference, and less rigorous rules. Personally I find that the strong type system and other compiler features help quite a bit in catching mistakes during refactoring! I almost always get errors when I change stuff around and addressing those errors usually ends me up in the right place. (Sometimes the compiler just refuses to parse a large/complex expression and doesn't give you any helpful pointers though. 🥲)

Of course, the other mentioned languages, like Kotlin, would be pretty equal contenders in that regard as well, from what I've seen. I'm not a Swift shill as some have previously in this thread accused me of being.

♥️Affinity v2; macOS 14; ⌨️🖱; recreational user since 2014.

Link to comment
Share on other sites

@hawk, a typical example of how Ada helps to promote type safety would be the fact that you can define your own integer types.  For example, I can define a type which can only contain the values 1 through 5:

type My_Integer is range 1..5;

That range will always be enforced by the compiler, either at compile-time (where possible) or at run-time (when necessary).  Defining custom types which are very specific like this can help to catch a lot more problems than would be caught otherwise.

 

Consider also that there are both types and subtypes, where subtypes within a type will convert "automatically" but separate types require explicit conversion.

Say I have an object ID and a color ID which are both numbers.  In Ada I can catch errors in which they might be confused by explicitly making them different types:

type Object_ID is range 0..2**32-1;
type Color_ID is range 0..2**16-1;

procedure Change_Fill_Color(o : in Object_ID; c : in Color_ID);

In other languages these would usually just be integer types and the parameters could be mixed up more easily.  If I tried reversing them, because the types would not match, the compiler would catch this error.

 

That said, I don't believe Ada would be a good fit as a scripting language for an application because it is a VERY large and heavy-weight language.  It is what the application itself should be written in, but you would need something a bit simpler and lighter-weight for the scripting.  I have never seen one that I actually consider good, but some are worse than others, and I definitely consider JavaScript to be among the worst.  Python has never really sat well with me - never liked the idea of using indentation as syntax for anything other than assembly language.  Maybe it just reminds me too much of the "punched card" mentality of traditional FORTRAN syntax (granted it is used very differently in Python)?  Don't know.

Link to comment
Share on other sites

@fde101 Nice! Swift is getting improvements to its static abilities (build-time constants for starters) in the near future, so I will try to bring this up during those discussions. The closest thing to this right now would be enums, for which every value has to be named, or property wrappers, which are not statically checked.

I agree now that JS is one of the worst, and Lua would be a good choice. I've been using Lua a bit with the macOS scripting tool Hammerspoon.

♥️Affinity v2; macOS 14; ⌨️🖱; recreational user since 2014.

Link to comment
Share on other sites

On 5/6/2022 at 3:51 PM, fde101 said:

None of them really address the readability of the code, so it continues to be much more difficult to maintain than code written in languages such as Ada or even (to a lesser extent) Pascal.

As the syntax of a programming language describes which combinations of characters form the code and error-free programs of the language, it's of course also always a matter of knowing & understanding the syntax of a respective language quite well. So to say to be used to it! - Further in terms of the readability of code here then, to use a good programming style (code formatting & indentation rules etc.) for the specific languange.

There are also code beautifiers & formatters available for a bunch of programming languages, which can help to make obfuscated looking code in a specific language then more readable to some degree. There are also code checkers (linters) which can be a help to find code style, syntax errors and structural problems in code. - Modern & powerfull IDEs (IntelliJ Idea, VS, Xcode ...) usually do already have automatic build-in support of certain of these toolings for the programming languages they support.

Though I agree, that some prog languages do have generally a worser and harder to learn syntax than others here. Further when doing non-trivial coding in JavaScript & Python having a good linter for those is often somehow mandantory then. - All in all, every language has its advantages and disadvantages, there is no one language that meets all needs everywhere and at all times.

Related to Swift and scripting, that would be possible too , see also here, at least for/under MacOS, though I don't know if it's portable for/into the MS world here in some reusable sense then too.

☛ 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

10 minutes ago, v_kyr said:

Related to Swift and scripting, that would be possible too , see also here, at least for/under MacOS, though I don't know if it's portable for/into the MS world here in some reusable sense then too

 

https://www.swift.org/blog/swift-on-windows/

-- 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, v_kyr said:

Related to Swift and scripting, that would be possible too , see also here, at least for/under MacOS

Good stuff. Really, I skimmed that article and it looks like a great resource/tutorial. However, it really shows that Swift is far from well-suited for OS scripting, or at least for interoperating with shell tools/processes. The amount of boiler plate required to get piping to work is just outrageous.

image.png.95e6694d96c34f27b0c6e32ecbc43920.png

If you're going to use Swift for scripting, you'd better try to stick with the built-in frameworks as much as possible. And even with that there are portability issues because Foundation is slightly different on macOS than Linux or Windows. 🫤

♥️Affinity v2; macOS 14; ⌨️🖱; recreational user since 2014.

Link to comment
Share on other sites

29 minutes ago, walt.farrell said:

I know and monitored the Swift blog there for some time. But not all Swift related is still portable among the two OSes, there are still ...

Quote

Adding support for Windows to Swift is the beginning of a journey. The current support sets the first milestone where the language is usable. There is yet another even broader part of the ecosystem like lldb and the Swift Package Manager which still need more work to be as complete in their support for this different platform.

... a bunch of things to do for a seamless interoperation of Swift here.

☛ 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

People, we need to take a breath and pause for a moment. This is about adding scripting abilities to the Affinity Suite of applications. I need to use other applications as well as the OS with scripting. I will bet that MS Word can be manipulated with Python, I really doubt that it can be manipulated with Ada or Pascal or Fortran or Swift. 

Are my assumptions correct? I am talking about using things 'out of the box', not something that requires a lot of additional applications and libraries and frameworks added to the basic OS. I won't be happy if Affinity comes out with a scripting solution which means I can only use the three affinity applications and not have access to other applications' scripting abilities because they don't work with the choice that is 'secure' and has good 'types'.

Consider the end user, how many of us can remember anything about Faprol (Favourite Programming Language) or even used it in the first place. It has been close to 30 years since I switched from Pascal to C and it has been about 15 years since I did anything with C or any of its cousins. Never used Ada or Fortran or ...

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

4 hours ago, Old Bruce said:

I need to use other applications as well as the OS with scripting.

 

Yes, as I just reiterated a few posts ago:

On 5/6/2022 at 9:51 AM, fde101 said:

We have been over this many many times in this thread already.  This is fine for scripts that are limited to the Publisher or Affinity ecosphere, but there is also a use case for scripting to be able to integrate multiple programs together from across different vendors.  For that an OS-level solution is required, or at least something that can communicate outside of the application(s) the script is running in.  Running a script (of whatever language) within Publisher is a good start, but it is not a complete solution.

 

The selected language is irrelevant if it cannot hook into the underlying OS and connect in both directions with other applications - accepting data and instructions from outside the Affinity applications, replying to them, and possibly vice versa with an embedded language if one is provided.

Link to comment
Share on other sites

I'm beyond depressed reading this thread. I started it almost 4 years ago and there's been nothing but crickets...

For mine there should be a few criteria for scripting:

1) it must be cross platform. I don't care if it's two languages (like InDesign) or one but clearly one would be better. I think the obvious one would be javascript but at this stage I'd be happy with even a basic Applescript library

2) it should be able to access non-Affinity apps (Filemaker, Access, Word, Excel etc). The real power of scripting comes from inter-app data sharing. Virtually everything we do with InDesign involves pulling data from our editorial or advertising databases.

3) it needs to be easy enough for a non-programmer to access. Whilst I'm now a programmer, I started my coding journey writing scripts and scripting should be easy enough for a novice. I can't believe people are suggesting every known programming language for simple scripting - some of which would be a terrible introduction to coding.

Given the elapsed time, I think Affinity have given up on the idea of scripting. Sales data probably suggests their market is 'backyarders' so they're largely ignoring the commercial market where scripting is widely used. Ironically, if they had more advanced features they would probably make inroads into the commercial media space. I think not targeting large businesses is vastly underselling Affinity's potential.

I believe if Affinity had serious plans for scripting they would announce it in a roadmap similar to how they announced the iPad products. You'd think if there was even an inkling it might be in the future there would be messages/surveys going to users - particularly users in this thread - about what might be desired.

No, I think scripting is as good as dead and buried so discussion about languages is moot.

Link to comment
Share on other sites

On 5/5/2021 at 7:28 PM, loukash said:
On 3/26/2021 at 11:06 AM, kimtorch said:

We do these tasks thousands of times a week (literally).

If so, you will likely be able to afford hi-end software that can do the job for you the way you need. Right?

Yes we can, and it's exactly what we do.

You seem to be suggesting Affinity has no desire for our business and the way to resolve the deficiencies of their product is to use a different app.  No problem, I'm sure they're happy for you to tell people not to use their software.  I'd bet we're not the only media company who'd love to change but won't because they can't do the job we need.

Link to comment
Share on other sites

On 5/8/2022 at 1:51 AM, kimtorch said:

No problem, I'm sure they're happy for you to tell people not to use their software.

affinity.serif.com/licence > §23 (Windows section) or §24 (Mac section)

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

  • Staff
On 5/8/2022 at 1:26 AM, kimtorch said:

I'm beyond depressed reading this thread. I started it almost 4 years ago and there's been nothing but crickets...

For mine there should be a few criteria for scripting:

1) it must be cross platform. I don't care if it's two languages (like InDesign) or one but clearly one would be better. I think the obvious one would be javascript but at this stage I'd be happy with even a basic Applescript library

2) it should be able to access non-Affinity apps (Filemaker, Access, Word, Excel etc). The real power of scripting comes from inter-app data sharing. Virtually everything we do with InDesign involves pulling data from our editorial or advertising databases.

3) it needs to be easy enough for a non-programmer to access. Whilst I'm now a programmer, I started my coding journey writing scripts and scripting should be easy enough for a novice. I can't believe people are suggesting every known programming language for simple scripting - some of which would be a terrible introduction to coding.

Given the elapsed time, I think Affinity have given up on the idea of scripting. Sales data probably suggests their market is 'backyarders' so they're largely ignoring the commercial market where scripting is widely used. Ironically, if they had more advanced features they would probably make inroads into the commercial media space. I think not targeting large businesses is vastly underselling Affinity's potential.

I believe if Affinity had serious plans for scripting they would announce it in a roadmap similar to how they announced the iPad products. You'd think if there was even an inkling it might be in the future there would be messages/surveys going to users - particularly users in this thread - about what might be desired.

No, I think scripting is as good as dead and buried so discussion about languages is moot.

Affinity will support Javascript and also have a 'C' based API binding interface that people can use to write plugins. We will also have the ability to create UI to support their scripts and plugins with dialogs and panels. 

We have a team developing this but the amount of work is very large so unfortunately users will need to be patient.

Link to comment
Share on other sites

23 minutes ago, TonyB said:

Affinity will support

YES YES YES!

23 minutes ago, TonyB said:

Javascript

🥴

(joking of course, lots of people did want JS after all)

25 minutes ago, TonyB said:

and also have a 'C' based API binding interface that people can use to write plugins.

Nice! That sounds like I could write a Swift package wrapping that API. The same could probably be done for Python and others.

26 minutes ago, TonyB said:

We will also have the ability to create UI to support their scripts and plugins with dialogs and panels.

That's great to hear!

27 minutes ago, TonyB said:

We have a team developing this but the amount of work is very large so unfortunately users will need to be patient.

Send my regards to the programmers, I really appreciate their painstaking work!

Thanks for the update, @TonyB !

♥️Affinity v2; macOS 14; ⌨️🖱; recreational user since 2014.

Link to comment
Share on other sites

3 hours ago, TonyB said:

Affinity will support Javascript and also have a 'C' based API binding interface that people can use to write plugins. We will also have the ability to create UI to support their scripts and plugins with dialogs and panels. 

That's good enough for me. Much the same way it was done in InDesign.
Since Javascript reads and writes text files, for those that can stand using a conversion-to-txt stage, excel, filemaker and others would still be available the old fashioned way.

 

3 hours ago, hawk said:

Nice! That sounds like I could write a Swift package wrapping that API. The same could probably be done for Python and others.

That's really great if that works :) Would make it worth it learning either the one or the other for me. 

Thank you programmers, thank you for the update @TonyB!

Link to comment
Share on other sites

5 hours ago, TonyB said:

Affinity will support Javascript and also have a 'C' based API binding interface that people can use to write plugins. We will also have the ability to create UI to support their scripts and plugins with dialogs and panels.

👀 Oohh, very interesting… thank you for the heads-up! I look forward to hearing much more about this as it develops in the future, but for now I'm happy to have this initial acknowledgment of direction and intent. 👍

Link to comment
Share on other sites

5 hours ago, TonyB said:

Affinity will support Javascript and also have a 'C' based API binding interface that people can use to write plugins. We will also have the ability to create UI to support their scripts and plugins with dialogs and panels. 

We have a team developing this but the amount of work is very large so unfortunately users will need to be patient.

Thank @TonyB for that information.

One thing that I'd love to know, if possible, is how you are going to deal with automation which remains platform specific.

Apple during the last Year WWDC announced that the future of automation on MacOSX is Shortcuts (replacing AppleScript). I have no doubts that on this year's WWDC, just next month, we will see a bigger push towards that.

Windows, no doubt, have their own technology. 

Are there any plans to take advantage or each platform unique automation technologies?

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

  • Staff
2 minutes ago, Seneca said:

Thank @TonyB for that information.

One thing that I'd love to know, if possible, is how you are going to deal with automation which remains platform specific.

Apple during the last Year WWDC announced that the future of automation on MacOSX is Shortcuts (replacing AppleScript). I have no doubts that on this year's WWDC, just next month, we will see a bigger push towards that.

Windows, no doubt, have their own technology. 

Are there any plans to take advantage or each platform unique automation technologies?

We will support a very limited set of platform specific automation functions with one of those exposed functions being able to pass a Javascript snippet that will then have full access to Affinity. 

Hope that makes sense.

Link to comment
Share on other sites

❤️@TonyB Great news! Thank you for officially confirming this. It's a lot of reassurance for us scripting people to know it's on the horizon, even if it takes a lot of waiting.

Good move on JS support IMHO, as it onboards the existing Adobe scripters with the necessary DTP expertise, and a lot of the frontend guys.

Link to comment
Share on other sites

[resigned sigh emoticon]

I loathe Javascript.

Not me, I hate it.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

Personally, I'm beyond building emotional relationships with the technology I use to get the job done 😉

We probably get the best of both worlds - gets as high-level and as low-level as practically possible, with very sane defaults considering the demographic.

Technically, I think it would be nice if the default JS integration was built on top of the C api, so they would match feature-for-feature. I kinda suspect it's gonna be like that, because that means Serif doesn't need to maintain two distinct solutions.

In that case, it would be nice if the JS implementation was opensourced, even retaining copyrights - the non-JS-inclined people and addon devs would get a lot of delicious and testable API usage samples.

That has been a source of great confusion with Adobe ExtendScript documentation, in many areas you had to go by feel on what data types are accepted by a function, sometimes to the point of documentation being not only vague, but plain wrong.

Link to comment
Share on other sites

23 hours ago, TonyB said:

Affinity will support Javascript and also have a 'C' based API binding interface that people can use to write plugins. We will also have the ability to create UI to support their scripts and plugins with dialogs and panels. 

We have a team developing this but the amount of work is very large so unfortunately users will need to be patient.

It's encouraging to hear this and I want to thank TonyB (and Affinity) for putting it out there. At least we now have some glimmer of hope for the future.

I'm happy enough with javascript as the language. It makes sense to have a single, cross platform language and with JS already available in InDesign, it means a lot of active scripters will have a head start. It will be interesting to see the syntax and object model - just imagine if a script which runs on InDesign could run on Publisher with only minor changes (similar to how Affinity works their magic with IDML files). I know it's fanciful, but it really would be magical!

I'd love to have a rough time-frame but I expect that's asking too much. As mentioned elsewhere I'd be happy with some basics to get started and then build up the library over time.  

Having an API is also encouraging. I don't write C but I can imagine there will be an active marketplace for plugins if they keep to the low-cost Affinity model.

Link to comment
Share on other sites

On 5/9/2022 at 4:01 AM, TonyB said:

Affinity will support Javascript and also have a 'C' based API binding interface that people can use to write plugins. We will also have the ability to create UI to support their scripts and plugins with dialogs and panels. 

We have a team developing this but the amount of work is very large so unfortunately users will need to be patient.

Thank you so much for this "hard" information. I may have differing degrees of affinity for various scripting languages, but the complete lack of one has been an obstacle to using Publisher to its fullest potential. Also, I'm tired of screen-sharing from my now-ancient late-2012 iMac to produce specific publications in my now-ancient but miraculously functioning InDesign CS6 installation that supports both full scripting and saved searches.

This is just great news, and I appreciate the persistence of the programming team in getting this done.

bbuds_and_Web_Versions_21-22.png

-- 

Matt

 

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.