Scripting

[CM0]

4 hours ago, Tim France said:

The team has been making good progress. I don't have any updates on a release date but please be assured we are not sitting on our haunches

I sincerely appreciate the time to just drop a small comment here and let us know a bit how things are going.

[Daniel77]

Appreciate the work. Just to let you know that my ability to use Affinity Publishing is "do or die" based on Scripting.

I need to be able to

1 - swap the same master page into 100+ documents at once
2 - save "text version" of 100+ documents at once
3 - save "html version" of 100+ documents at once
4 - generate PDFs of 100+ documents at once

This will allow me to drop InDesign.

Speaking of which, it seems that "save as text" and "save as html" are currently not available? Therefore, that is a feature request, as well.

Otherwise, I am still bound to InDesign (which I don't want to be).

Thanks!

Edited November 19, 2023 by Daniel77

[Frozen Death Knight]

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?

[Affinityconfusesme]

@Frozen Death Knight We may have to wait a while for scripting to come to beta and then we will have more info about the controls for them. Hopefully we will know soon in what version it will become available. 

[fde101]

On 11/18/2023 at 10:16 PM, Daniel77 said:

"save as text"

How would that work?  Do you just mean to export an individual story?

 

On 11/18/2023 at 10:16 PM, Daniel77 said:

"save as html"

From a DTP perspective HTML is essentially an eBook/ePub format, which has already been requested in other threads, such as:

 

Alternatively HTML could be a simple rich text format for exporting an individual story, which would be a different feature request from what people are usually asking for.

 

Either way, this is not the correct place for this - the thread this was posted in is about scripting.  If you are looking for the ePub style export of HTML, you should add your support in an existing thread for that.  If you are looking for a story export, there may be an existing thread requesting that but I am not turning one up in my initial attempt at searching.  If you meant something else by a text format export, I have no idea what that would be, but I would suggest searching for an existing thread and creating one if you can't find it, giving a bit more detailed of an explanation of exactly what you want from it.

[Slof]

Scripting would be very welcome. Scripting Summa OPOS-marks to a design to print and cut without Adobe or Corel software please?

[kirk23]

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.

[Affinityconfusesme]

I hope that this will make it into version 2 by September of this year.

[PaulEC]

51 minutes ago, tzvi20 said:

I hope that this will make it into version 2 by September of this year.

Why - what’s happening in September?

[Affinityconfusesme]

I am going away and then I won't really have access to affinity for a long while. I want to be able to try out scripting once before then being that there is no release date or cycle yet.

[Petar Petrenko]

7 hours ago, tzvi20 said:

I am going away and then I won't really have access to affinity for a long while. I want to be able to try out scripting once before then being that there is no release date or cycle yet.

Have a nice trip.

AFAIK scripting will appear after v. 4.0 and it is about 2+ years

[Petar Petrenko]

@tzvi20 You can be confused as much as you like, but it is not up to me.

[walt.farrell]

On 1/10/2024 at 5:08 AM, Petar Petrenko said:

AFAIK scripting will appear after v. 4.0 and it is about 2+ years

And what do you base that on, given that it is one of the few items that Serif have actually said they're working on, and provided a demo of some working code?

[Affinityconfusesme]

@Petar Petrenko Your comment confused me because Tim France's last comment implied that they want to get it out as it's ready. It does seem like they are pretty close to that point.

[Petar Petrenko]

21 minutes ago, walt.farrell said:

And what do you base that on, given that it is one of the few items that Serif have actually said they're working on, and provided a demo of some working code?

On some earlie Affinity's answers on the topic when they announceed it.

[v_kyr]

11 minutes ago, tzvi20 said:

...that they want to get it out as it's ready. It does seem like they are pretty close to that point.

And what do you base that on? Just on that last statement from Tim?

That just indicates that the whole is still in progress & in development state, so some more things do work now and have been in a state to be internally reused for certain tasks and tests. But it doesn't tell you how complete the C/C++ API interface and JS scripting engine is at all now, or when the whole is in a state to be released at all.

Further there is also much more than the coding things only named so far to do, namely the whole user & usage documentation of available API & JS functions (aka a concept overview, function list overviews, function explanations, various examples ...). - For developers the later said/named things here (writing the docus & user guides ...) takes in contrast to writing prog code usually more time to build & set them up in a manner, understandable and usable for end users at all.

[Tim France]

49 minutes ago, v_kyr said:

namely the whole user & usage documentation of available API & JS functions (aka a concept overview, function list overviews, function explanations, various examples ...

This.

The scripting devs are going to have to dedicate a significant amount of time towards documentation. We can't expect our docs team to document the ins and outs of an API (technically multiple APIs), it's simply not fair or realistic. Besides, we'd have to tell them what to write, which would mean pretty much writing the documentation anyway. Sure, they'll be able to present it in a way that looks good and integrated with the normal app documentation, but the devs are going to have to provide much of the content.

We're planning to use one of the many available documentation tools to do most of actual generation for us. The current favourite is Doxygen, largely because most of us have had at least some exposure to it.

Please remember too that the scripting team sometimes has to do bits of work away from scripting development. As the dev who wrote the DWG/DXF importer (and now exporter - see here 🙂), I tend to be the one tasked with its fixes and improvements. The same goes for Move and Shape Data Entry. Everyone in dev could put in those fixes, but it makes so much more sense if I do them because I'm most familiar with the code and should be able to do the work faster. The members of the scripting team do spend most of their time doing scripting work, but it's not 100%.

[Affinityconfusesme]

@Tim France Thanks for letting us know how things are progressing. These comments are more than appreciated.🙂

[v_kyr]

37 minutes ago, Tim France said:

The scripting devs are going to have to dedicate a significant amount of time towards documentation. We can't expect our docs team to document the ins and outs of an API (technically multiple APIs), it's simply not fair or realistic. Besides, we'd have to tell them what to write, which would mean pretty much writing the documentation anyway. Sure, they'll be able to present it in a way that looks good and integrated with the normal app documentation, but the devs are going to have to provide much of the content.

Exactly as I thought things will be, as it's always also the same for me here (although in/for other IT areas than graphics) and the dev projects I'm involved in. Or the other way said, from my own long time experiences as a dev I usually somehow know how the rabbit runs here. - Maybe no need to emphasize this, but as devs we usually like more to code than to overall write docs. But hey that's the way of cookie crumbles, somebody has to do the job and that's mostly the API inventors/implementers, as they know best how things have been implemented and how they do work.

37 minutes ago, Tim France said:

Please remember too that the scripting team sometimes has to do bits of work away from scripting development. As the dev who wrote the DWG/DXF importer (and now exporter - see here 🙂), I tend to be the one tasked with its fixes and improvements. The same goes for Move and Shape Data Entry. Everyone in dev could put in those fixes, but it makes so much more sense if I do them because I'm most familiar with the code and should be able to do the work faster. The members of the scripting team do spend most of their time doing scripting work, but it's not 100%.

That's also common usage in my domain, so even you are already working on certain longer time taking tickets, there's then mostly/always some other more urgently one pushing into the todo stack, which then has a higher importance/priority to be more urgently fixed (or to be implemented). So the overall processing sequence importance of to be worked on tickets will be reordered. - As said, it's a well known handling in many dev areas and you are all not alone here, I can sing a song about it too in my domain.

[CM0]

26 minutes ago, v_kyr said:

That's also common usage in my domain, so even you are already working on certain longer time taking tickets, there's then mostly/always some other more urgently one pushing into the todo stack, which then has a higher importance/priority to be more urgently fixed (or to be implemented). So the overall processing sequence importance of to be worked on tickets will be reordered. - As said, it's a well known handling in many dev areas and you are all not alone here, I can sing a song about it too in my domain.

I worked under that model for many years in the past as well. It was constant painful frustration. Fortunately we finally moved to having feature teams that were off limits to other tasks. Productivity was much better without constant interruptions.

[kimtorch]

1 hour ago, Tim France said:

Please remember too that the scripting team sometimes has to do bits of work away from scripting development. As the dev who wrote the DWG/DXF importer (and now exporter

Speaking of import/export, is there any news on whether there will be some form of text tags for scripting formatted text?

[Peter Kahrel]

@Tim France

Many thanks for the progress report.

> Naturally we've been exposing more of the apps' functionality to scripts

I hope the ultimate aim is to expose all the app's functionality to scripting. Can you say anything about that?

When you expose only part of the app's functionality you have to make a choice -- you'll always get it wrong.

 

[Petar Petrenko]

@Peter Kahrel if you are the author of "GREP in InDesign" I must say thank you for the great book.

[Peter Kahrel]

> I must say thank you for the great book.

Glad to hear it!

[Seneca]

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.