Reputation: 28689
My Qt app's context menu is displayed in the incorrect position when using multiple monitors on Gnome 3.
It would seem that perhaps the culprit here is Gnome Shell, rather than Qt itself, as I can't replicate the issue described below with Ubuntu Unity, it only happens when running Ubuntu Gnome 14.04.
Symptoms:
I am using QWidget::mapToGlobal(QPoint)
from a QWidget::customContextMenuRequested
signal in order to find the correct position to display a context menu.
I am then using QMenu::exec(QPoint)
to display the menu in that position
void Window::slotOnShowContextMenu(const QPoint& p)
{
_menu->exec(_tree->viewport()->mapToGlobal(p));
}
My problem is that I have the following screen layout:
When my window is on the right hand screen, or on the left hand screen but at a position below the top of the right hand screen, the context menu is shown correctly:
When my window is on the left hand screen, at a level above the top of the right hand screen, even though the Y value of the QPoint
returned from mapToGlobal
is correct, the context menu is not displayed at that point, but is rather constrained to be at the same level as the right hand screen.
I have confirmed that _tree->viewport()->mapToGlobal(p)
returns the correct results (just by logging the resulting QPoint
)
QPoint point = _tree->viewport()->mapToGlobal(p);
std::cout << point.x() << ":" << point.y() << '\n';
It would therefore seem that QMenu::exec(QPoint)
is the culprit?
How can I correctly display my context menu?
Edit:
I tried running the same app on standard Ubuntu 14.04 (ie: using Unity instead of Gnome), and the incorrect behaviour doesn't present itself, so this would seem to be a Gnome 3 issue?
I have tried changing my primary monitor so that the portrait monitor on the left is primary, and the context menu displays correctly.
Note black launch bar is on the left screen
When using the following layout (primary screen is landscape on the right) the context menu position is constrained to be the top of the primary monitor.
Note black launch bar is on the right screen
So it would seem that the primary monitor's top position is the maximum height that Qt will display it's context menu?
Upvotes: 3
Views: 1148
Reputation: 1
I'm running into this with qt applications in fvwm if:
The menus end up off-screen and not visible at all or in completely the wrong place (depending on the monitor offsets) -
Thus I'm not so sure this is just a gnome shell bug.
Upvotes: 0
Reputation: 700
I ran into this same issue. As I dug into it I realized that it's a conflict between the perceived/"logical" monitor location and the rendering of the screen. In my case, I can see through the output of xrandr
and the configuration of ~/.config/monitors.xml
that my right most monitor (the equivalent of your Hewlett Packard 27" monitor) that it has a position offset of +360
:
$ xrandr
Screen 0: minimum 320 x 200, current 7040 x 1440, maximum 16384 x 16384
eDP-1 connected primary 1920x1080+5120+360 (normal left inverted right x axis y axis) 309mm x 173mm
...
These 360 pixels correspond to the top of the window's "location" as understood by QT. In my case the menu bar itself is 25 pixels high. Keeping all this in mind(360 + height of title bar + height of menu) actual offset of where perceived drawing of the menu.
+---------+---------------------------------------------+ ^
| | | |
| +-------------------------------------^-------------+ | |
| | | | 25 pixels | | | 360 pixels
| +-------------------------------------v-------------+ | |
| | | | | v
| | | 385 pixels | +---+---------------------------+
| | | | | |
| | +----v+ | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | +-----+ | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| +---------------------------------------------------+ | |
| | |
| | |
| | |
| | |
+-------------------------------------------------------+-------------------------------+
When I re-aligned me screens so that the position offset was zero like in the following setup the problem went away:
$ xrandr
Screen 0: minimum 320 x 200, current 7040 x 1440, maximum 16384 x 16384
eDP-1 connected primary 1920x1080+5120+0 (normal left inverted right x axis y axis) 309mm x 173mm
...
In this case the 360 pixel position offset is now zero and QT renders the menu drop down at the correct location:
+-------------------------------------------------------+-------------------------------+
| | |
| +-------------------------------------^-------------+ | |
| | | 25 pixels | | |
| +--+-----+----------------------------v-------------+ | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | +-----+ | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | +-------------------------------+
| +---------------------------------------------------+ |
| |
| |
| |
| |
+--------------------------------------------------------
I was in the process of filing a bug with QT about this (as I have multiple applications which are affected by this bug), but in the process of collecting the relevant information for the bugs I discovered that it's not just QT/QT5 affected but also Blender. As Blender does not use a graphics framework (e.g. QT/QT5, GTK+, etc) this is almost certainly a bug in one of the components of GNOME3.
Upvotes: 1
Reputation: 1856
While the technical details may be slightly different, I found with elementary os and two monitors (a laptop and a smart tv), with my built-in display positioned on the right of the external display, the menu is invisible if I have the Qt app (KeePassXC in my case) on my built-in display. If I move it to my external display, the menus are at the top of the display, instead of in the window. There is clearly a bug somewhere, whether in Qt or ubuntu or gnome shell, I can't say.
I can say that switching my displays back to the default positioning, with the built-in on the left of external, the issue is resolved: I can finally access the menus where they should be.
I have tried moving the window location around, and as long as I have my built-in display situated to the left of my external display, it doesn't matter where the window is, it just works like it should.
This solution may not be ideal if your monitors are not physically positioned that way, but in my case, I'm already having to lie about where my monitors are positioned. My built-in is below my external, but when I try to tell elementary that, it stops functioning correctly (all windows are moved to outside the bounds of the screen, all windows launch off screen; deleting .config/monitors.xml fixes it, but I have to be able to get to a command prompt on the screen to do it.)
Upvotes: 0