QAction is not a widged, so it is not possible to set it as a parent of QMenu.
As a result, QMenu assigned to QAction is not automatically deleted when action is removed from menu and/or deleted.
As soon as QMenu becomes empty it is closed. This can happen when the application completely reloads its menu.
Instead, call deleteLater which will destroy the QAction later at which point it is automatically removed from the menu.
BUG: 399975
FIXED-IN: 5.14.4
CHANGELOG: Fixed global menu misbehaving and unexpectedly closing with certain applications
Differential Revision: https://phabricator.kde.org/D16297
Summary:
The getLayout response handler compares the new list of actions with the
current actions in the menu and calls deleteLater on all actions which aren't
part of the new list anymore.
Then, it adds all actions from the new list which aren't part of the menu yet.
As deleteLater only has an effect after the next event processing, the menu
still contains them together with the added actions.
This resulted in broken size calculations, as even for static menus the item
count changed during aboutToShow.
Note that this is not a proper solution for the resize issue, as the
aboutToShow handler changes the menus content for a reason, the application
is free to add/remove items at any point in time.
Test Plan:
The context menu for SNI items in the system tray shows at the
correct position now. Only tested the wayland session.
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D11586
We call updateMenu() to cache the first level of menus in advance in global menu applet.
Just move the "opened" call there to ensure it's always called both when the menu shows or when someone manually triggers it.
Differential Revision: https://phabricator.kde.org/D9782
Firefox deliberately ignores the "about-to-show" event and only updates its menus in response to "opened".
There was an unused slot to send an "opened" event. Use that and place the updateMenu call inside.
Also use an UniqueConnection.
Differential Revision: https://phabricator.kde.org/D9631
Summary:
Right now, new Action always appends to the list, but application may
want to add new action in the middle of the menu. This breaks such
application with dynamic menu entries. This change tries to keep the
order of actions same as the order in dbus request.
Test Plan: Manually tested the brokened menu in certain applications.
Reviewers: #plasma, davidedmundson, broulik
Reviewed By: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8585
Summary:
This sends the close event to the client which then sends aboutToHide to
the QMenu.
Code was all there, just not hooked up
BUG: 375053
Test Plan: Added qDebug to the test app inside libdbusmenuqt
Reviewers: #plasma, markg, broulik
Reviewed By: #plasma, markg, broulik
Subscribers: broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5192
Summary:
Export actionForId as a method in menuImporter
IDs are used in the low level API which the appmenu kded module wants to
use directly.
Fix arguments in itemActivationRequest
We have a int actionId and a uint window timestamp in porting somehow
these had got swapped and renamed. This now matches the relevant DBus
signal they connect to.
Open correct acton sub-menu on loading
So pressing alt+e will open the edit menu immediately when showing the
application menu.
Also remove existing leftover code that did this which is using a member
var which was previously never set.
Test Plan:
Had the relevant emit patch in plasma-integration
Pressed alt+e, got the edit menu
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4832
Summary:
This not only makes the code cleaner but more importantly avoids plasma
making a blocking DBus call to a client in the QDBusInterface
constructor
which does a blocking call to Introspect
Test Plan: Ran my test app with the dynamic menu. Everything was still
fine
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4172
Summary:
Then update appet, SNI, and appmenu appropriately which are only care
about the root menu.
This fixes some premature showing and re-evaluation.
Test Plan:
Ran statusnotifiertest and checked submenu worked
Ran applet and checked everything was still fine
Restarted kded and checked window decoration menu
Reviewers: #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4161
Summary:
See comment at the top of createAction
Reduces the number of warnings in updateAction about unhandled
properties
Test Plan: Still works
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4088
Summary:
The previous code worked as follows:
- when we show a menu we would emit aboutToShow on the root item
- we would then recursively load the /entire/ menu structure before
emitting we were done.
Because we only sent aboutToShow on the root menu, any clients that were connected to
a submenu's aboutToShow never got an aboutToShow signal.
This patch does the (in retrospect far more obvious) fix of just
calling aboutToShow dynamically on each submenu when it's time to show,
then updating the menu whilst it's showing.
Test Plan: Dynamic menus now work, DBus traffic is considerably down
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4059
Summary:
When updating a menu we would always delete all the actions and recreate
them.
This caused a problem that we would also be deleting submenus and
recreating them, meaning when we update the applet's submenu before
showing it, our submenu will always be destroyed.
This patch uses the DBusMenuItem IDs to re-use existing QAction / QMenu
objects and only create new instances when needed. It should also be (in
theory) faster as there's a lot less object creation every update.
Also replace QSignalMapper with a lambda and replace replace QMap<int,
QPointer<QAction*> with QMap<int, QAction*> and a lambda to do cleanup
on deletion.
Test Plan:
Tweked the applet to update before showing
Original QMenu object used before showing still has all the items
Reviewers: #plasma
Subscribers: broulik, markg, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4057
Summary:
libdbusmenu-qt had a quirkin it that meant it would spawn a nested
event loop when updating a menu.
In order to fix StatusNotifierItem I ended up making a fork of the 3
small classes that we needed and applying a fix, whilst we waited for
upstream.
We also were including a complicated library+plugin that handled import
and exporting, just to do importing which is rather pointless.
When appmenu support was restored, we ended up re-linking the original
dbusmenu-qt library. The original still had the same bug, manifesting in
a whole new way of Kate's bookmarks menu automatically closing when you
click on it.
This patch shares the same libdbusmenu-qt lib we have for the SNI
dataengine with the one for appmenu.
Test Plan:
Everything compiles after removing the find package for old libdbusmenu-
qt
Menu in the Plasma applet works a lot better, and doesn't have the bug
of menus randomly closing.
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D3926
This contains a temporary fork of the importer, with the main paths
fixed.
The old code spawned a new event loop in the signal QMenu::aboutToShow()
This refetched the menu, even though we had already fetched it, before
calling show.
Spawning new event loops from a QML function, leads to all sorts of
crashes. This
fixes that, and saves some pointless DBus traffic
BUG: 343971
BUG: 345838
BUG: 345933
REVIEW: 123992