elementary
Position windows opened via context menu depending on pointer position
Problem
The desktop has a context menu with currently 3 actions:
- Change wallpaper
- Display settings
- System settings
When choosing one of these actions in a multi monitor setup, the settings window might open on a completely different screen.
So I have to move my head to have a look at the other screen, then identify the newly open window (which might have appeared on top of previously opened applications on that screen).
This interrupts me quite heavily when I just want to make a quick change to the settings while doing actual work.
Proposal
To have a better user experience and less interruptions on the user interaction flow when invoking one of these actions, I suggest that the window opens relative to the position on the desktop where the context menu opens.
Example: I have a laptop with 1920x1080 px display and an external screen with 3840x2160 px in an "extend display" configuration.
My main display is the 4k external screen but previously it was only the laptop. The 4k screen is quite big, too (32") and I am sitting quite close (I know that this is not ideal)
Now I move my mouse near the external screen bottom right corner (like 5cm or so from the screen's border). Then I right click and open the settings from the context menu. The settings window opens on the laptop screen centered. I would like to open it with the bottom right border of the window located where the mouse pointer was when opening the context menu. If I would open the context menu near to top left corner of the ext. screen, I would expect the window to appear with the top left corner of the window located at the location where the context menu opened. Same for the remaining two corners. This way, the newly opened window will also never overflow the screen borders so that all contents of the window will be visible.
This should be completely independent from the chosen primary display. So the same behavior should in the above case happen on the laptop screen.
Prior Art (Optional)
No response
Checked this and this doesn't happen with GTK 4 version of settings! So I guess we need to wait for it to release.
Thanks for trying it out and letting me known. Does anyone have an estimate when it might be released?
@CodingSpiderFox We don't have an estimate when it'll be released. There is still a lot of work to do. Only 8 plugs out of 21 were ported to GTK 4.
