It's been a long time since I've worked with this code, but IIRC move
transition isn't even used. Certainly displaced
was needed to fix the scaling issue when items were added quickly (especially at startup).
OK, I'll close it mentioning your MR.
@iasensio what about move
animation? IMO it should be disabled as well - it feels like it was the root cause, because on your screenshot icons positions are shifted, not scale.
Other solution would be to add x,y
properties animation to displaced
. Check this for more details:
https://doc.qt.io/qt-6/qml-qtquick-viewtransition.html#handling-interrupted-animations. On second thought maybe not, in this situation, but I keep this link here for reference.
@iasensio Does it fix this? https://bugs.kde.org/show_bug.cgi?id=478112
When compiling KWin from master (Qt6) on KDE Neon (based on Ubuntu 22.04) with mesa upgraded using Kisak Mesa PPA CMake fails with this error:
-- Found gbm: /usr/lib/x86_64-linux-gnu/libgbm.so (found version "23.0.3;-;kisak-mesa;PPA")
CMake Error at CMakeLists.txt:239 (if):
if given arguments:
"23.0.3" "-" "kisak-mesa" "PPA" "GREATER_EQUAL" "21.1"
Unknown arguments specified
This dataengine can be dropped. It was used only in System Tray, but no longer is: https://phabricator.kde.org/T13319, !836 (merged). I kept it in Plasma 5 only for compatibility, but should be removed in Plasma 6: !836 (comment 236398)
BTW, kde/workspace/plasma-workspace/dataengines/statusnotifieritem/
is deprecated and not used. Code was copied to kde/workspace/plasma-workspace/applets/systemtray/
, old code is still there, it was decided to keep it in Plasma 5. It should be removed in Plasma 6.
I wonder if there is any chance to distinguish XEmbed icons so different context menu open policies can be used. IIRC it should be possible. XEmbedSNIProxy does not register menu object - it handles ContextMenu operation directly.
Check plasma-workspace/applets/systemtray/statusnotifieritemsource.cpp -> contextMenu()
. It checks if m_menuImporter
is available, if not it falls back to "ContextMenu"
operation. You can add new role to StatusNotifierModel
, something like hasMenu
with boolean value true if StatusNotifierItemSource->m_menuImporter != null
. Then in QML you can check it - if menu is available then you can safely show it in onPressed. If not, it has to fallback to "ContextMenu" operation, which has to be called in OnClick
(because GTK3 will check mouse state).
There is a lot happening here. Preferable we want menu shown on mouse pressed, so that it is consistent with other right-click menus (discussed here): https://phabricator.kde.org/D22804
For plasmoids this is working fine. SNI has some issues:
GTK3 apps usually use libappindicator, which create proper SNI item (registered in DBus). But some systems do not have libappindicator or it is not available (statically compiled apps? sandboxed apps?). Then GTK3 falls back to legacy XEmbed with mouse validation. Gtk2 and Wine is IIRC not affected - you can send spoofed signals and they don't care.
Additionally, emitPressed is part of different feature. It is part of the effort to pass mouse signals to plasmoids, for example middle button click mutes volume. We need to call onPressed but there is also a property named 'pressed' which shadows onPressed in QML in Qt 5. Maybe this won't be needed in QML in Qt 6.
OK, then let's go with your approach then. I totally agree that icon name should be preferred, this makes much more sense. I wonder by this was done in the opposite way... but that does not matter much now.
I didn't test your change, so make sure you check all combinations - there is a test application in plasma-workspace/applets/systemtray/tests/statusnotifier/
. IIRC there is an existing problem with overlay icons, some combinations do not work correctly.
Instead of changing C++ backend it is better to move all the logic to QML. This way you can use PlasmaCore.IconItem
which IIRC has all the error handling, fallback etc. The only thing missing is icon theme path. It was even discussed here: https://phabricator.kde.org/D28208 - that was never finished. There was a plan to move to QML, I wanted to do that but few things happened and I didn't have enough time :( We were also limited by the use of dataengine which cannot be modified as it is part of the API. We no longer use dataengine (which is deprecated anyway), all the code is hosted internally in the systemtray. It is just a simple copy but now it is possible to do some cleanup and migrate to QML.
Instead of mocking the settings class use the real class with an artificial config file
Konrad Materka (a02d1ca2) at 25 Feb 08:40
It should be fine now, I'll test tomorrow. Note to myself: do not make commits after midnight...
Konrad Materka (a02d1ca2) at 24 Feb 21:48
applets/systemtray: Do not open context menu on mouse pressed for SNI
Konrad Materka (b93f682b) at 24 Feb 21:40
applets/systemtray: Do not open context menu on mouse pressed for SNI
... and 6 more commits
But right-clicking on an applet doesn't bring up the context menu anymore
Oh! I'll check that.
I can reproduce reliably
var job = service.startOperationCall(operation);
job.finished.connect(function () {
plasmoid.nativeInterface.showStatusNotifierContextMenu(job, taskIcon);
});
In other words, while job is being scheduled, mouse up event is ignored. Then the next mouse up on the same panel (like in bug report on the application launcher) sends activated
signal. But I had no time to investigate further.
This was already discussed in the past: https://phabricator.kde.org/D22804