Should they, though? Screen priorities aren't stable, intentionally so.

Hm, when I use Display Configuration to Change Screen Priorities then the setting is stable.

I think screen priorities should be reliably configurable. Its unbearable if users have to reconfigure
their many KWin rules just because they migrated to Wayland or replaced their video card or similar.

Also KWin rules KCM provides rule exports, probably to share them across devices.

Now, if I am used to monitor the logs on my left screen at home, but suddenly have to monitor
logs on the right display at the office, this is a huge additional angry factor.

I have no clue how to configure screen indexing/ordering/prioritizing besides Display Configuration.
Is there any?

Are Screen Priorities and Screen Indices even related? 
Or should KWin provide a Screen Priority Property besides Screen Index Property?

The priorities thing is about where your desktop environment components are placed, they're not really that good a fit for window rules. But it would still be better than the random-ish indices we have right now.

I think the best option would be to use the (now properly persistent) output UUIDs, so you can configure a window to be placed on a physical display. Implementing that would also require some new UI to select a screen though.

(In reply to Zamundaaa from comment #3)
> The priorities thing is about where your desktop environment components are
> placed, they're not really that good a fit for window rules. But it would
> still be better than the random-ish indices we have right now.

I've been postponing changes here until having a clearer idea of what we want to mean with this setting.
I agree with you on this one, and if there is consensus, we can make the "int" setting be the screen priority (with corresponding changes also in the UI)

> I think the best option would be to use the (now properly persistent) output
> UUIDs, so you can configure a window to be placed on a physical display.
> Implementing that would also require some new UI to select a screen though.

On paper this sounds nicer, but it can be an issue with changing set-ups (let's say different physical screens on a company or work/home, etc) A bit similar to what happened what screen UUIDs when used to store desktop settings. I wouldn't mind also adding this if considered, but maybe better as an additional rule property. 

In the end I think there is no actual best option, only get closer to match (multiple ever changing) user expectatives :)

But using the Display configuration's screen priority as screen index in Kwin reads reasonable on paper also. 
On all my devices with configured priorities this matching mechanism would make perfect sense to me. It's predictable that zero is always primary and so on.
If the Kwin rules screen index is greater than available indices, it should always use the highest available index (least priority).

Are there use cases where it doesn't work?

(In reply to Dominik Kummer from comment #5)
> Are there use cases where it doesn't work?
Like I wrote, they define the position of your panels. If you decide to change the position of the panels, then all your window rules get changed too.

(In reply to Ismael Asensio from comment #4)
> On paper this sounds nicer, but it can be an issue with changing set-ups
> (let's say different physical screens on a company or work/home, etc) A bit
> similar to what happened what screen UUIDs when used to store desktop
> settings.
That system was mostly *that* terrible because it didn't actually use any UUID. The system used the connector name, which is just barely better than a random number generator, and on top of that it had some heuristics for matching different connectors to the same containment, which made everything even worse.

But yeah, the physical display won't work for every use case. Making it two options does sound reasonable.

But why would anyone want to have different screen priorities for panels and windows? That would overcomplicate things, as we have activities and virtual desktops also. 

Is there an actual use case for separate priorities? 

IMHO it's even better to expect certain windows at the same display where I'd expect certain panels.

*** Bug 510136 has been marked as a duplicate of this bug. ***