"Modified" indicator "*" is unexpectedly still in title bar even when the project is no longer modified

[triska]

OS and Version (please complete the following information):

• Operating System: Debian Trixie
• Shotcut Version: shotcut-linux-x86_64-26.2.26.txz from the project download page

Describe the bug
The modified indicator is unexpectedly still in title bar even when every change is undone.

Steps To Reproduce

1. Start Shotcut and open any project.
2. Add a clip, or perform any other action that leads to a history entry.
3. Undo the action with Ctrl-z, or undo the action manually in any other way (for instance by removing the clip again).
4. The modification indicator * in the title bar is still shown, indicating that the project is modified even though all modifications are undone. Hence, we get the impression that changes are made to the project, even though the current state is the same as the last saved state.

Expected behavior

The * indicator should not be present when the current project state is identical to the last saved state, so that it can be reliably used to see that a previously modified project has returned to the last saved state.

For instance, the current state of the project could be compared with the last saved state. Hashing could be used to keep the space overhead tiny, this is how for example GNU Emacs implements this feature.

[bmatherly]

I propose to close this as "wontfix".

• It is a nitpick
• Our undo operations don't always leave the model in the exact state as before (maybe properties are in a different order, etc)
• I don't want to maintain and incur the additional cost of hashing the project data every time something changes

[triska]

Regarding these arguments: Would it be desirable also for other operations to maintain the project state in a canonical form, for instance for regression tests?

[bmatherly]

Would it be desirable also for other operations to maintain the project state in a canonical form, for instance for regression tests?

Of course. We would love automated regression tests. But we are just two dudes working on this in our spare time. I'm not saying "no" to the idea you propose. But I'm not volunteering to do it. I would love to review a PR for this, though. Maybe you could submit one?

[triska]

I'm not saying "no" to the idea you propose.

In the very first sentence of your response you proposed to close this as "wontfix". I'm not even two dudes but only one dude filing this issue in my spare time because I noticed it when working with this excellent program, so I filed it also to gauge how interested anyone is.

In another message I read @ddennedy is interested in adding unit tests, and if a canonical state representation helps with this, it would make also this issue easier. The overhead of hashing would in all likelihood be negligible, and if a canonical state representation is used then states may even be compared much more efficiently in other ways, so that any differences are even more readily detected. Maybe also other contributors may become interested in helping with this.