Toplevel::debug() is one of annoyances that you need to deal with when
implementing a new client type. It can be tempting to just write "this"
to the stream, but it will result in a crash.
In order to make implementing new client types easier, this change
introduces a debug stream insertion operator overload that works for all
kinds of the Toplevel class.
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
Summary: Provide for KWin scripts the possibility to work with a activities aware ClientModel. In the same way that the ClientModelByScreenAndDesktop works with virtual desktops.
Reviewers: #kwin, mart, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D29284
Summary:
Currently each managed X11 client is represented with an instance of
Client class, however the name of that class is very generic and the
only reason why it's called that way is because historically kwin
was created as an x11 window manager, so "Client" was a sensible choice.
With introduction of wayland support, things had changed and therefore
Client needs to be renamed to X11Client in order to better reflect what
that class stands for.
Renaming of Client to X11Client was agreed upon during the last KWin
sprint.
Test Plan: Compiles, the test suite is still green.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24184
Summary:
In 403038 the user expected the DBus call to run to finish before
processing the next request. For a singleshot script that makes a lot of
sense, otherwise you have no idea when it finishes.
This also allows us to return errors.
CCBUG: 403038
Test Plan:
NUM=$(qdbus org.kde.KWin /Scripting org.kde.kwin.Scripting.loadScript /noFile.js Minimize)
qdbus org.kde.KWin /$NUM org.kde.kwin.Scripting.run
Error: org.kde.kwin.Scripting.FileError
Could not open /noFile.js
Running a real script behaved effectively the same as before.
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18127
Summary:
KWin::Script::loadScriptFromFile ran in it's own thread and accessed
member variables of KWin::Script without any guards.
Potentially script could be destroyed whilst the file is loading.
Rather than adding mutexes everywhere, this patch scopes the QFile
object to be local to the threaded function making it independent.
BUG: 403038
Test Plan: Ran a script from a file
Reviewers: #kwin, graesslin
Reviewed By: #kwin, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18126
Summary:
Qt render loops behave quite differently to each other.
KWin scripting as a workaround for another situation cleans
(17553e5a1f) handles tracking of script
windows by deleting the underlying window handle on hide.
This currently happens before the window gets the hideEvent.
Arguably this is a quirk with Qt, but in the current state:
- QSGThreadedRenderLoop deletes the platform window and cleans up
- We then get the hide() event. This no-ops because there's no window.
(else branch of case WM_TryRelease in qsgthreadedrenderloop.cpp)
- We carry on rendering animations despite having no platform
- undefined behaviour
Normally this isn't a problem as typically destruction of the platform window
happens only when a window is being deleted, we're messing with Qt
internals here.
If we make sure the QHideEvent is processed by the render loop first,
things seem fine.
BUG: 397767
Test Plan:
Ran QSG_RENDER_LOOP=threaded
Read output with scenegraph logging rules on
Reviewers: #kwin, broulik
Reviewed By: broulik
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15025
I did some research with the result that such comparisons are indeed
not standardized to be legal before C++14. In C++14 they are.
These microoptimizations can thus be re-enabled when C++14 becomes
the required version.
Summary:
Exposes two new global JS functions to register and unregister touch
screen edges.
Test Plan: Added test case
Reviewers: #kwin, #plasma
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D5277
The export of the WorkspaceWrapper was changed to be a subclass with all
the elements still being in the parent class. But the "workspace" was
exported with QScriptEngine::ExcludeSuperClassContents. Thus all usages
of workspace were broken and our tests started to fail on build.kde.org.
This change removes the ExcludeSuperClassContents which means that also
the QObject properties and slots are now exposed which was previously
not the case.
CCMAIL: github@chilon.net
Summary:
The version provided is only compatible with QtScript so it became
necessary to split WorkspaceWrapper into a base class and two child
classes, one for QtScript and one for QmlScript.
BUG: 340125
FIXED-IN: 5.8.4
REVIEW: D3185
Summary:
registerShortcut is available to javascript KWin scripts but was not
available to those written in declarative script.
BUG: 340225
FIXED-IN: 5.8.4
REVIEW: 129250
Summary:
It was consistently wrong so it worked before, but not having a typo is
better.
Test Plan: Compiles, grepped that it's not invokable/public
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2266
Summary:
This change introduces a Scripting::findScript method which returns
the AbstractScript. Thus a test can load a script, retrieve it and
trigger run on it. As the test would also need to know when finally
the test is running a signal is introduced to notify about it.
This makes the scripting ScreenEdgeTest way more reliable. The test
had been failing on both build.kde.org and build.neon.kde.org due to
not knowing when the script is loaded.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2497
-use qstringliteral only when necessary (i.e. not in concat or comparison)
-use qbytearray instead of qstring when dealing with latin1 input and output (glplatform)
-use qstringref to extract numbers from strings (glplatform)
-define qt_use_qstringbuilder to optimize all string concatenations
-anidata: use ctor init lists, add windowType member initialization
REVIEW: 125933
According to the documentation the ownership of a QObject created by
QQmlComponent::create is transferred to the caller.
This fixes a crash on KWin tear down.
REVIEW: 118345
Instead of having it's own QQmlEngine TabBox just uses the newly
exposed engine from Scripting and creates a new context for it's
own usage.
REVIEW: 116565
Instead of having each declarative script create it's own qml engine
there is one hold by the Scripting singleton. The engine's root context
gets populated in Scripting and each script just gets a new child
context. Thus also the WorkspaceWrapper instance is shared between the
declarative scripts.
A declarative KWin script needs to register the QQuickWindows it is
using in the KWin object. This method ensures that the QQuickWindow
will destroy the platfrom window once it gets hidden. So the next
time the QQuickWindow is shown a new platform window is created.
As can be seen in the OSD this is not really nice, therefore a
KWin.Dialog should be created which takes care of these steps.
The DBusCall is exported as a QObject to the QML environment. It is
intended as a declarative replacement for the callDBus method which used
to be exported on global scope in the QtQuick 1 world.
Example usage:
DBusCall {
id: dbus
service: "org.kde.KWin"
path: "/KWin"
method: "setCurrentDesktop"
arguments: [1]
Component.onCompleted: dbus.call()
}
Getting all functionality from old solution into new one is not really
possible. Main problems are that QtScript provided more functionality
than the QJSEngine. For example it's no longer possible to just export
functions to the engine. We need to have a Qt wrapper object. At the
moment this wrapper object doesn't export all functions as the callbacks
are tricky. A solution might be to create specific QML types
encapsulating functionality which used to be exported on the functions.
Nevertheless a basic QML script loads and works and the ported readConfig
function works, too.
AbstractThumbnailItem inherits from QQuickPaintedItem using QPainter to
do the fallback painting of icons.
The scene is adjusted to get the information from QQuickItem instead of
QDeclarativeItem. Clipping got a little bit more complex as the clip
path does not exist any more. To get it right the ThumbnailItem needs to
specify the parent it wants to be clipped to with the clipTo property.
E.g.:
clipTo: listView
The scene uses this clipTo parent item to correctly calculate the clip
region. Also the ThumbnailItem needs to have clipping enabled.
Note: this commit currently breaks TabBox as the qml and view are not
yet adjusted. In scripting the export of the item is disabled, but any
qml script using a ThumbnailItem would obviously also fail.
Not sure why kdeclarative gets its own subdir, nor why
there is no CMake module to to add it to the include dirs
on find_package, but this matches what plasma-framework
does at the moment.
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
Let KDeclarative::setupBindings() add the import paths: it too takes
paths from KGlobal::dirs()->findDirs("module", "imports"); it adds paths
in the correct (reverse) order [1].
[1] See kdelibs 400b9f2e9d10386bb175b6123fe0cdaafeaffe61 for further
details.
REVIEW: 110670
Vlad Zahorodnii