We were not looking into the plugin directory when figuring out the applet
path when it's load from an absolute path.
Fixes configmodeltest
REVIEW: 129101
Makes it possible to use plugins that offer a metadata.json file.
Define the service type when falling back to the desktop file parser, so
the type system is proper.
Don't destroy a KPluginMetadata tuple to instanciate it right away.
REVIEW: 129102
Commit 752626ad55 left a code path through
the switch statement where defaultActionsCfg would be an invalid group.
This is semantically correct as there is no relevant actions config for
this type of containment, however we then call methods on it which leads
to an assert in kconfig - and a failing unit test.
REVIEW: 129096
It's reasnoble to expect people to download an applet just before trying
to change an existing applet using the alternatives system.
Therefore doing the check at applet initialisation time is semantically
wrong. Especially as it doesn't just disable the action but also skips
creating it.
Finally this gives a startup performance boost; loading all the applets
metadata takes a small amount of time (~20 milliseconds) not really
noticable when you're doing it once, but it adds up if you're doing it
over multiple applets sequentially.
Show times where 0 is the beginning of the process
Use QDebug to get QVariant's values
Delay constructor print so that we know which class is being constructed
Use QJsonObject instead of going back and forth with QVariantMap
Reviewed by David Edmundson
The 'qml-plasmoid' is excluded on purpose in this case, since the file
has many translations already, and we are too close to the periodic
release date of frameworks: this means extracting it now would remove
all the existing translations, giving a couple of days only to
translators to provide them back.
Once version 5.27.0 is released, this restriction will be lifted, as
there will be plenty of time to translate everything back.
According to [X.org
docs](http://www.x.org/releases/X11R7.7/doc/compositeproto/compositeproto.txt)
regarding NameWindowPixmap:
"This pixmap will remain allocated until freed, even if 'window' is
unmapped, reconfigured or destroyed. However, 'window' will get a new
pixmap allocated each time it is mapped or resized, so this request will
need to be reinvoked"
So, pixmap needs to be discarded not only on XCB_CONFIGURE_NOTIFY event
but on XCB_MAP_NOTIFY event also.
The svg elements cache isn't really a "configuration" and it's not
something that should be overridden by global config settings.
Loading it as a simple config skips the cascading and saves reparsing
kdeglobals.
REVIEW: 128966
when the view is in SizeRootObjectToView mode, the root
object is resized in the event handler, that is too late at startup.
resize the root object right after having announced
the new containment, so the view subclass can have
the view resized to the proper size beforehand,
removing an useless containment graphicsobject resize.
REVIEW:128915
running tasks need to have some visual indicator,
otherwise is impossible to distinguish between
tasks and launchers in icontasks
Change-Id: Ib1c319c675855a605d8a268bad2bb43ad19a6e4d
WindowThumbnail did some open GL operations, discarding old textures, in
the GUI thread. Whislt it's not going to cause a threading issue (as
updatePaintNode always ran when the main thread was blocked) we're not
meant to mix threads with openGL contexts.
It also seems to have a GL leak on nvidia, which was previously masked
by the double delete fixed in
https://git.reviewboard.kde.org/r/126131/diff/2/
It seems only one worked, and in the applied version we went with the
wrong one.
This patch makes use of QQuickItem::releaseResources to delete the GL
textures on window change and destructor; it's then removed from
stopRedirecting so that start/stop redirecting handles xcb on the GUI
thread and updatePaintNode/discardPixmap is the GL stuff on the render
thread.
See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
REVIEW: 128763
BUG: 368066