Avoid problems with renumbering pages starting with v.3.5x

[robertskiba]

Hi guys,

with the upcoming 3.5 version, it will be a matter of a short drag&drop to renumber the pages and possibly destroy a whole logic if someone is using things like button press/release where pages are addressed.

I suggest to implement two diffent things to create an option to avoid that:

• instead of addressing a page number, it could be made possible to use the name of the page (before: 1/1/0 - after: Mainpage/1/0). There could be some enumeration in the system to look for the first page with the name 'Mainpage' and translate it to the correct page. This would keep the 'Mainpage' in the example safe to address, even if it is moved somewhere else.

• Another option could be to automatically rename all page addressings (1/1/0 would be automatically detected in a command and converted to the new page like 5/1/0). But I guess, the first idea maybe easier and more reliable to implement.

[thedist]

This discussion is a little late in the development cycle of 3.5.0, but here are my thoughts:

instead of addressing a page number, it could be made possible to use the name of the page (before: 1/1/0 - after: Mainpage/1/0). There could be some enumeration in the system to look for the first page with the name 'Mainpage' and translate it to the correct page. This would keep the 'Mainpage' in the example safe to address, even if it is moved somewhere else.

I'm not particularly a fan of using Page Name as a reference for things like changing page on a surface when a name is not globally unique. Also what if Page 5 was named '4'? Should a button that changes a surface to page 4 change to the actual page 4, or the page named 4 even if it's index 5?

Another option could be to automatically rename all page addressings (1/1/0 would be automatically detected in a command and converted to the new page like 5/1/0). But I guess, the first idea maybe easier and more reliable to implement.

Manipulating what a user has set may be just as problematic as what if the user references pages by index, and wants to manipulate that index by inserting/deleting a page to offset all of their references one way or another then by Companion automatically adjusting page references (which in itself is complicated when you consider some references could be variables, some could be utilized in expressions, etc...) then you're causing problems in another way.

[Julusian]

I agree with all this.

I think the action to be able to reference by some identifier other than number is the way to go though. But to solidify the parsing it will probably need to be the page portion of 1/2/3 gets split out to its own input field. That allows us to avoid any ambiguity in what page/4/1/2/3 and other weird values mean.

The question I have is whether it should reference by name, or some other identifier. Each page has an internal id (random string of characters), which we could use that as the reference (although that isn't particularly friendly). Or add a new name like concept where the user can specify 'ids'/aliases/tags/labels/something. The benefit here is that they could be semi-technical and not the content/descriptive names that exist today.

Whatever we choose to do here for these actions will likely also end up being used in the http and other apis so that the same result can be achieved from externally. There are a couple of issues #2138 #1676 asking to having some kind of location agnostic identifiers for buttons in the apis. It would be nice to have one approach that can be applied to both cases