[Bug] [Linux] New floating windows placement on multi-monitor setup

[einhander]

Describe the bug Some new floating window placement are wrong in multi-monitor setup. See the screencast in this comment: https://github.com/DanWBR/dwsim/issues/744#issuecomment-2696499163

To Reproduce

1. Use multimonitor setup
2. Create new flowsheet

Expected behavior All new windows appear in center of active monitor.

Desktop:

• OS: Linux Debian Testing with Awesome WM as window manager
• Version 9.0.0

Additional context

It's a minor problem

[DanWBR]

@einhander it seems that Screen.PrimaryScreen.WorkingArea.Center in

https://github.com/DanWBR/dwsim/blob/ce8549e71006501bf8891a92052a80dd6ccd5447/DWSIM.ExtensionMethods.Eto/EtoExtensions.cs#L62-L88

is returning the total area of all monitors. Last time I tried Screen.DisplayBounds.Center, it was returning null on Linux.

[einhander]

The placement of normal windows is OK for me. The dialog windows are also OK.

[DanWBR]

@einhander how is it doing in v9.0.1? same behavior?

[einhander]

@DanWBR thank you. Please, wait till end of next week. I'll have to check it with my multi-monitor setup in university.

[einhander]

@DanWBR That's better, but not perfect, see screencast

https://github.com/user-attachments/assets/e943a414-853c-445d-a8fa-72a6cf04ee8f

The new window only appears on a non-active monitor. I think you are using the primary monitor instead of the active monitor. Here is xrandr output for primary monitor:

eDP connected primary 1920x1080+3840+0

So using the primary monitor as the spawn point will result in new windows only appearing on one fixed monitor. I briefly checked the eto documentation and can't see if it's possible to get an active monitor. The workaround for this problem is to set to these windows properties to _NET_WM_WINDOW_TYPE_NORMAL instead of _NET_WM_WINDOW_TYPE_UTILITY as it is now.

[DanWBR]

@DanWBR can't do further improvements due to Eto.Forms library limitations on Linux.

[einhander]

Anyway, thank you for your efforts.