Scripting

[Ezbaze]

On 12/22/2024 at 9:55 PM, affi.usr said:

Anyone consider walking around problem and create scripting tools based on python library like this:

https://pypi.org/project/pynput/

https://pyautogui.readthedocs.io/en/latest/index.html

Is it maybe not great, but after creating tool for detecting exactly positions of toolbars it can create quite simple framework to automate any Affinity app without making developers anythings. Some parts are easy as sending keys we can switch to tool. The most crucial problem is deal with position of toolbars and clickable options. The best from this suggestion is that community can start now adding scripting without Affinity Team and some solution can be easy translate to others languages as well. 

Python is supported by MacOS and Windows. If we choose good, stable solution (library) automating mouse and keyboard will be universal.

The simplest solution for different screen size resolution is create template with coordinates of GUI icon buttons. It should be done once and after that used. The main downside is that this kind scripting can be affected by main OS tools (popup from other apps), and sometimes can be needed few seconds delay to working correctly. From other hand using any way to assign script to keyboard shortcuts we can run script independently and create some effects / boring stuff faster.  

I started, but I stopped after creating a new document. It's a lot of work, which I didn't think was worth it. The accessibility features let you do pretty much anything.

[evtonic3]

Is this the kind of scripting that will be in Affinity? If so it will be awesome! 
 

https://www.instagram.com/reel/DEXpjKnvlVW/?igsh=MW5keHZpZDJ3amNl

[n_shcherbakov]

On 1/3/2025 at 10:40 PM, evtonic3 said:

Is this the kind of scripting that will be in Affinity? If so it will be awesome! 
 

https://www.instagram.com/reel/DEXpjKnvlVW/?igsh=MW5keHZpZDJ3amNl

I'm really looking forward to the scripting tools coming to Affinity products, but specifically in this example there is a solution that already works:
 

[evtonic3]

2 hours ago, n_shcherbakov said:

I'm really looking forward to the scripting tools coming to Affinity products, but specifically in this example there is a solution that already works:
 

FANTASTIC! Now how smart does one need to be to figure these capabilities out?!! Need more people like you sir to put stuff out that makes Designer shine! Thank you!

[n_shcherbakov]

14 hours ago, evtonic3 said:

Now how smart does one need to be to figure these capabilities out?!!

I don't think I showed anything out of the ordinary, but thanks!

[evtonic3]

4 hours ago, n_shcherbakov said:

I don't think I showed anything out of the ordinary, but thanks!

You may think you didn’t, but how many of us knew how to do that? You know users  that know Affinity Designer well enough to do these “tricks” are not influencers or people that post tricks. Sure there are tutorials for so many things but even the age old tutorial is getting “old” - people want small digestible small videos that get to the point. That is where Affinity should be. Promoting tricks like this in small 15-30 second clips. I’m telling you this would help the new generation of users.

[n_shcherbakov]

14 minutes ago, evtonic3 said:

You may think you didn’t, but how many of us knew how to do that? You know users  that know Affinity Designer well enough to do these “tricks” are not influencers or people that post tricks. Sure there are tutorials for so many things but even the age old tutorial is getting “old” - people want small digestible small videos that get to the point. That is where Affinity should be. Promoting tricks like this in small 15-30 second clips. I’m telling you this would help the new generation of users.

Okay, I'm convinced. That's what I'll be doing in the near future.

upd: for me it's obvious why there isn't a lot of tutorial content for Affinity products ← insufficient professional user base ← insufficient features for professional use of the product (I've gotten the hang of it) ← lack of full feedback from the community and lack of a roadmap

*I purposely wrote in reverse order because the latter is the most important issue.

[JET_Affinity]

 

On 8/20/2024 at 5:50 AM, baoyu said:

I‘d consider the Scripting system be the BIG CHANGE 😂

On 9/3/2024 at 8:58 AM, fde101 said:

Realistically, yes, it would be, but the majority of users are likely more casual and will write off scripting as something they will never use.

The ability to use plugins for the products will interest a larger number of people than the scripting feature, but that will not drive sales of a new version until those plugins are available, so neither of these things will likely be enough, on their own, to convince Serif's marketing department to start advertising a new major release which they expect to charge people for.

Realistically, these should have been engineered into the core of the products from the beginning and should have been a 1.0 feature, so they are coming late and pushing them to a 3.0 release if they are ready by 2.x would be a bit much.

Like baoyu said, I would certainly expect the new scripting API feature to be major enough to justify the next pay-for major release. I'd be quite willing to pay for upgrading to the new version of all three apps.

Regarding fde101's concerns:

I completely disagree with the assumption that 'casual users' would "write off" the scripting feature, whether they are ready to write scripts themselves or not. Just look at Inkscape's Extensions menu. That effectively is Inkscape's built-in scripting implementation. But it doesn't just empower scripting users. A long list of Extensions are included with the standard download of Inkscape, and any user can pick and choose from hundreds of additional free Extensions that are created by other users. Inkscape would be far less capable to all of its users without its Extensions.

Prior to Adobe's Captive Customers rip-off licensing, I built a considerable number of Illustrator scripts in its Javascript-based scripting environment. But I've only just very recently started dinking around with Inkscape's Python-based extensions. That certainly didn't keep me from having Inkscape on-hand and using its Extensions for many years. Again, Inkscape would be far less capable to all of its users without its Extensions. I would certainly be surprised if the first release of Affinity's scripting didn't come with a broadly-useful set of pre-built ready-to-use scripts that demonstrate its power and potential.

Many users in this forum have pined for Serif to implement support for commercial 'plug-ins'. I consider that approach to adding bespoke features archaic, passe', inflexible, and needlessly costly. Providing a well-done scripting API has far more potential. Scripting users will no doubt be sharing the scripts they create with other users, either for free or for a small price.

Another misconception (I think; corrections welcome) evidenced in this thread is the notion that a program that has a scripting API has to have some kind of explicit built-in 'support for AI' in order to use an AI Chat to help writing scripts for it. I'm  no programmer and don't play one on the internet. But as I understand it, AI Chats fetch from whatever is 'out there' on the subject. While Inkscape 1.4 came out late last year, you can still get help from an AI Chat about writing Extensions for Inkscape, and it can even return fully-functional Extension scripts that work in earlier versions. Sure, new versions of software (for example, FileMaker Pro) are scrambling to add AI-centric access to AI from within the program's standard interface. That doesn't mean I can't use AI Chat to assist in building a complicated relational database structure in an earlier version of FileMaker.

JET

[krsdcbl]

2 cents on preferences and expectations for a scripting API:

JavaScript is great!

Let users bundle "script plugins" with node or deno, on top of direct in-app scripting - wile Python is insanely versatile and possibly more approachable to beginners, JS builds on a huge ecosystem and mature package managers. If possible, even provide TypeScript interfaces.

Thinking ahead, since Affinity was aquired by Canva, I suspect it could be very likely that in the coming years the ecosystem gets tied closer together - since Canva is web based, keeping a scripting API in JS/TS could lay a foundation for building utility that connects functionalities of those platforms. Build stuff in Designer, use a script to expose assets & symbols to asset libraries in Canva, etc.

Don't abstract things too much, give us raw access & a good plugin interface

Another big advantage of JS ecosystem is that today, it's mainly used for webapps - and that means GUIs! If I'm not only able to script around with the objects in Affinity, but can add a "custom widget" with arbitrary UI elements, I can create plugins and add functionality that other Users don't have to know how to script to use. It's unquestionably a challenge to properly sandbox such things and keep it secure, but it could make it insanley accessible to implement own little tools that are much more than just a script file.

Wherever possible, keep things SVG!

Another amazing synergy is that (as far as i understand), a lot of the internal vector stuff in affinity is kept in SVG - which is XML, is representable as a DOM, and therefore script authors could leverage a plethora of existing libraries for DOM manipulation, SVG animation, and and and. If we can manipulate vector data in designer as XML, even within boundaries, there'be an insane amount of existing, purpose-made tooling that can be applied, for which the native API possibly wouldn't have to provide own functionality by itself.

Wherever possible, provide access to native SVG properties and CSS! If I have a vector object or text in Designer which' fills, strokes, appearance etc are represented in SVG and kept in sync with the UI, it'd be so much easier to create automations, link properties to each other, build "custom setups" like you'd see in Cinema4D for example. Which brings me:

Make Properties linkable & interpretable without the need to go deep into the API!

I'd love to be able to make a "cloner Script" for filling a box with symbols after a specified pattern, and then have it listen to that box' dimensions, do some calculations, and update properties of the strokes in the contained objects, as a simple example. I'd love to see Serif draw inspiration from Cinema4D here, since such functionality might not even require to go into "actual scripting" - a node based interface like C4Ds Xpresso would be way enough to achieve such things as above: drag an element into the node-based-editor, pick-link it's property to another elements property, add a Math node in between, voila: you don't need "scripts". And that leads to the conclusion:

Don't try to serve different intents with the same tool!

The Scripting API should be powerful and in-depth, and duly avoid compromising on utility for keeping it "beginner / non-dev friendly". If you implement an API that is dumbed down to make it easier to script without any idea of coding, you'll just end up with an interface that is still complicated and verbose to non-devs, but at the same time will be highly limiting and dissapointing to people who code. You'll end up with an tool that is not really useful to anyone, and was cumbersome to implement since it must pass everything it does to layers below that actually "do the things".

If your scope is to make it easy for non-technical users to unlock "scripting" functionality, and you have the ressources to design interfaces and APIs to serve that specific purpose: opt for a node-based visual approach, and expose the underlying libraries as-is for anyone who wants to go deeper!

If such an interface is not within the scope, then still go with the "big boi API" approach and empower the community. Tech-savvy users will step in and create custom scripting abstractions that make it easier to do stuff for anyone not versed with code, and your Add-On Store is already an ideal platform for distributing such community provided interfaces & utilities to end-users and creators who can't or won't dive into learning js and your API.

Trust the users, trust the community - give them real tools, not toys!

One last thing: I know Affinity programs are not FOSS, but maybe it's worth to embrace some of the open source approach:
The API is far from done, but that's no reason to keep it out of "pre-alpha" - if possible, allow access to whatever is there so far in the Beta program, make it abundantly clear that none of that is anywhere ready for production, and that it's highly unstable and not to be used for actual work yet - but let interested dev-focused users just play with it and provide feedback and ideas as early as possible.

Good things come from demoing early, great software is built from abundant feedback - and the latter goes thenfold for anything that is a "coding product"!

[fde101]

On 1/17/2025 at 6:52 AM, krsdcbl said:

a lot of the internal vector stuff in affinity is kept in SVG

Why would you think that?

99.9% confident this is wrong.

[ohmantics]

I've spent the last several days trying to build some custom SF Symbols using Designer 2. It's been miserable.

One missing aspect is lack of scripting.

Most professional art tools that have scripting have Python support. JavaScript suffers from a broken numerics model and I'd be concerned that trying to work with computations around Bezier control points would have unexpected results.

[Jon W]

11 hours ago, ohmantics said:

JavaScript suffers from a broken numerics model...

Care to elaborate? JavaScript uses the same 64-bit double precision numbers as every other common language, which Affinity also uses internally. So it's perfectly capable of manipulating any aspect of our documents with no loss of precision.

[Affinityconfusesme]

@Jon W  I can elaborate. I program in java and it is similar to javascript in syntax so I'd assume that numerics is similar. In general there is a lot of similarity between the languages even though they are different. Also I'd love to get a progress report on how things are progressing as that would be very nice...

[Jon W]

11 minutes ago, Affinityconfusesme said:

Also I'd love to get a progress report on how things are progressing

Well... I can tell you that scripting development is still going strong and progressing as planned. There's a lot still to do, but rest assured: we'll get there eventually!

[krsdcbl]

On 1/21/2025 at 3:27 AM, fde101 said:

Why would you think that?

99.9% confident this is wrong.

Happy to stand corrected, this is why I prepended what you quoted with "(as far as i understand)"

My assumption comes from the software handling clipboard data as SVG, as per the settings - which leads me to think that there must be internal interfaces to at least easily transform SVG data into the internal object structure bidirectionally, even if it's not "stored" as such, and thus it may be a viable approach to apply existing svg tooling to the scripting API (still assuming, pls do correct me if u know better!)

[krsdcbl]

32 minutes ago, Affinityconfusesme said:

@Jon W  I can elaborate. I program in java and it is similar to javascript in syntax so I'd assume that numerics is similar. In general there is a lot of similarity between the languages even though they are different. Also I'd love to get a progress report on how things are progressing as that would be very nice...

This is pure assumption and wrong generalization. Besides the name, those two languages have little to do with each other - think of "Javascript" as a sort of nickname for what is actually called ECMAScript

There are some issues with floating point precision indeed, but they are well known and there's plenty ways to mitigate them. And when it comes to other oddities with NaN/typing stuff etc, using TypeScript for authoring & compiling your js is highly encouraged, solves those issues and brings a plethora of other advantages

[Jon W]

6 minutes ago, krsdcbl said:

My assumption comes from the software handling clipboard data as SVG, as per the settings

The "Copy items as SVG" setting means that items are copied as SVG in addition to our native format. This is for pasting items into external apps. When pasting in Affinity, we always prefer the native format if available - we don't convert back from SVG.

[krsdcbl]

3 minutes ago, Jon W said:

The "Copy items as SVG" setting means that items are copied as SVG in addition to our native format. This is for pasting items into external apps. When pasting in Affinity, we always prefer the native format if available - we don't convert back from SVG.

Aaah thanks a lot for clarifying, that makes sense!
In that case, forget my musings about SVG tooling in the long post above (it was just a side thought anyway) 

[fde101]

6 minutes ago, krsdcbl said:

think of "Javascript" as a sort of nickname for what is actually called ECMAScript

JavaScript was the original name back when the language was created, and is something of a misnomer as it really has nothing to do with Java except to leach off of the at-the-time popularity.  Java follows a traditional class/object model with a well-defined class hierarchy, while JavaScript uses prototype-based inheritance, a completely different form of object-oriented programming.  Java is strongly typed, JavaScript is decidedly not.  Very different languages.

The language was originally created by Netscape specifically for use on the Internet (in web sites) and it was a semi-proprietary language which did not really have a well-defined standard backing it up.

Over time, the language was extended in various ways that really didn't make sense with regard to the original design, with a variety of completely different design patterns being introduced with a total lack of consistency, resulting in the horrible wreck of a language that has since been standardized as ECMAScript.

ECMAScript refers to the standardized language minus the DOM, making it more generic for use in applications other than web sites.

JavaScript by now refers to ECMAScript with the DOM, meaning it is the language as used in a web browser.  JavaScript is in essence a specialization of ECMAScript - it is ECMAScript specific to use on web sites.

People still tend to refer to JavaScript when it is used as an application scripting language, but this is not really correct usage; what is being used for application scripting is actually ECMAScript, not JavaScript.

[Jon W]

Just to (hopefully) draw a line under this scripting language debate:

1. We chose JavaScript (ECMAScript) for reasons that I'm not going to go into here! 
2. JavaScript floating point precision is as good as any other scripting language we could have chosen. 
3. Although its native number type is floating point, integers up to 2^53 are represented precisely; if you need more then there's BigInt. If you need integer truncation then there's Math.floor. In other words: it's not a problem.
4. Our JavaScript SDK is implemented as a plugin and built on top of our C++ SDK. This means that although we currently have no plans to do so ourselves, it will be fully possible for anyone to implement "first class" support for Python or any other scripting language.

[Peter Kahrel]

Sounds very sensible, pleased to hear it.

Can you say when there'll be something for us to play with?

Thanks,

Peter

[Jon W]

3 minutes ago, Peter Kahrel said:

Can you say when there'll be something for us to play with?

Sorry Peter, I'm afraid we can't comment on timescales for upcoming features.

[Peter Kahrel]

Ok, fair enough. Thank you.

[CM0]

19 minutes ago, Meliora spero said:

This could potentially impact precision and accuracy when manipulating Bézier nodes

Spline runs in the browser - https://spline.design/#features

Graphite runs in the browser - https://graphite.rs/

Modyfi runs in the browser - https://www.modyfi.com/

Don't worry, this is not an issue.

[garrettm30]

4 hours ago, Jon W said:

Our JavaScript SDK is implemented as a plugin and built on top of our C++ SDK. This means that although we currently have no plans to do so ourselves, it will be fully possible for anyone to implement "first class" support for Python or any other scripting language.

That is an interesting hint. Am I wrong to infer that third-party plugins of various kinds will become a possibility?