Rename groups - batch processing

[Milos Micatek]

Hello.

I am working on comic book lettering and using Groups to prepare the balloons for future slicing to PNG format (they are inputs for comic book composer we are developing). I try to keep it clean and organized by using simple naming code "LANGUAGE platform ###" e.g CZE mobil 001, CZE mobil 002, etc. Sometimes I need to split the ballon and/or add new one which messing up the order.

I usually put there an extra letter (001a, 001b...) but I would prefer to keep numbers only.

Is there any chance to rename all groups in 1 step by defining syntax I described above?

I found the batch renaming for Slices is not possible but what about the Groups, Layers...?

[Gabe]

Hi @Milos Micatek,

Unfortunately, you cannot batch rename. The rename function we have got works on an individual basis. 

Thanks,

Gabe. 

[v_kyr]

@Milos MicatekHmm, if those drawings do export & (re)import correctly to SVG (?) you can try to rework and apply the whole on a text editing basis via scripting etc. instead, since SVG is wholly text based. - Meaning here concrete that all setup layer group names have associated IDs like ...

...
<g id="CZE-mobil-002" serif:id="CZE mobil 002">
...
<g id="CZE-mobil-001" serif:id="CZE mobil 001">
...

... which you can parse for through the whole file. It's basically nothing more as setting up a counter (counting either up or down for those ID occurrences, a number increment/decrement) combined with a find/replace then for the number part of an ID (the layer naming number portion).

[Milos Micatek]

@v_kyr I am not very familiar with scripting language. Anyway the inputs for Nanits composer are PNG files, the balloons and text with transparent background.

Yes, I can rename those files later but my question was if there is an implemented batch renaming functionality which obviously is not (thanks @GabrielM for your answer). Maybe it should be added to requested features... 

 

[v_kyr]

Well this batch renaming of layers is more or less an individual organization demand feature (in your special case here) and I don't know if other users also might have a demand for this. Meaning here, it makes only sense to implement such a feature at all, if a bunch of people have a need for these things.

[X-Raym]

@v_kyr This is precisely why scripting API is deeply needed : to let all users solve their own specific issue in an efficient way.

That said, simple search / replace + counter feature is more than a specific user request.

[v_kyr]

1 hour ago, X-Raym said:

@v_kyr This is precisely why scripting API is deeply needed : to let all users solve their own specific issue in an efficient way.

That said, simple search / replace + counter feature is more than a specific user request.

Basically yes a scripting API would be fine to have, but I fear they would then miss to implement a bunch of important functions in an initial scripting API too, like for the actual APh "macros" implementation.

[X-Raym]

@v_kyr Yes, that would be a bummer,

Though even with extra basic things (like layer name/position/rotation/scale Get/Set if would already offer a tons of services. Really, a ton !)

[v_kyr]

Yes, combined with the usual elements of a scripting language (data types, operators, objects, if-else-loop statements ... etc.)  one could write then own custom functions for certain image/drawing generating and handling aspects.

[R C-R]

12 hours ago, v_kyr said:

Yes, combined with the usual elements of a scripting language (data types, operators, objects, if-else-loop statements ... etc.)  one could write then own custom functions for certain image/drawing generating and handling aspects.

That would be great but I suspect the core Affinity code would need major work to be able to support a scripting language. Maybe we will see that in version 2?

[X-Raym]

@R C-R Glad you also find it useful ! With enough feedbacks maybe it could be accepted ?

I don't need it would need any deep code refactoring. Internally, all the functions (getting layer name, setting layer names, getting item pos etc...) already exists. It is not as if they would have to develop a new graphic engine etc... It is basic Affinity files functions.

They just need to exposed these functions to other softwares via the API.

[R C-R]

1 hour ago, X-Raym said:

They just need to exposed these functions to other softwares via the API.

I think there is probably much more to it than that. As far back as 2014 or 2015 there were some requests for an Affinity SDK & various suggestions for several kinds of scripting language support. The gist of the staff replies were that they were considering ways of doing that but there is a lot of proprietary code they do not want to expose in an SDK, & that there were other only hinted at reasons that would require major code rewrites to support the kind of object oriented scripting support most often requested.

I think what it amounts to is mostly that the apps were built from the ground up for a GUI so there is much less built-in support for a CLI than we might expect, but that is just a guess.

[X-Raym]

@R C-R I don't understand their answer at that time then, SDK doesn't have reveal any code, it is not like open sourcing, it is just bringing some functions to users but without access under the hood. It d'oesn't even have to be object oriented.

Sure it is surely way more complex than we can imagine. But also... not impossible... and deeply wanted by users

[R C-R]

In my admittedly limited experience with SDK's they do often reveal a lot about the underlying structures & commands of the code, if not the code itself. It may be necessary to read between the lines to find it, but sometimes what is not there is just as revealing as what is.  

Also, I am not sure how useful it would be for a graphics app that is designed around a GUI front end not to offer back end access to graphic objects for commands to operate on. For example, how could you enumerate the layers in the Layers panel to get or set any of their properties if they are not accessible as objects?

[X-Raym]

@R C-RI use an audio software called REAPER for which I coded hundreds of scripts.
I can assure that API doesn't need to reveal anything from the app source code. API are just list of functions basically.

As it offers scripting in various language (Python, Lua, C++, EEL...), the choice what to not have any objects. So it only returns points, or value directly.
For EG, when you call an object, you get the object ID. And then you can pass this object object ID to a function get certain values about this object (like GetItemPosition() ). And you have Setter functions which allows to have and Object ID and the desired value (like SetItemPosition() ). There is also more generic function like  GetItemParamValue( item_id, param) for which you can specified lots of different param, but ultimately, there is no object involved.
It is still very efficient and easy to code.

But I guess this should have to be discussed in a dedicated API request thread

[Wosven]

You don't need the full code, but a comprehension of the object model if there's one and of the methods/functions you can use with the script language with their parameters to help you, for examples:

http://jongware.mit.edu/idcs6js/

https://www.indesignjs.de/extendscriptAPI/indesign-latest/#about.html

[R C-R]

3 hours ago, X-Raym said:

For EG, when you call an object, you get the object ID. And then you can pass this object object ID to a function get certain values about this object (like GetItemPosition() ). And you have Setter functions which allows to have and Object ID and the desired value (like SetItemPosition() ). There is also more generic function like  GetItemParamValue( item_id, param) for which you can specified lots of different param, but ultimately, there is no object involved.

??? 

[X-Raym]

@R C-R Sorry a bit of confusion in my explanations, between "code" object and "project object" (shapes in Affinity Designer, Item in Reaper :P).

I was referring to what is called "item" on reaper project timelines, apart on my last sentence. But these are not code objects (they don't have methods, constructor etc), they are just like ID pointers.

I'm all about talking about scripting but this may be out of scope of this particular thread (as we don't have scripting)

[v_kyr]

Well there are generally always several different approaches possible to implement some sort of scripting (language) support. - One common widely used approach (as is also often seen for adapting APIs to certain other languages) is using wrappers, where say language B wraps the main language A code calls/functions. Let's say Python code wraps Affinity C/C++ objects and functions. Another approach is instead using  lexers and parser generators (lex/yacc and similar tools etc., so to create scanners for the lexical analysis of specific language source texts and a parser generator), which then together are used to form an complete interpreter or corresponding adapter based translator part. - In other words there are (as often) different technics and approaches possible to implement these things.

[X-Raym]

@v_kyr The first method is more efficient, but any method will be better than none

[R C-R]

4 hours ago, v_kyr said:

One common widely used approach (as is also often seen for adapting APIs to certain other languages) ...

So if there is no application level API, how does that work?

[v_kyr]

8 hours ago, R C-R said:

So if there is no application level API, how does that work?

An API was just used as an wrapping usage scenario example, so where wrapping is often used. You can build an object package structure (interface) where you wrap/embbed and map all the needed object creation and method/calls etc. There are also several well defined design patterns which can be used for such purposes.

[R C-R]

29 minutes ago, v_kyr said:

An API was just used as an wrapping usage scenario example, so where wrapping is often used. You can build an object package structure (interface) where you wrap/embbed and map all the needed object creation and method/calls etc. There are also several well defined design patterns which can be used for such purposes.

The thing about this is I keep seeing the word "object" appearing in every comment, so one way or another if the app does not expose objects to the scripting language, the whole thing kinda falls apart, or at least becomes very difficult to use.

It also seems to me that a well defined class structure is a necessity, ideally one that explicitly defines what methods/calls can be used with the various object classes. Running compiled scripts should not overly tax memory so excessive paging won't slow them down; somehow must deal with not all of a document's data always being loaded at the same time; know what to do with mipmaps; & so on.

Basically, all I am saying is we do not know enough to say how much work it would take for the Affinity apps to support a useful scripting language.

[v_kyr]

38 minutes ago, R C-R said:

The thing about this is I keep seeing the word "object" appearing in every comment, so one way or another if the app does not expose objects to the scripting language, the whole thing kinda falls apart, or at least becomes very difficult to use.

The term object and how used by several people in this thread can have different meanings and depends on the context they used that term. - From a programmers and OO programming language point of view here (that context) an object is clearly defined then as an at runtime created/build instance of a class definition. In OO one usually talks about classes which describe and define the attributes (fields) and behavior (methods) of objects etc.

55 minutes ago, R C-R said:

It also seems to me that a well defined class structure is a necessity, ideally one that explicitly defines what methods/calls can be used with the various object classes. Running compiled scripts should not overly tax memory so excessive paging won't slow them down; somehow must deal with not all of a document's data always being loaded at the same time; know what to do with mipmaps; & so on.

Since the Affinity Apps are written mainly in C++ they will have internally some OO oriented class structures, as for example abstract class Shape and then concrete classes rect, circle, triangle ... which do inherit the base attributes and methods from a shape (attributes/methods the all share) but can overwrite or extend the inherited capabilities of a plain shape dependent on what attribute/methods etc. those will additionally need.

For scripting you would need to have definitions for the most common needed things, similar to what menu entries, keyboard shortcuts etc. do initiate and are mapped to. You would need to be able to define/create or access/modify a document, it's canvas (the drawing area), layers, the graphics primitives ... etc. - Script compilation depends on the choosen language here, ideal would be some interpreter like language which supports both, an interactive mode and for performance reasons (for possible huge scripts) then some faster turn-around precompilation.

1 hour ago, R C-R said:

Basically, all I am saying is we do not know enough to say how much work it would take for the Affinity apps to support a useful scripting language.

Do you have to care about that? You are an end user (customer) and not a member of the dev team, so why do you always worry about those things? - In the IT-domain I work our software customers don't care about that, that's not their problem, they have some demands and do need several features and functionality and it is our part (the software edevs) to implement what the customers do need here. Ideally then in a way both sides are happy with, so to say in a gracefull working bugfree manner.

[X-Raym]

 @R C-R @R C-R

It is true that adding API is a lot of works. Though it will open the apps to news features and it audience and audience satisfication will increase widely.

Object based or not on the scripting side it doesnt matter that much. I script for software wich have each or the other API style and it is same difficulty level.

If you really want to speak about code, here are two exemple with proto-code (not actual code but coding style demo. I use Lua syntax as ref).

https://gist.github.com/X-Raym/8936e950ad4441208ace57845a373346

See how little difference it makes on script side.