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:
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
Since d51b8dc093 the test fails on CI, apparently because we test with
Breeze default settings, which is no borders now and we can move a bit into
the window geometry and still be on the border if borders exist, otherwise
not.
For now fix it by checking if there are borders or not and then test
accordingly. But long-term we should test both cases and besides not rely on
external decorations for our test, instead use a fake specific for our
integration testing.
Summary:
This is an alternative solution to T8707 and in comparision to D13276 a less
drastic change to KWin's default behavior.
Instead of changing the border size default for all KDecoration plugins by
switching the default from border size Normal to None introduce new
functionality, which allows a KDecoration plugin to recommend a border size in
its metadata. By default KWin listens for these recommendations and sets the
border size accordingly.
If there is no metadata recommending a border size, KWin falls back to the
current setting of Normal sized borders.
A user is able to override the recommendations from the KCM, which has been
extended accordingly.
Test Plan: Manually with adjusted metadata of Breeze.
Reviewers: #kwin, #plasma, #vdg, ngraham
Reviewed By: #vdg, ngraham
Subscribers: hpereiradacosta, filipf, anemeth, davidedmundson, abetts, graesslin, ngraham, zzag, kwin
Tags: #kwin
Maniphest Tasks: T8707
Differential Revision: https://phabricator.kde.org/D13284
Summary:
In KDE 4, there was a very handy option to disable decoration tooltips.
Decoration tooltips were lost in transition to KDE Plasma 5, and so
the option.
Given that decoration tooltips were brought back to KDE Plasma 5, "Show
decoration button tooltips" option can be still useful for people(like me)
who may wish to disable them because of personal preference.
Reviewers: #kwin, broulik, mart
Reviewed By: #kwin, mart
Subscribers: ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D19152
Summary:
the Lookand Feel kcm already applies decorations to kwin, allow to
read them as defaults for the case of distribution customization
where a different lnf with a different deco is wanted
Test Plan: tested to start kwin with a different lnf which loads an aurorae decoration
Reviewers: #plasma, #kwin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D18261
The option NoPlugin allows to disable window decoration plugins. It
used to exist with the old decoration library but got unfortunately
lost during the switch.
This change brings back the option and also allows runtime changes
of the option.
REVIEW: 124708
* Aurorae needs to pass QVariantList args to parent Decoration
* DecorationBridge implementation needs to be a KWIN_SINGLETON
* DecorationBridge needs to be passed with args to created Decoration
A decoration plugin can indicate that it supports themes. For this
the decoration plugin needs to specify in the org.kde.kdecoration2
group of the JSON meta data the following:
themes: true,
defaultTheme: "nameofDefaultTheme"
If the themes key/value pair is present and set to true KWin will
read the entry "theme" in the [org.kde.kdecoration2] group with the
value of defaultTheme as the default value.
The read value (if there is one) is passed to the created decoration
in the QVariantList. The QVariantList contains a QVariantMap as first
entry and the theme name is passed for key "theme".
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
