Missing context menus in multi-display setup
Opened this issue · 6 comments
Brief summary of issue / Description of requested feature:
When running a multi-display setup, context menus and dropdowns may not appear, depending on which display mudlet is on.
Steps to reproduce the issue / Reasons for adding feature:
- Connect a second monitor
- Right click on the window, or check the trigger type dropdown
- Move mudlet to the other display
- Check again
Error output / Expected result of feature
On some of the displays, the context menus may not appear
Extra information, such as the Mudlet version, operating system and ideas for how to solve / implement:
Tested on linux AppImage 4.17.2, in fedora 38 with gnome
Does this sound like it might be related to the discussions in edbee/edbee-lib#77 - @dicene put a fix in place (which got adopted upstream) but I wonder whether it fully solved the problems - or is using code that Qt has now declared obsolete (because it used details that were not adequate in a multi-monitor setup)...
This is something I could look at - and, unlike the screen shot I displayed in that Issue I now have a triple-header (43" 4K TV with two 1920x1080 monitors beneath - IIRC) which have the right combinations of pixels to mesh nicely into a larger rectangle - which will be an ideal test environment...
The context menus aren't showing up on the other monitor, like the autocomplete dropdown did in that other issue.
Interestingly, I'm only seeing the issue when the displays are configured as a "joined" virtual display with the laptop's built-in display as the primary monitor, and the primary slightly offset from the external.
If I switch to mirrored, or if I make the external monitor the primary, or if I line up the built-in and the external, then the issue goes away.
i.e. this works:
but this does not:
... if I line up the built-in and the external, then the issue goes away.
Do you mean that there is a gap (some pixels) between the two displays in the overall "desktop" area - if so then it sounds like the context menu might be being placed in that area (gap) between the displays - and that is a very plausible explanation as the code (from what I recall, only checks that the menu is displayed in the overall desktop area - and not particularly on any "screen" within that!)
Also, though I may be wrong, I think some OS/DE environments do expect adjoining displays to be aligned at one corner - not as they are your second case (or maybe they just try to "snap" them together like the first)...
No, there's no gap between the edges. In fact, there doesn't seem to be a way to separate the screens to create a gap between them, as far as I can tell.
I started testing other screen arrangements: built-in lined up on the bottom of the external, on the top, on the left instead of the right; built-in offset above the external instead of offset below it; etc. All of the arrangements work fine, with the exception of the one I originally had trouble with, and its mirror image: built-in display to the left or right of the external, and offset below (such that the top of the built-in display is somewhere below the mid-line of the external display's vertical)
For your problem case - in which direction would the context menu be if it were on-screen. I'm beginning to suspect that it is being shown on a portion of the "virtual desktop" (a rectangle including the outer edges of all the monitors) which is within those bound but not part that is physically present on any of your monitor.
(There is a separate but related case that I get with my web-browser where it puts a context menu on the wrong monitor!)