Summary:
We get the data as a QByteArray we can just ref the original data,
rather than doing a deep copy of the data.
Might save a few cycles when we have an SNI animating.
Test Plan:
Ran an app that I know uses xembedsniproxy which always sends data as an
image
Still had an icon in the system tray as before
Reviewers: #plasma, markg
Reviewed By: markg
Subscribers: markg, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5670
This patch primarily is aimed at applications using libappindicator.
For example:
* Steam
* Discord
* Deluge
libappindicator doesn't provide functionality for raising an application,
but only a context menu. Since it also doesn't even provide the corresponding
DBus method, we use the resulting error to try to display the context menu
instead, which matches the behaviour on Unity and Gnome.
BUG: 375351
Reviewers: #plasma, davidedmundson
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4301
Summary:
If an image is created with no size, QImage::data() points to nullptr.
We then pass this as an argument to memcpy. It doesn't really matter
because we're copying 0 bytes into it, but it's still thrown as an
error.
plasma-
workspace/dataengines/statusnotifieritem/statusnotifieritemsource.cpp:401:12:
runtime error: null pointer passed as argument 1, which is declared to
never be null
Test Plan: Ran it again. No error
Reviewers: #plasma, apol
Reviewed By: apol
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4196
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:
Changes triggered by investigation into a long-running high CPU usage bug with system tray animations. The systray itself had icon name to icon resolution code, which was being triggered (twice) for every icon, every time any icon in the systray was updated. This code was spinning up a KIconLoader on each of these instances, and throwing it directly away. Each one triggered a large quantity of memory allocations and disk scans.
This patch moves the extra bit of "appName" logic from the native part of the system tray to the statusnotifieritem datasource, which already had a stored 'customIconLoader' to handle icon theme paths, and removes the special lookup from the sytemtray applet completely. It also prefers icons provided by the dataengine to doing another lookup (contentious?). This removes all the extra CPU usage outside of the QML scene graph and graphics drivers locally.
This is very much a looking for feedback item - there are things about the icon loading paths I almost certainly haven't appreciated yet, and perhaps preferring loading by icon name in the applet has a another purpose.
BUG: 356479
Test Plan: Have tested locally with kgpg and steam, the two apps I have that trigger the old code path. In neither case, however, did the appName logic produce a different result to the code with just the icon search path in statusnotifieritem.
Reviewers: #plasma, davidedmundson, mart
Reviewed By: #plasma, davidedmundson, mart
Subscribers: davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2986
Summary:
Changes triggered by investigation into a long-running high CPU usage bug with system tray animations. The systray itself had icon name to icon resolution code, which was being triggered (twice) for every icon, every time any icon in the systray was updated. This code was spinning up a KIconLoader on each of these instances, and throwing it directly away. Each one triggered a large quantity of memory allocations and disk scans.
This patch moves the extra bit of "appName" logic from the native part of the system tray to the statusnotifieritem datasource, which already had a stored 'customIconLoader' to handle icon theme paths, and removes the special lookup from the sytemtray applet completely. It also prefers icons provided by the dataengine to doing another lookup (contentious?). This removes all the extra CPU usage outside of the QML scene graph and graphics drivers locally.
This is very much a looking for feedback item - there are things about the icon loading paths I almost certainly haven't appreciated yet, and perhaps preferring loading by icon name in the applet has a another purpose.
BUG: 356479
Test Plan: Have tested locally with kgpg and steam, the two apps I have that trigger the old code path. In neither case, however, did the appName logic produce a different result to the code with just the icon search path in statusnotifieritem.
Reviewers: #plasma, davidedmundson, mart
Reviewed By: #plasma, davidedmundson, mart
Subscribers: davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2986
Summary:
Set the initial values for all the things
This is important as Plasma::DataModel has an unsolvable bug
When it gets data with a new key it tries to update the QAIM roleNames
From QML this achieves absolutely nothing as there is no signal to tell
QQmlDelegateModel to reload the roleNames in QQmlAdapatorModel
No matter if the row changes or the model refreshes
This means it does not re-evaluate what bindings exist (watchedRoleIds)
and we get properties that don't bind for this or any future SNI.
The main source of this problem is syncStatus can occur before
refreshCallback; but whilst that's easy to guard against, there's still
multiple if{} blocks that don't set various keys in refreshCallback()
which would all need changing too. This seemed cleaner and easier to
manage.
BUG: 366283
BUG: 367756
Reviewers: #plasma, mart
Reviewed By: mart
Subscribers: broulik, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D2613
set values that could be null as QString() instead of QVariant
the values so will be there but empty
similarly, set as empty qstrings also missing QIcons,
that's the only way qml can check if it's valis since QIcon is an
opaque type for QML
KIconLoader gained a second argument in KF5 that allows one to pass an
absolute path to a icons to search.
This saves trying to guess the app name, and adding that. This fixes
certain application icons not loading (for example radiotray)
REVIEW: 122384
Quoting the KIconThemes change that lead to this change:
Revert "Revert "Allow passing custom theme base path together with custom app themes""
This reverts commit 6a75883159bbeb9a9316436d428d2617c3b5fc96.
This was never intended to be pushed, it was a local test for the testcase
in RR119058. Sorry for the mixup.
We're back to good now.
CCMAIL:mklapetek@kde.org
CCMAIL:plasma-devel@kde.org
This is needed to build against KIconThemes 6a75883159bbeb9, which
reverts the commit that adds the path to the addAppDir call. From
looking at the API docs, this *seems* to be the right fix, but I don't
know how to test this properly, so I can't confirm that this actually
works. It builds though, and that's at least a step forward.
If someone can test this, that would be very useful.
CCMAIL:mklapetek@kde.org
CCMAIL:plasma-devel@kde.org
Reviewed-by: Eike Hein on IRC
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://community.kde.org/Frameworks/GitOldHistory
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo kde-workspace, frameworks branch, at commit
049113e719dd2fc4446d054fa1a3aada330094f0
Friedrich W. H. Kossebau
David Edmundson
Roman Gilg
Lindsay Roberts
Aleix Pol
Marco Martin
Montel Laurent
Sebastian Kügler
Martin Klapetek