I’ve built a few different varieties of TOX saving and externalizing tools over the past few years, and recently have revisited using the .dirty flag on COMPs. One sticking point here is that a COMP that contains another externalized COMP will be marked dirty if its external child contains changes.
Changing the op: /project1/base_some_component/base_some_child_comp1 marks this op as dirty, but also marks its external parent (/project1/base_some_component) as dirty.
When it comes to tracking changes / knowing when an operator needs to be re-saved this presents an ambiguous scenario. Ideally, I want one developer to be able to work in /project1/base_some_component/base_some_child_comp1 while another works in /project1/base_some_component/base_some_child_comp2. While each dev may have only made changes in their respective components, using .dirty to inspect components would lead them to believe that their component workspace and its parent are both dirty.
My current work-around is to build a hash table for all external ops at start, then rehash and compare when saving. This works reasonably well, but currently I only track operators and parameters… leaving op connections, position, color, etc as changes that aren’t currently supported.
That’s a passable band-aid, but not great in the long run.
The Ask
Change the .drity member (or add another) to reflect the status only of the contents of a COMP and it’s non-external children.
Bonus Ask
Include a dirty indicator when inside a component next to its external comp status:
This is particularly an issue in git when merging between branches. If I just save everything dirty all the way up I can hit a merge conflict when it isn’t actually an issue. Either I have to track each file that I touched or I have to accept merge conflicts as part of my workflow and do a side by side to confirm.
+1 for this or other similar solution for managing external tox changes. In our Tox Tools in The HQ PRO we used the dirty flag to mark in a UI which external components might need saving. We’ve had reports from macOS users that it can be finnicky on macOS specifically. Also sometimes it seems like sometimes on Windows it also doesn’t always feel rock solid. Improvements on the dirty flagging or another solution for better managing changed states of external toxes would be great. I think @dylanroscover would have some thoughts as well, as he’s built a few externalizer tools.
On the other hand, changing parameters does not mark them as dirty. This is, in general expected and good, but for example adding a custom-parameter should mark the component as dirty.
@raganmd really like the idea of hashing the component to check for a dirty-status.
Some kind of indication is def a welcome addition. Esp inside the component. I put in a little widget into the default UI to get a good glimpse of if something is dirty or not:
If we are on the topic of that, anyone knows what kind of timestamp the externalTimestamp is refferring too?
externalTimeStamp → Time(Read Only):
Time stamp of the external tox file when it was last saved or loaded.
Where did you find externalTimeStamp documented? I’m using it in my toxmanager but realized I have no idea where I found a reference to it. I can’t seem to find it anywhere on the wiki.
