Should we have `system/view/screens` at all?

[hiiamboris]

I've come to question the whole idea that windows should be attached to different screens.

It's easy to show that a single window can span any number of displays, and in that case to which display it belongs?

You can say it belongs to the display where its left top corner is located - this definition is sufficient, sure, but the point is that our per-display division is artificial - it is not enforced by the OS.

Moreover, if we think from a focus model perspective: there are nodes in the OS widget tree (windows, pages, fields) that remember their last focused widget or caret position and restore it to the child when such node is refocused. But screen is not one of these, as we can't refocus to a screen, only to another window.

So:

• What do we gain from it? Please list the benefits that you see.

• Clearly we get extra complexity, as now we have to traverse all the system/view/screens to list all opened windows: example

My proposal here is:

1. Let's keep screens as informational structure: we need each screen's geometry to locate and place windows
2. Let windows belong all in the same single root (e.g. system/view/windows)

[greggirwin]

Do we have a description of the current logic and why it is the way it is? I agree that listing pros and cons is a good thing to do.

Even all windows on a screen list their offsets relative to the primary monitor/screen, not the one they are on, so we can't say it's a PRO because it avoids negative window offsets. You still need to know the overall display coverage.

[hiiamboris]

I wonder (related). How do we even determine which window is currently active in Red? There's no "selected" screen that would guide us to a "selected" window on that screen.

[greggirwin]

Need to use GetActiveWindow for the active app window, or GetForegroundWindow for the system wide active window.

[hiiamboris]

Yes, but that's a non-portable R/S hack that needs more hacks to get that HWND converted back into a window face. What do we do on Red level?

[greggirwin]

Agreed. Other OSs must have similar APIs. To do more, Red would have to hook the OS to track changes, or do it within a single app if that's enough, and set it accordingly.

We can start from use cases, and see if there's a simple solution for those. The only time I remember needing something like this was in tracking spawned processes, but then I didn't really need to know the active window, but to bring it to activate it.

[hiiamboris]

Use case example: "Where is the current focus?"

Especially when graphical focus indication is involved. I know there are hacks... I could track each window's on-focus, if it worked reliably.

But in the context of this issue, I'm just bringing the solidity of our focus model to the table. Is it complete without knowing the active window? No. We can go down the /selected facets to discover both the currently focused face and last focused faces of each page-related subtree (e.g. in tab-panels). Again, in theory only, as in practice it's all broken throughout, but the design is there. But there's no design for the active window or screen.