chessboard

I assume that chatGPT generates Blender scripts quite well because there are many references on the web that chatgpt has "learned" from, due to the open source nature of Blender and therefore a large number of users who know how to script and share their scripts on the web.
Similar knowledge cannot be expected for affintiy scripts, as chatGPT does not learn to script. It does not "know" anything about scripting logic and scripting languages, nor does it understand how to read API documentation and combine this information with knowledge of the rules of a particular scripting language. It simply can't think. Instead, it simply collects scripts that others with knowledge of the scripting language have already written and can combine them into new scripts. This works all the better the more often the tasks set have already been solved and published on the web. If you ask chatGPT to create a script for a very specific and unique purpose, it is more likely to fail.
Scripting in Affinity will be so new that chatGPT will not immediately find enough scripting input. If scripting in Affinity becomes popular, the later versions of chatGPT will probably also be able to generate scripts for the Affinty applications. It is not a question of which scripting language is used. There just needs to be enough sample material available.

ChatGPT 4  
Affinity Photo is going to support java script soon . Do you think you would be proficient with making scripts for Affinity Photo or it would require a whole new training and unlikely?  
ChatGPT The introduction of JavaScript support in Affinity Photo is an interesting development. As a language model trained by OpenAI, I am proficient in JavaScript and have a strong understanding of programming concepts, which would be directly applicable to creating scripts for Affinity Photo, assuming its JavaScript implementation follows standard practices.
Affinity Photo likely has its own specific application programming interface (API), which means that while the core JavaScript language would be the same, the specific functions, methods, and processes to interact with Affinity Photo's features might be unique to that software. Learning these specifics would be necessary to create effective scripts for Affinity Photo. This would involve understanding how the API allows a script to interact with the software's features, such as image manipulation, layer management, and other photographic or graphical editing capabilities.
The process would be similar to learning any new API or software library: understanding the documentation, experimenting with basic examples, and gradually building more complex scripts. Given my existing programming knowledge and ability to learn from written materials, adapting to create scripts for Affinity Photo would be feasible. However, since I cannot execute or test scripts in real-time environments, I would primarily be able to offer guidance, pseudocode, or untested script examples based on the provided documentation and API references.
 

I assume that chatGPT generates Blender scripts quite well because there are many references on the web that chatgpt has "learned" from, due to the open source nature of Blender and therefore a large number of users who know how to script and share their scripts on the web.
Similar knowledge cannot be expected for affintiy scripts, as chatGPT does not learn to script. It does not "know" anything about scripting logic and scripting languages, nor does it understand how to read API documentation and combine this information with knowledge of the rules of a particular scripting language. It simply can't think. Instead, it simply collects scripts that others with knowledge of the scripting language have already written and can combine them into new scripts. This works all the better the more often the tasks set have already been solved and published on the web. If you ask chatGPT to create a script for a very specific and unique purpose, it is more likely to fail.
Scripting in Affinity will be so new that chatGPT will not immediately find enough scripting input. If scripting in Affinity becomes popular, the later versions of chatGPT will probably also be able to generate scripts for the Affinty applications. It is not a question of which scripting language is used. There just needs to be enough sample material available.

I assume that chatGPT generates Blender scripts quite well because there are many references on the web that chatgpt has "learned" from, due to the open source nature of Blender and therefore a large number of users who know how to script and share their scripts on the web.
Similar knowledge cannot be expected for affintiy scripts, as chatGPT does not learn to script. It does not "know" anything about scripting logic and scripting languages, nor does it understand how to read API documentation and combine this information with knowledge of the rules of a particular scripting language. It simply can't think. Instead, it simply collects scripts that others with knowledge of the scripting language have already written and can combine them into new scripts. This works all the better the more often the tasks set have already been solved and published on the web. If you ask chatGPT to create a script for a very specific and unique purpose, it is more likely to fail.
Scripting in Affinity will be so new that chatGPT will not immediately find enough scripting input. If scripting in Affinity becomes popular, the later versions of chatGPT will probably also be able to generate scripts for the Affinty applications. It is not a question of which scripting language is used. There just needs to be enough sample material available.

Did you read the line:
Both Jon and Tim are part of the scripting development team, not the publisher development team. They develop the scripting feature for all three applications: Designer, Photo and Publisher. I find it quite understandable that they are specialists in their field and not for photographic, design, illustration and publishing software issues.

Did you read the line:
Both Jon and Tim are part of the scripting development team, not the publisher development team. They develop the scripting feature for all three applications: Designer, Photo and Publisher. I find it quite understandable that they are specialists in their field and not for photographic, design, illustration and publishing software issues.

Hi @kimtorch.
We are doing our best to engage with our users and understand their requirements.  
Our primary focus is to expose existing application features to scripts/plugins; text support is just one part of this. We are software developers, not publishers, and although we often liaise with the Publisher team regarding text matters, they are not really scripting experts. So you might have to explain some things that may seem obvious to you. 
We are aware of InDesign text tags: as I understand it, they are primarily used to map to text styles on import.
What we're trying to understand, and I hope you can explain, is how this relates to scripting. I would guess that perhaps you envisage a script which would run as a tagged text import filter, overriding the tag -> style mapping which would normally be set up manually in the app?

Documentation and all the rest that goes with it is very important upon the release of the product. 
However, there is value in including this functionality early in the beta cycles of the product(s). Even if the scripting is not ready and missing a lot of functionality. It doesn't have to be part of major point releases until it's actually release worthy.
Those of us who would love to experiment with it early would send an invaluable feedback to the devs, which in my opinion is as important as the release itself. And those who love living on the edge would start using it early in live projects and learn what works what what doesn't.

Question to the devs, will it be possible to have custom keybinds for whatever script is being created through this new system, or will that be something happening later down the line?

Apps: All
Platforms: macOS, Windows and iPad
Previously when you cycled your selection box this was only a temporary operation. You can now make this permanent...
From the select menu there are two options:
- Cycle selection box (this was the existing option)
- Set selection box (the new option)

Also note the shortcut for these - [Full Stop] to cycle and [CMD + Full Stop] to set on macOS and iPad or [Ctrl + Full Stop] to set on Windows.
The new feature is that after cycling to the selection box you want you can now permanently set that for your current selection by using the Set Selection Box command.
In the example below, I have two shapes which are rotated by the same amount. Therefore when they are selected by default the selection box is oriented to match the shape's rotation. Now if I want to permanently make those shapes have a selection box which is oriented to my page I can cycle to regular bounds and then Set Selection Box, which will now make that persist every time I select those items in future.

 
A couple of other notes on this feature:
As well as cycling to the base box and regular bounds of an object, if you have a grid set which has a different rotation to your page (or, are working on an isometric plane for example) you will additionally get the option to cycle and set the selection box to be aligned with the the current planar bounds of the selection. If you have a multiple selection which includes objects rotated by different amounts, if you wish to set your selection box for all objects in your selection to match the orientation of one of them you can set the one you want to match to be your key object. Then when you cycle your selection box the "base box" option will match that object's rotation.  
 

Apps: Designer and Publisher (+ some changes to the existing feature in Photo)
Platforms: Windows and macOS
We have now added the States panel to Affinity Designer and Affinity Publisher which previously only existed in Affinity Photo. Layer states allows you to either:
Capture the current visibility states of your layers across your document Create queries based on various criteria to use to make a selection or toggle visibility of layers This feature is particularly useful to manage different variations of your work. As an example, one of the social ad campaigns for our recent Black Friday promotion was created in Affinity Designer across multiple artboards. Each artboard had 4 variants for English, Japanese, German and French language.

 
Previously if you wanted to toggle between the English and French version for example you would need to toggle the visibility of the appropriate layers on each artboard separately - not particularly workable when you have many artboards / spreads. The new states panel gives you a new way to work with designs like this. 

In this case I could set up a query with criteria which captures all my Japanese layers. From the states panel click "New Query" at the bottom, I called the query "JA" and set up my criteria to be "All Art Text and Frame Text layers that have a layer name which ends in JA" as below:


Because on each artboard we had used the consistent naming convention that all Japanese text has a layer name ending in JA, all English text has a layer name ending in EN, etc. it made it easy to then set up 4 queries for each of the languages. We could alternatively have used a convention like all French variants are tagged yellow, English tagged Red, etc. 
So now to switch from English to Japanese across all artboards I can just turn off everything that fulfils my EN query, and turn on everything which fulfils my JP query using the visibility on/off buttons next to the queries in the states panel - so in two clicks end up with the below:

 
While this example is only including text, of course I may have had different imagery for each locale and could have included those in the same queries to still have one button to toggle text and images of each language on and off. Also, as it's set up a query like this, should I add additional Japanese specific layers to any of the artboards and name them ending in "...JA" my JA query will automatically pick them up.
In Publisher the same principles apply giving the ability to globally toggle different layers on and off across all spreads in your document which match the criteria you have specified. While building complex expressions is easy, you may also find you wish to have a query for something simple like "Layer Type is Images" giving you an instant way to turn all images on and off across your whole document.
Additional Notes
As well as toggling visibility of queries there is an additional button to make a selection of all layers which fulfil the criteria specified in the query. This is also a new function not previously available in Affinity Photo. For those who used the States panel in Affinity Photo you will notice we have changed the name of what were previously called "Smart States" to "Queries". This reason for this is in the future we anticipate adding a new feature to this which would be better described as a Smart State (this will be something you can build from multiple queries). This will be something which we add in a future update. There is other new functionality we plan to bring to this in the future - namely ability to create presets and some level of integration with export options - but again that will be something for a future update.
 

It's going to be javascript  right?     Wish it would rather be Python . ChatGPT seems so much more proficient with Python  while it took hours if not days to make it write you a working javascript for Photoshop.
 
We need scripting system that works  with ChatGPT nowadays  please.     With Affinity apps I am afraid it would be like persuading it to write you a script for 3d max  vs Blender   where ChatGPT instantly shines.

It locks some functions. But not others.

When a company like Serif deliberately provides customers with such unconventional (and unpopular) functionality for years, it would only be good practice to offer a traditional one via global preferences or in layer panel preferences. Not per document though.
I would venture to say that I would strongly recommend that the traditional method is the default, and I can't imagine customers rush to switch to the untraditional one. But then Serif's advocates could sit in Nottingham and repeat in whispers "We haven't removed our method. We have not removed our method." in a rocking chair.

There are a few (very few) situations where the current Lock behaviour* would be useful. But a far far better use of locking a layer would be to not allow me to change anything about it. 
 
* Locking the location only.

I would suggest to exend this feature request so that there should be a general Find-replace function, by which one could exchange any kind of object/groupe/symbol by another one. So that, for example, you could replace all blue elipses with yellow stars, but just for artboard "A" and no other artboards.
The "Select all" functionality is still there. What's missing is a general replacement feature. There are still many loose ends of this kind that Serif can pick up and tie up further.

I would bump the idea for a double click to delete a node. It's keyboard free, works great in Corel Draw, there is no function assigned to a double click on a node, and it's unlikely to be a gesture people would do by mistake. Win win win win. 
 

Can we please keep this thread for discussions about the Delete node feature? 

Blender Implements the Pie option very successfuly and it has many options, basically you move the mouse in only 1 direction, no need to scroll down.
regard the mouse movement, from my experience, it doesn't take you too much efforts.
by the way, affinity iPad offer this option 

Grumpy grandad in:
First; I love Affinity's apps. I'm a total evangelist and convinced a lot of customers and colleagues to purchase it. I have been a "Affinitier" since 2015 and I won't go back. So please, don't take this as a free light ranting.
I'm tired. I'm frustrated. Because of tables. And I have been this way since Publisher came out. I can't understand by Affinity decided to make tables as a separate monolithic object only.
Why, in the name of the design gods, they decided to make it like something outside of the text (Something that even the cheapest, crappiest text editor app understand).
Why, in the name of the design hell's lord they decided that tables can't spread through text containers, columns and pages.
Why, in the name of sanity, can't we set a fixed width to a table, or set fixed width to a column, or block the width to prevent Publisher resizing them whenever I move any other single column, making a nightmare to set the table layout.
I'm tired. This is the single cause of friction and discussion inside out studio team. This is the cause of delays and multiple errors on our work. It is the cause that we have started to make tables in a larger document apart so we can work with big tables before segmenting them to be placed into the final layout. This is why we fear to add or move any design element, because the hideous tables will no spread or move correctly in the documents breaking all the text workflow. This is why we fear to modify a table layout, because we will have to do it on all the segments of the table.
Our last work toke 4 extra hours just because of the tables. Because of the need to segment it and re-layout it after any document modification. And that's 4 hours I can't pass onto the customer because is not their fault.
In 2019, Affinity recognized that this was a very requested feature. Now we are in 2023, and that forum post is deep under into the vault of the lost threads. But we still have to design tables with virtual scissors and glue.
Publisher v2 has been a great improvement on a lot of things, but this table thing is outrageous, and just now, in the middle of a urgent complex corporate document full of tables, it is wat is making us to be working on Sunday instead of walking the dog in the countryside.
I don't know what more to say. I wish Affinity to tell us something more that "we know it is requested we will look into it, someday"
For all the love that I have to the team, I hate tables in Affinity. And I hate to be inside the studio trying to make tables to work on Sunday.
Grumpy grandad out.

From the help:

Thanks everyone for all your suggestions - please keep them coming! They are all useful. 
Initially, we'll be concentrating on exposing existing functionality - primarily, manipulation of documents and their contents. 
Then later we will be able to move on to some of the "new feature" things that have been suggested: custom tools / shapes / brush engines / personas etc. 

If someone in the Scripting development team at Affinity could answer me this, it would be great.
In other applications I use, that allow for scripting (mainly, Cinema 4D and VizRT), besides being able to create scripts that can be executed from a menu listing (Cinema 4D, only), I can also attach a kind of a "tag" to an object that runs scripting code in real time, whenever the scene/document is changed/refreshed.
That way, I can perform scripting operations on the object that the "tag" is attached and also on its children.
Will Affinity scripting abilities only allow for scripts that can be invoked from a menu or will we have a new type of "tag" to attach to our "layers/objects" that can allow us to add abilities/behaviours to any "layer/object"?
Something like my mockup...
 

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.

We currently have no plans to allow customisation of existing tool behaviour. 
However, your wish could be easily realised by a script which performs the Expand Stroke command in response to a notional "object created" notification.