-
|
Steps to reproduce:
This has led me to a lot of unintentional actions and I am hoping there is a way to change it to how Windows does it - namely, the menu is not shown until the right mouse button is let go of. Tested on LXQt (Qt) and Firefox (GTK). This "eagerness" of mousedown/mouseup actions may appear in other areas, but I have not found any yet. |
Beta Was this translation helpful? Give feedback.
Replies: 11 comments 8 replies
-
|
I may have misunderstood your question because I didn't get what you meant by "eager". But, in case you meant that right clicking can easily activate the first menu-item randomly, that may be about a faulty mouse (setting). In Qt, a menu-item is activated when the "mouse release event" happens on it, and I don't think that can be changed. If the mouse is moved before it's released, it could activate the first (or last) menu-item by chance. However, some Qt themes — particularly, some Kvantum themes, like the one in the following screenshot — put a small margin before the first menu-item (and after the last one), so that a small mouse shaking can't activate anything. But most Qt themes lack that margin, Fusion included. I think the default GTK theme has it too.
EDIT: Breeze seems to have a tiny margin too. |
Beta Was this translation helpful? Give feedback.
-
|
It was the first few menu items that were often triggered for me accidentally. I read somewhere that Qt6 was changing this behavior, but testing on Qt6 programs it appears that is not the case (yet?). It seems like a questionable aspect of current Qt/GTK, if people are aware that this trips people up and devs have added minor mitigations. |
Beta Was this translation helpful? Give feedback.
-
|
Theoretically, it should be possible to show any menu only on releasing the mouse button, but I can imagine that it might have serious side effects. I didn't find a parameter for it in QStyle documentation. If you know of Qt reports or professional discussions on this topic, please add their links here. |
Beta Was this translation helpful? Give feedback.
-
|
BTW, I forgot to mention something about your question. An old behavior of a toolkit may be suboptimal, but almost no one may have paid attention to it before. I mean that the lack of a report doesn't mean anything by itself (although I hope you find one). I have a firsthand example of this but don't want to clutter this page by talking about it. |
Beta Was this translation helpful? Give feedback.
-
|
This is what I found for: |
Beta Was this translation helpful? Give feedback.
-
|
Good news! I knew that I'd seen it somewhere but didn't remember where. At last, I found I'll test what will happen if it's set to EDIT: Sorry for the typo; fixed now. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I tested However, there are complications, which may be the result of assuming that it should be First, some Qt apps have problem with it. For example, when I right click a row in the playlist of Audacious, the context menu is shown on releasing mouse button, but Audacious also starts to play the song. I'm not sure if this is a problem in Audacious or in Qt. Second, this is only about the context menu. I didn't find an option for all menus. Thus, if we set it to Third, we can't change how GTK menus behave. That may be seen as another discrepancy. I feel there may be more problems, but since I tested it on my old laptop (which I don't use for work), I didn't have enough time for a thorough investigation. My personal opinion is that isn't worth adding an option. But I hope we'll hear from other LXQt members too. EDIT: Oh, Audacious was just one example. I checked it again and saw that several apps behave inconsistently with it, including our apps. Some apps even override it in some places and follow it in others (like Falkon). This is an example of how a fixed value is wrongly assumed for a parameter (see the bold paragraph in #1433 (comment)). |
Beta Was this translation helpful? Give feedback.
-
|
This is indeed good news that Qt has an option for it. It sounds like /if/ LXQt apps don't work with it set either way or behave inconsistently with it, that should be fixed (if not Qt's fault), but other Qt programs may mangle the option unfortunately. I recompiled lxqt-qtplugin with |
Beta Was this translation helpful? Give feedback.
-
Theoretically, I agree with you. Practically, there are lots of other Qt apps. We can't tell their devs to "fix" their apps only because we want to set But, perhaps most importantly, there may be a spec somewhere ( |
Beta Was this translation helpful? Give feedback.
-
|
This topic gets more interesting to me each time I return to it. Last night I mentioned some discrepancies that would result from setting Without setting |
Beta Was this translation helpful? Give feedback.
-
|
I couldn't resist the temptation of testing more thoroughly, by making Qt5 and Qt6 test packages for showing context menus on mouse release in my work computer. In what follows, I use the signs (+), (-), (0) and (?) for "OK", "Not OK", "Neutral" and "Not Decided" respectively.
Will it be bad if LXQt becomes the first DE with an option for it — although only with Qt apps? |
Beta Was this translation helpful? Give feedback.
-
After installing Falkon, the issue only appeared inside the webpages. Perhaps an issue with qt5-webengine?
This happens for all menus, regardless of how
I feel it should be left as what other apps do / the Qt default is. |
Beta Was this translation helpful? Give feedback.
-
Correct, but what I meant was the same as what you mentioned: it creates a problem when Unfortunately, if someone sets
I agree. |
Beta Was this translation helpful? Give feedback.
-
|
For the sake of completeness: The context menu problem in lxqt-panel's Main Menu can be worked around by this patch for diff -ruNp libqtxdg-orig/src/qtxdg/xdgmenuwidget.cpp libqtxdg/src/qtxdg/xdgmenuwidget.cpp
--- libqtxdg-orig/src/qtxdg/xdgmenuwidget.cpp
+++ libqtxdg/src/qtxdg/xdgmenuwidget.cpp
@@ -145,7 +145,20 @@ bool XdgMenuWidget::event(QEvent* event)
if (e->button() == Qt::LeftButton)
d->mDragStartPosition = e->pos();
}
-
+ else if (event->type() == QEvent::MouseButtonRelease)
+ {
+ // Do not activate actions by right clicking because
+ // context menus may be shown on releasing right mouse button.
+ QMouseEvent *e = static_cast<QMouseEvent*>(event);
+ if (e->button() == Qt::RightButton)
+ {
+ QAction *action = actionAt(e->pos());
+ if (action != nullptr && action->menu() == nullptr && action == activeAction())
+ {
+ return false;
+ }
+ }
+ }
else if (event->type() == QEvent::MouseMove)
{
QMouseEvent *e = static_cast<QMouseEvent*>(event);
The same problem in Main Menu's search view can be fixed by a similar patch for diff -ruNp lxqt-panel-orig/plugin-mainmenu/actionview.cpp lxqt-panel/plugin-mainmenu/actionview.cpp
--- lxqt-panel-orig/plugin-mainmenu/actionview.cpp
+++ lxqt-panel/plugin-mainmenu/actionview.cpp
@@ -289,6 +289,16 @@ void ActionView::mousePressEvent(QMouseE
QListView::mousePressEvent(event);
}
+void ActionView::mouseReleaseEvent(QMouseEvent* event)
+{
+ // Do not activate actions by right clicking because
+ // context menus may be shown on releasing right mouse button.
+ if (event->button() == Qt::RightButton)
+ return;
+
+ QListView::mouseReleaseEvent(event);
+}
+
void ActionView::mouseMoveEvent(QMouseEvent *event)
{
if (!(event->buttons() & Qt::LeftButton))
diff -ruNp lxqt-panel-orig/plugin-mainmenu/actionview.h lxqt-panel/plugin-mainmenu/actionview.h
--- lxqt-panel-orig/plugin-mainmenu/actionview.h
+++ lxqt-panel/plugin-mainmenu/actionview.h
@@ -104,6 +104,7 @@ protected:
virtual QSize viewportSizeHint() const override;
virtual QSize minimumSizeHint() const override;
void mousePressEvent(QMouseEvent *event) override;
+ void mouseReleaseEvent(QMouseEvent *event) override;
void mouseMoveEvent(QMouseEvent *event) override;
signals:
These patches have no side effect with the default value of EDIT: If LXQt really implements this, the patches should be made more complete by checking the context menu policy, but they work for testing. EDIT1: On second thought, checking the context menu policy may not be needed — as it isn't checked for MS Windows by |
Beta Was this translation helpful? Give feedback.
-
|
What about the generic case (for all things Qt) where Qt::RightButton mouse release triggers a sub-menu. That was my concern that I forgot to mention. However I can't find any examples of this for my installed apps, maybe the issue is either Main Menu specific or exceedingly rare. |
Beta Was this translation helpful? Give feedback.
-
If by "submenu" you mean a context menu for a menu in any Qt app, as I mentioned in #2460 (reply in thread), we can't do anything about it. It's up to the developer to pay attention to details and add a small code to his app — like the above one. But, more importantly, the issue should be fixed in Qt itself. If by "sumenu" you really mean a submenu, it isn't affected. Anyway, why should users trigger menu actions by right clicking?! IMO, the condition if (action && action == d->currentAction) {
if (!action->menu()) {
#if defined(Q_OS_WIN)
//On Windows only context menus can be activated with the right button
if (e->button() == Qt::LeftButton || d->topCausedWidget() == 0)
#endif
d->activateAction(action, QAction::Trigger);
}
}Perhaps a more fundamental approach could also be taken regarding |
Beta Was this translation helpful? Give feedback.
-
|
@stefonarch found this for Firefox and Thunderbird:
|
Beta Was this translation helpful? Give feedback.
-
|
To sum it up: Qt is not self-consistent in this regard. Hence closing lxqt/lxqt-qtplugin#79 (and related PRs). See the comments under that PR for the reason. |
Beta Was this translation helpful? Give feedback.
Good news! I knew that I'd seen it somewhere but didn't remember where. At last, I found
ContextMenuOnMouseReleasein Qt →qplatformtheme.cppand then noticed that it's already covered by our lxqt-qtplugin →lxqtplatformtheme.cpp. We've left it to its default value, i.e.,false.I'll test what will happen if it's set to
trueand whether that has a side effect.EDIT: Sorry for the typo; fixed now.