The widget is kept shown [regression]

[yan12125]

With 9f9b912, after right-clicking on the tray icon to show the widget, there are two ways to hide the widget:

1. Right-click somewhere outside the widget
2. Right-click the tray icon again

After upgrading to 5e39683, neither ways work. I guess it's related to 1bdba31.

Environment: Arch Linux up-to-date + LXQt on X11 + xfwm4-git 4.14pre2+18+gc7e73e3d6-1

[Martchus]

I didn't notice that problem with openbox and plasma. Maybe it is the line which is setting the window flags explicitly which is now missing something: setWindowFlags(Qt::ToolTip | Qt::FramelessWindowHint | Qt::Popup);

And be sure that the environment variable QT_XCB_NO_GRAB_SERVER is not set.

[yan12125]

I didn't notice that problem with openbox and plasma

FWIW, I still got the issue with openbox.

Maybe it is the line which is setting the window flags explicitly which is now missing something

Thanks for the hint! First I dump the original window flags with qDebug() << windowFlags();. The result is:

QFlags<Qt::WindowType>(Popup|WindowTitleHint|WindowSystemMenuHint|WindowMinMaxButtonsHint|WindowCloseButtonHint|WindowFullscreenButtonHint)

After several trials and errors, I found that removing Qt::ToolTip fixes the issue.

diff --git a/tray/gui/traymenu.cpp b/tray/gui/traymenu.cpp
index b4f6ca7..ddf99ca 100644
--- a/tray/gui/traymenu.cpp
+++ b/tray/gui/traymenu.cpp
@@ -24,7 +24,7 @@ TrayMenu::TrayMenu(TrayIcon *trayIcon, QWidget *parent)
     menuLayout->addWidget(m_trayWidget = new TrayWidget(this));
     setLayout(menuLayout);
     setPlatformMenu(nullptr);
-    setWindowFlags(Qt::ToolTip | Qt::FramelessWindowHint | Qt::Popup);
+    setWindowFlags(Qt::FramelessWindowHint | Qt::Popup);
 }
 
 QSize TrayMenu::sizeHint() const

And be sure that the environment variable QT_XCB_NO_GRAB_SERVER is not set.

Yes I didnt use that.

[Martchus]

Ok, it also happens under openbox. I must have closed the menu by clicking on a blank space of the menu itself in all my tests (which is the 3rd option to close the menu).

(I have written that comment before reading your previous comment.)

[Martchus]

Yes, that works - I tested it now. If you like, make a PR. If that makes things worse on Wayland again then I don't care and add a Wayland specific path later myself.

By the way, I use QT_XCB_NO_GRAB_SERVER for all my testing. Hence I always have to close the menu using "the 3rd option". The problem I want to avoid during development is that the debugger pauses the process while the mouse is grabbed (under X11 the behavior you were missing is achieved by grabbing the mouse). So that's the background info why I didn't catch that issue during my tests.

[Martchus]

I've just uploaded the commit myself.

[yan12125]

By the way, I use QT_XCB_NO_GRAB_SERVER for all my testing

That's useful!

I've just uploaded the commit myself.

Thanks!

[Martchus]

No I remember why I added the Qt::ToolTip flag: To get the relative coordinates for the context menu right. This is now broken instead. But there must be a better solution than making it a tooltip.

[Martchus]

I found a workaround, see the commit description if you're interested: 6057b2c

Not sure whether this workaround is better than simply using QCursor::pos(). I wanted to avoid QCursor::pos() because it doesn't work under Wayland but under Wayland there other problems anyways.

[yan12125]

Glad to see another issue fixed/workarounded, but to tell the truth it's beyond my Qt knowledge :]