Summary:
So far we were following a bit unique and rare doxygen comment style:
/**
* Contents of the comment.
**/
Doxygen comments with this style look balanced and neat, but many people
that contribute to KWin don't follow this style. Instead, they prefer
more traditional doxygen comment style, i.e.
/**
* Contents of the comment.
*/
Reviewing such changes has been a bit frustrating for me (so selfish!)
and for other contributors.
This change switches doxygen comment style in KWin to a more traditional
style. The main reason for doing this is to make code review process easier
for new contributors as well us.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22812
Summary:
Currently code base of kwin can be viewed as two pieces. One is very
ancient, and the other one is more modern, which uses new C++ features.
The main problem with the ancient code is that it was written before
C++11 era. So, no override or final keywords, lambdas, etc.
Quite recently, KDE compiler settings were changed to show a warning if
a virtual method has missing override keyword. As you might have already
guessed, this fired back at us because of that ancient code. We had
about 500 new compiler warnings.
A "solution" was proposed to that problem - disable -Wno-suggest-override
and the other similar warning for clang. It's hard to call a solution
because those warnings are disabled not only for the old code, but also
for new. This is not what we want!
The main argument for not actually fixing the problem was that git
history will be screwed as well because of human factor. While good git
history is a very important thing, we should not go crazy about it and
block every change that somehow alters git history. git blame allows to
specify starting revision for a reason.
The other argument (human factor) can be easily solved by using tools
such as clang-tidy. clang-tidy is a clang-based linter for C++. It can
be used for various things, e.g. fixing coding style(e.g. add missing
braces to if statements, readability-braces-around-statements check),
or in our case add missing override keywords.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, apol, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22371
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:
We have a mix of different doxygen comment styles, e.g.
/*!
Foo bar.
*/
/**
* Foo bar.
*/
/** Foo bar.
*/
/**
* Foo bar.
*/
/**
* Foo bar.
**/
To make the code more consistent, this change updates the style of all
doxygen comments to the last one.
Test Plan: Compiles.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18683
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:
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
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:
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
A new sub-directory scripting is added in autotests/integration to
gather all test cases related to scripting.
The first added test case verifies the activation of screen edges. For
that it loads a helper script, which reserves an edge based on config.
When the edge is triggered showing desktop is activated.
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.
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.
The view is never shown or used in any way except to create the
QDeclarativeEngine. So instead of using a view as a wrapper, let's create
a QDeclarativeEngine and a Component and create the script from the
Component.
To have Plasma.Dialog working we also need to add the created script item
to a QGraphicsScene.
The main difference is that the activation of an edge is no longer
broadcasted to all effects and scripts, but instead a passed in slot of
the Effect/Script is invoked.
For this the EffectsHandler API is changed to take the Effect as an
argument to (un)reserveElectricBorder. As callback slot the existing
borderActivated is used.
In addition the ScreenEdge monitors the object for beeing destroyed and
unregisters the the edge automatically. This removes the need from the
Effect to call unregister in the dtor.
BUG: 309695
FIXED-IN: 4.11
A script can register a callback through registerUserActionsMenu to be
informed when the UserActionsMenu is about to be shown. This menu calls
the Scripting component to gather actions to add to a Scripts submenu.
The Scripting component now asks all scripts for the actions, which will
invoke the registered callbacks with the Client for which the menu is to
be shown as argument.
The callback is supposed to return a JSON structure describing how the
menu should look like. The returned object can either be a menu item or
a complete menu. If multiple menu items or menus are supposed to be added
by the script it should just register multiple callbacks.
The structure for an item looks like the following:
{
text: "My caption",
checkable: true,
checked: false,
triggered: function (action) {
print("The triggered action as parameter");
}
}
The structure for a complete menu looks quite similar:
{
text: "My menu caption",
items: [
{...}, {...} // items as described above
]
}
The C++ part of the script parses the returned object and generates
either QAction or QMenu from it. All objects become children of the
scripts QMenu provided by the UserActionsMenu.
Before the menu is shown again the existing menu is deleted to ensure
that no outdated values from no longer existing scripts are around. This
means the scripts are queried each time the menu is shown.
FEATURE: 303756
FIXED-IN: 4.10
REVIEW: 106285
KConfigGroup is not the least thread safe and unfortunately
the KServiceTypeTrader::self()->query() will in doubt create
one if the sycoca database was damaged.
BUG: 303713
REVIEW: 105608
(cherry picked from commit e3edcbcf66b324febcc2014ca4c1fbfa383d8972)
KConfigGroup is not the least thread safe and unfortunately
the KServiceTypeTrader::self()->query() will in doubt create
one if the sycoca database was damaged.
BUG: 303713
REVIEW: 105608
A new global method is exported to perform a remote method call
through D-Bus. The call is always performed async invoking a
callback once the call completed passing through the arguments
received from D-Bus.
Possible code looks like the following:
callDBus("org.kde.kwin", "/KWin", "org.kde.KWin", "currentDesktop", function (desktop) {
print("Current Desktop through D-Bus: ", desktop);
});
REVIEW: 105396
ScreenEdge is changed to emit a signal whenever a screen edge
got activated without an action or effect taking care of it.
A Script can reserve one to many callbacks for an edge and the
callback get's triggered whenever the signal is emitted. On
deconstruction of the Script the edge is unreserved again.
FEATURE: 299275
FIXED-IN: 4.9.0
REVIEW: 104904
A ScriptEngineAgent is added to monitor the execution of a
script. If it ends it stops the script to free resources.
The same is done in case of an exception, just that in this
case the script takes care of unloading itself.
REVIEW: 104871
The I/O intensive reading of the complete KWin Script
file into a QByteArray is moved into a thread.
Evaluating and setting up the script engine is still
performed in the main thread.
REVIEW: 104782
Searching for the scripts to load is performed in an own
thread including unloading of already loaded scripts which
no longer should be loaded.
To ensure that two threads are not trying to load/unload
at the same time a mutex is added to protect the list of
loaded scripts.
REVIEW: 104768
A global method "registerShortcut" is exported to the scripts which
can be used to register a callback to be called when the global
shortcut is triggered.
The shared code between Scripts and Effects is moved into template
functions defined in a new file scriptingutils.h.
REVIEW: 104400
Whenever the KWin configuration is changed, scripting has to unload
scripts no longer loaded and load the scripts which have been added.
For this new methods are introduced to check whether the script is
loaded.
REVIEW: 104037
New global method readConfig is exported to QtScript and declarative scripts.
Config is read from a config group stored in kwinrc called "Script-<pluginname>".
For this the ctors of the AbstractScript and derived classes are changed to also
take the pluginname.
For this the Script class is slightly refactored to have a common
base for JavaScript and QML based scripts.
Why QML bindings? This allows to use QML for example for the
desktop change OSD or for fullscreen effects like Present Windows.
Scripts are found by the KServiceTypeTrader and can now be
enabled/disabled. Loading of config is currently disabled. Will
be made available again after scripted effects are merged.
Unlike stated at several places in the code it is not difficult to
setup the connections to all Clients.
It would have been nice if the failed attempts to connect the Clients
would not have made it into the code as emitted signals which are
nowhere used. Not to mention that like in all places the signals to
inform that a state changed were emitted before the state changed was
performed.
Each KWin Script is also exported as a D-Bus object and can be
stopped (destroyed) and started through D-Bus. Output and errors
are emitted as D-Bus signals. That allows external applications
(e.g. Plasma desktop scripting console) to load a script and print
out the output.
The general interface is exported as /Scripting and allows to load
a new script by file. The script is not directly executed but only
loaded. To execute it the run method on the script object has to be
invoked.
