"Modified" indicator not visible

[Brad Brighton]

I originally posted this in the feature requests side but the more I think about it, the more I consider the inability to see _any_ modified indicator (please correct me if I'm blind!) a bug. 

If the official answer is "don't keep so many tabs open" or "use shorter filenames", well... not gonna happen (in either case). :-D 

Most recently tested in 1.7.1 macOS

 

[Aammppaa]

It isn't a bug, as everything is working as the system is designed to work.

But I think it is a reasonable feature request.

[Brad Brighton]

8 hours ago, Aammppaa said:

It isn't a bug, as everything is working as the system is designed to work.

But I think it is a reasonable feature request.

I'm genuinely not wanting to pick a fight but I'm curious: in what manner do you regard a "sometimes visible" modified indicator to be working as designed?

Incorrect/inconsistent UI should also be considered a bug... as a reference:

In general, use a dot to mark a modified document as unsaved only when it can't be autosaved. If a document can be autosaved, there shouldn’t be a dot on the close button in the document’s title bar and next to the document’s name in the Window menu. It’s fine to append an Edited suffix to the document's title in the title bar, but this suffix should be removed when the document is closed or the user manually performs a save.

Behave appropriately when Auto Save is disabled. Users can disable Auto Save by selecting the “Ask to keep changes when closing documents” checkbox in the General system preference pane. When Auto Save is disabled, your app should exhibit the expected behavior when there are unsaved changes. Specifically, your app should denote that there are unsaved changes and present the Save dialog when the user tries to close the document, quit the app, log out, or restart.

from https://developer.apple.com/design/human-interface-guidelines/macos/system-capabilities/auto-save/

The recovery file(s) that Affinity Photo uses don't count as autosave. The app has the "[m]" indicator but again, only under best case conditions so at best, this implementation of the UI maxims is inconsistent.

[Chris B]

Hey Brad Brighton,

I will log this with the developers as I think it's a good idea but I'll let them decide if it's a bug or an improvement  

[Brad Brighton]

3 hours ago, Chris B said:

Hey Brad Brighton,

I will log this with the developers as I think it's a good idea but I'll let them decide if it's a bug or an improvement  

@Chris B, thanks! The only reason I care about the distinction (aside from philosophy) is because the implied priority of a bug is (normally) much higher than the feature requests.