[Ukv]

Performance, clipboard behaviour, and file browser persistence seem like fairly typical OS-specific issues. Obviously not great if they're not properly testing macOS, but I don't think it's an "even bigger red flag" for those to be OS-specific.

Grouping close-together changes of the same control for undo sounds probably intentional to me, like how Ctrl+Z in a textbox doesn't go one character at a time, and if I move something with arrow keys I'd expect that to be one "movement" once I stop rather than one per key repeat. Whether it's grouping too aggressively to the point of being recognized as an issue is probably down to personal preference, though I would lean towards agreeing that less grouping would be better.

[goblin89]

> Grouping close-together changes of the same control for undo sounds probably intentional to me

I explained how it happens. Intentional or not, it just takes us between buggy software and poorly designed software and even then losing changes (not all of what is undone is redone and you are left in an inconsistent state) remains a bug.

> Ctrl+Z in a textbox doesn't go one character at a time

Retyping text is not comparable to readjusting different fine color controls on different pages of the UI across different nodes.

By comparison, the aforementioned RawTherapee (despite being powered by Qt and looking pretty barren) in fact works more reliably with no such issues, and it’s also cross-platform software that is free to boot.

[Ukv]

> The aforementioned RawTherapee has no such issues

I don't mean to claim that the mentioned issues are unavoidable or that some piece of software is more likely than not to have these issues, just that when there are OS-specific issues it's this kind of thing I expect. Clipboard handling is pretty much an entirely different implementation on each platform unless you're using something like Electron that already handles it for you, for instance.

[goblin89]

There’s no use case for system clipboard, given it’s a monolithic piece of software that doesn’t allow multiple projects to be simultaneously open in different instances. There’s nowhere else to paste except the same window.

Meanwhile, open-source, non-Electron, multi-platform software that handles copy-paste via system clipboard exists just fine (VCV Rack comes to mind).

[Ukv]

> There’s no use case for system clipboard

There are many things it makes sense to copy/drag-drop between applications. There are cases where you might not need to, but using the system clipboard is still common.

> Meanwhile, open-source, non-Electron, multi-platform software that handles copy-paste via system clipboard exists just fine (VCV Rack comes to mind)

VCV Rack seems to just use GLFW to handle it, but again I'm not claiming these issues are unavoidable or more likely than not to occur. For any given issue with some software, 99% of other software will not have that same issue.

[goblin89]

This starts to look like a waste of time and not a useful discussion. There are frameworks and libraries that handle 100% of clipboard OS specifics, and the app in question has no use for system clipboard in the first place. In my experience the app is buggy and a pain to use relative to other software, that’s the entirety of my point.

[Ukv]

> There are frameworks and libraries that handle 100% of clipboard OS specifics

They're sufficient in many cases, but you'll still sometimes need the control of working with COM/etc. directly, and those libraries don't fully save you from platform-specific bugs (e.g: https://github.com/glfw/glfw/issues/2644).

> the app in question has no use for system clipboard in the first place

What do you expect to happen when you copy some text from an external editor into a text field?