[Proposal] Remove Screen from WindowBase

[workgroupengineering]

Avalonia/src/Avalonia.Controls/WindowBase.cs

Line 95 in 8ad9205

public Screens Screens { get; private set; }

I would suggest removing the Screen property and making the members of the Screens class static.

[sn4k3]

+1

I too come into problem because of this, should be static.
Also what about a getter Screen property on Window that indicates in which screen is currently, so if user change screen it will update the Screen property?

[workgroupengineering]

If Screens is static yoo can get screen by Screens.FromWindow(this);

[sn4k3]

My point is, with the property there we can get notified when screen is changed. So it's more for the event thing.

[workgroupengineering]

You can create a custom Behavior that listens for the Position change event.

[maxkatz6]

Not static, but it could be moved to the Application probably.

[workgroupengineering]

if the core team wants, I do a PR.

[grokys]

There's a good reason for this, something about how windows can be on different seats with a different screen configuration, so the available screens can depend on where the window is displayed. I'm not sure of the details though - @kekekeks can explain.

[kekekeks]

Having global variables greatly restricts possible Avalonia usage scenarios. Having global screens, for example, means that there is only one set of screens with windows movable between them, which is not true in the following scenarios (we don't support all of them yet, but we shouldn't deliberately prevent ourselves from supporting them):

1. multiseat X11 - there are different sets of screens and input devices running on the same machine by the same user on the same X Server
2. multiseat Wayland - there are different sets of screens and input devices running on the same machine by the same user on the same X Server
3. running an embedded VNC server (with or without an actual desktop windows of the same process), there can be multiple VNC sessions
4. exporting devtools from a mobile device to desktop machine via websocket
5. GUI embedding into a video game with devtools running as a separate actual desktop window

So in general platform services and "global" state which isn't really so global should be only accessible via a TopLevel that is actually bound to that particular "global" state.