chessboard

If we can't add new characteristics to existing tools, I hope we can, at least detect clicks/double clicks/drags/drag&drop, etc, in documents/artboards, so that we could implement new "tools".

I don't get why this is a problem on windows. The Mac versions can do this since version 1 (I think). Almost any software on windows offers the ability to arange subwindows in the application window. Even Serif Draw Plus could do this.
This is a really important feature, please, please implement it in the Windows-Version, too!

Many good suggestions have already been made. For me, it would be nice if scripts were generally able to replicate (automate) workflows that I do "by hand" but have to repeat multiple times (20, 40, 60 or more times depending on the project). Therefore, it would be nice if scripting was able to control every part of the applications, such as making selections, arranging layers, applying filters, creating, duplicating, moving and deleting objects, opening and saving documents, switching between open documents, applying or changing object styles and so on.
It would also be very helpful if scripts allowed the user to make adjustments while the script is running. For example, you could open the dialog for a filter and let the user make adjustments, and then after pressing "OK", continue the script taking into account the user's input. Or, even simpler, let the user select files using the open or save dialog. It would be even nicer to be able to create custom dialogs for scripts.

Hi, I've been lurking in the forums for quite a while now on scripting-related topics, hoping to see it added to the Affinity Suite. I run a comic localization company, and we use InDesign and Photoshop extensively in our business. Since people were mentioning usecases, I will give an example of the two main ones it would be great to have so we could switch our large team over to the affinity products:
1. I have built up a complex system (web GUI, server etc) to control (the very expensive) InDesign Server. We received thousands of chapters from Japanese publishers in InDesign containers (it's the dominant format in this industry). Since our team operates in Photoshop, not InDesign, I have a system that ingests these files, and converts them to PSD files. I also have an alternative pipeline that exports the contents of an entire InDesign project to a PDF file. Both of these are essential to our workflow. I know that due to the difficulties of implementing .indd support in Affinity Publisher, the full workflow will probably never be truly replaced, but Publisher can at least open .idml which we can mandate the usage of to some extent.
An essential part of this is mimicking the "Bridge" functionality. I can use the (admittedly ugly) "BridgeTalk" functionality of InDesign Server to interact with both InDesign and Photoshop at the same time, so having the functionality to script between different Affinity apps would be nice, although not required.
Throughout this entire workflow, something that has been really nice about Photoshop's scripting is that I can do literally anything I can with Photoshop actions in the scripting language. The process is a little painful, but if the docs suck for a specific operation, I can record an action in Photoshop, then use publicly available tools to convert the action file into a bunch of scripting commands, which has helped when doing things people don't normally do.
Overall, the Photoshop portion involves importing the exported PDF layers from InDesign into a document as layers (with a specified DPI), then turning the entire thing into a smart object, and resizing the document and occasionally changing its format to grayscale. Something that I miss with the resizing step is the ability to specify the resizing algorithm, so if we could have the same control Affinity Photo currently gives you in the GUI (Lanczos etc) that would be great
 
2. We have written tools based on publicly available scripts (such as https://swirt.github.io/typertools/) which improve productivity for our freelancers greatly. I can't emphasize enough how much work this tool saves people when lettering comics. It's probably the single most important reason they can't switch to Affinity Photo, because all of #1 still technically would work since Affinity Photo can read PSDs (even with smart objects!). We need the ability to build complex GUIs that are built-in to the program (or at least as a pop-up window that does not prevent focus on the document). I don't like saying this, but I think Adobe's choice of going with a "webview" was the correct idea, because there's no GUI toolkit as extensible, hackable, and for which you can find devs that's better than chromium. I think exposing your own widget toolkit would be better for puritans and for the experience, but I'm not sure how you're going to possibly implement every possible widget someone needs, meaning they'll be constrained and therefore irritated when they don't have e.g. a special color picker, custom vertical fader, or whatever else their GUI requires.
As a side-note, we are currently working on developing another script/GUI in photoshop to allow for direct uploads/downloads of the documents to our project management system. Some kind of `fetch`-like API access would be nice. I know the difficulties and dangers involved with letting a script communicate with the outside world, but I don't think you're going to be able to compete with Adobe without an equivalent to their "Socket" API.
 
I hope this helps you a bit, and I eagerly await scripting abilities.

What I would like is to be able to select a number of groups in the layers panel and run a script which would rename the layers in the group with the group's name and incrementing numbers. So there would be Items 1, and Items 2 plus Shapes 1, Shapes 2, and Shapes 3.

==============
I would also like to be able to take the name of the group and prepend/append it to the names of the layers in those groups. So I have Bob Left Arm and Alice Left Arm etc.

===============
Search for named layers using regular expressions would be useful too. Then I could get rid of the various file extensions in Placed files.

==============
 

I think the most important thing is that the scripting works in the first place. Whether the language used for it satisfies the aesthetic demands of all users is secondary. JavaScript may not be a particularly attractive language for purists, but in the end, all that matters is that I, as a user, can tell the Affinity apps what to do, and they will do it. Everything else is an ivory tower discussion in my eyes. At least for the tasks that I expect a scripted graphic & photo design software to do. For other projects this discussion about the quality of programming languages may make sense.

This is laughably wrong. Ask Apple, Microsoft, Adobe, Google or any other software producer.
Going for perfect means a product NEVER gets released. Perfect is a utopian aim, but a naive, unrealistic project path - especially for a company the size of Affinity.
InDesign's scripting isn't perfect - but I'm glad we've had access to it for 20 odd years.

A few more.
Get (and set) currently selected object / text cursor/range position and attributes.
Get (and set) some of the common settings and current defaults. For example, a script might need to know which measurement system is in use or where files are opened from or saved to.
It would be nice to be able to record actions to generate JavaScript code.
Disable and enable screen redraws, with enable forcing a screen redraw. This would allow complex scripts to do things like generate hundreds of pages without bothering to refresh the screen.
Some way to display a modal progress meter with a cancel button, and of course the ability to update the meter.
Ability to show/hide/position/scale panels, tools, and document windows so scripts can customize the UI.

Ok actually this was just an announcement about the GM build and is digressing a lot into specific issues or feedback which should be started as new threads - if it's a bug in bug reporting, or a feature suggestion in feedback. I'm going to lock this thread now.

@Rick G Sorry, but you know who you are talking to, do you? 🤨

"For me" that works and is helpful. I never rule out the idea that it can be something on my end. I detailed this in another post. THAT IS NOT THE FIRST GO-TO
As for me, the idea that the checked new document stops the update should be enough for the developers to look at. I would think it should close a blank document or offer to save and close one with content
Don't apologize: I don't need it and you don't mean it This will keep happening. Someone will post something and it will be attacked by the grammarians and the spelling cops until the original idea is all but lost. Please just stop that! as for default document ... do you think that if the first response was "what do you mean by default document" things might have gone better? Of course it would although a lot less fun and fulfilling. Since programs like word an excel open to a "default document" I will not hang my head in shame over that usage although it was a bit confusing in an Affinity context.
But I am don with this one and am not worried if anything is done with this. You guys beat me to death over this and I do not have the energy  to contend with this silliness.

I'd add that in addition to being able to access the document object model and all object and text attributes, I'd like to see text variables, labels, and generic markers.

Whilst I appreciate everyone wants even the most obscure functions to be scriptable, let's not let 'perfect' get in the way of 'good'. Remember this is a product that currently supports NO scripting at all so I think it's better to keep requests realistic based on where it now sits.
Rather than imagining ideas of what could be done in the future, I suggest people start by submitting what they currently script in InDesign or Quark. This way Affinity have a good idea of what people are currently using and actually NEED in the AP scripting model. From reading this entire thread I'm sure there are a lot of people here who have never scripted InDesign or Quark in their life - they're more concerned about pushing their language preference than actually getting print work done.
But I digress...
Very few of the things I've seen listed are of any interest to us (yes, I know they may be 'important' to others) but we are a publishing company and have a desperate need for the basics of printing and publishing. These aren't things we'd like to do in InDesign - these are things we do literally hundreds or thousands of times a week and need Affinity to support before we'd ever consider changing.
Generate pages and documents based on templates Create frames with definable properties (type, geometric bounds, colours, text properties, name etc) I'll reiterate naming of frames as that is vitally important to the way we address target frames in InDesign (script labels) Populate frames with text or images allowing all fitting options Importing of tagged text and RTF - ideally adopting the Adobe model of tagging so existing frontends would 'just work' Create PDFs, jpegs, EPS files with definable presets Iteration through frames and placed images Ability to manage colour spaces  Scripted preflighting This is obviously not an exhaustive list but it's the primary functions we need to get a start. Our company simply can't run without automation. AP could be the best page layout product in the world but until we can do at least the basics of automation it's essentially worthless to us.

Indeed. And there are a few things that traditional compiled languages can’t do, like relatively easily exchange the same code across platforms. And a lot of the hardware or OS is accessible from scripting languages via libraries anyway. And often you aren’t really getting much speed advantage from compilation when most of the actual computation is going to be taking place inside the host application anyway.
And for everything else, there is the C API. C isn’t my favourite language either, but the C ABI is the lingua franca across interpreted languages, and if you have a C ABI it’s not that hard to whip up a FFI to call it from Rust or whatever else is your favourite.

Hi All,
An update to the beta has just been made available which we are expecting to be the build we release publicly very soon! This means you can update your beta version to be the same code as what we will be our initial public release of 2.1.
We will therefore now have a period where the latest beta version is the same as the release version. That will remain the case until we begin a fresh beta which will either be a patch to 2.1 if we feel it's needed, or hopefully moving straight to the first beta of 2.2. At that point you will be able to update the beta versions you currently have installed for that latest update to test. 
During the period that 2.1.0.1799 is in sync with the release build (when 2.1 is made public) it's up to you if you want to continue to report any bugs in the beta forums or the main bug reporting forums.
I want to take this opportunity to thank you all so much for being so actively involved with the testing of 2.1 - along with all the new features and improvements we have got through a huge number of fixes, and that's only been possible with having so many of you putting it through it's paces. It's made a huge difference, and we're very much looking forward to working with you all on the next beta!
All the best,
Ash

I think the most important thing is that the scripting works in the first place. Whether the language used for it satisfies the aesthetic demands of all users is secondary. JavaScript may not be a particularly attractive language for purists, but in the end, all that matters is that I, as a user, can tell the Affinity apps what to do, and they will do it. Everything else is an ivory tower discussion in my eyes. At least for the tasks that I expect a scripted graphic & photo design software to do. For other projects this discussion about the quality of programming languages may make sense.

Hi All,
Excited to say this week's build is what we consider to be our first release candidate for 2.1. This means we are now at a stage where we are avoiding making any significant changes the code before release (unless we find some critical issue which must be fixed of course).
Fixes since the last beta build are in this post.
Thanks,
Ash
 

This is the approach we are taking. In our world, scripts are just interpreted plugins, with the exact same capabilities as compiled plugins. 

Smooth curve doen't really reduce the anchor points. It just changes their order to make the stroke look smoother. In some parts the number of points is reduced, while new points are generated at other places.
Simplify does something different. It really reduces the number of points. If you go extreme with it, you are left with 2 points (depending on the software you use).

The advantages of JavaScript far outweigh any advantages of Python, IMNSHO, for anything to do with creativity and user empowerment extensions of an engine/core written in C/C++.
It's easy to think of JavaScript as a "lite" and dynamic C with objects/prototypes as an added means of wrapping, and dot notation for access, and go from there.
Further, any programmer able to make something significant with Python will be able to do the same thing in JavaScript, or Lua, Wren, or MaxScript or any other scripting language, as scripting languages are no longer the barriers to production. With the possible exception of Apple Script, which is a wholly different beast able to turn sane men mad.
Similarly, any skilled vector artist can produce with Illustrator, CorelDraw, Freehand, Designer etc. They might not like the workflow as much in some of them, but minus the need for a Blend tool, they can do their vector works in any of these.
However, the processes of making a binding between an evolving program (and Affinity products are definitely evolving) and a scripting language needs (for best rates of production and freedoms of evolvement) a stable, specific scripting language choice for optimal flexibility so the tail doesn't wag the dog.
Any attempt to be a truly agnostic creative engine for all scripting languages will heavily wag the dog and quickly begin curtailing and/or slowing the evolvement of the underlying software, despite the fact that scripting empowerment of a user base rarely leads to significant general buying of the software.
The provision of plugin development in native languages, however, is a whole other thing, and also should not be at all curtailed or limited by scripting language choice, and especially not by a choice to try to be generically and generally extensible by all/any scripting languages. Plugins are a long game, though, and might be over for most creative software, now that we have "AI" that's soon going to be able to control other software. 
 

Hello @v_kyr,
You are getting slightly unreasonable here. The team has stated, in numerous posts, that because the APIs are going to be the same for both C and JavaScript that they will keep the documentation in one place. There will be a lot of people for whom JavaScript will be the most important part and they will not regard this as garbage. They will concentrate on the JavaScript part and you can concentrate on the C based APIs. And they lived happily ever after. 🙂

As I said last week: we aren't ruling out built-in support other languages eventually, but we have no current plans to. 
However, any third-party "interpreter" plugins will have access to all the same capabilities as the built-in ones. 
 
 

Please only focus on one scripting language, so that it gets done, and done well. There's never been a case where the time spent making multiple scripting language support work hasn't significantly reduced the rate of production of the features that scripting support can provide, because being generic becomes too important. Theoretically good, but very limiting for a domain specific use of scripting.

That may or may not be a legitimate request. I personally hate the Mac way to have no application frames and the ability to see other app palettes or windows behind the app in front and was really glad about Adobe introducing the application frames. But if it would be optional, I would have no problem with this.
I'm sorry to take your request here as a reason for another topic, but it is another example of this, that the tone here on the forum lately leaves a lot to be desired. At least a "please" would not have hurt the desire. "Give me back" reads like it was yours before and Serif stole it from you.
A great many users here are very demanding and formulate their criticism in a way as if Serif had personally insulted them with the appearance of V2.

The abbility to UNDO by tapping with two fingers and REDO by tapping with three fingers on Windows Devices (like Surface Tablets) would also be very nice.
For now the history studio is the only way to do this without a keyboard.