Summary:
this makes the "no borders" option do something: however it cause many
other issues with many themes that weren't really designed for "no
borders"
it fixes the "tiny borders" for almost all themes, as the whole calculation before
was
completely wrong
Test Plan:
Some themes work way better now, some look broken with no border or no side borders
some look perfect with those options
another issue is that aurorae is going to support no borders, it has to support like
breeze resizing from the shadows
Reviewers: #plasma, #kwin, davidedmundson
Reviewed By: #plasma, #kwin, davidedmundson
Subscribers: davidedmundson, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25146
Summary:
Removes a tonne of complex code, means any future improvements to our
QtQuick integration only need to be in one place.
QML logic remains in Aurorae as it does complex things. All other
aurorae specialties remain.
Only functional difference is that we now use a shared GL context
between window frames, which Plasma::FrameSVG will make use of.
Test Plan:
kcmshell5 kwindecoration
ran some aurorrae themes on my kwin. Look the same as master
Reviewers: #kwin, mart
Reviewed By: mart
Subscribers: mart, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D25206
Summary:
Context behaviour subtly changed in Qt5.14 which has exposed some
questionable things in this KCM.
Auorae::Decoration is a context property of the loaded QML.
QObject::~QObject signals it's own deletion before deleting children.
This means the bindings of loaded QML update in particular
aurorae.qml
DecorationOptions {
id: options
deco: decoration
}
DecorationOptions has a pointer to the previously set decoration which
is now dangling, and we crash.
Rather than adding more guards and smart pointers in DecorationOptions,
this patch deletes the QQmlContext before deleting the context
properties that we expose.
It also moves unreferring the shared qmlcontext we inherit from till
after we've deleted the child context, because it didn't make sense.
Test Plan:
Opened KCM
Closed the KCM
didn't crash
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D24594
We have lots of inconsistency at the moment in CMakeLists.txt files. Most
of it is due to kwin being a very old project. This change hopefully fixes
all of it.
Summary:
KWin blits contents into a QImage raster buffer. Because of this we
don't need our underlying GL surface to be double buffered as it
effectively makes the whole thing tripple buffered.
Test Plan: Ran Aurorae, looked the same, should save some memory
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23331
Summary:
Aurorae has a timer between request update and updating the contents.
This makes some sense.
However on initial creation we want to snap the contents immediately as
otherwise we may be out by a frame between a new window being mapped and
the window decoration being rendered.
Test Plan:
Ran with Auroae
Windows opened immediately seemed to have a deco straight away
Reviewers: #kwin, zzag
Reviewed By: #kwin, zzag
Subscribers: zzag, romangg, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D23332
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 only SVG-based decoration themes react to border size changes.
QML-based decoration themes on the other hand, for example Plastik, don't
react to such changes, only new windows will have decorations with the
new border size.
BUG: 408035
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22665
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: QColor::dark() and QColor::light() are obsolete since long time ago.
Reviewers: #kwin, apol
Reviewed By: apol
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D22360
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:
Look there, another plugin I didn't remember. The other qml files are
not needed for the aurorae autotest as it's for the svg based themes
instead of qml themes like Plastik.
Test Plan: Further destroyed my system, test failed, with this change passed.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16761
Summary:
So far we didn't know why plastik wasn't loaded. Now we get the error
messages.
Test Plan: Saw error messages while investigating failing KWin test
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16753
Summary: The tests running Aurorae need to be able to pick up the plastik plugin.
Test Plan: Removed system install of plastik plugin, now test passes
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16752
Summary:
This ensures that DontCrashAuroraeDestroyDecoTest can load the plastik
window decoration when run from build directory as it happens on
build.kde.org.
Test Plan: Test passes now when manipulating XDG_DATA_DIRS to hide system install
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D16745
Summary:
Workaround QtBug-68997
Deleting of a RenderControl/render controlled window triggers deletion
of other queued deleted items, putting KWin in a corrupt state. See Qt
bug report.
Deleting this queued means we know we don't have anything else going on
in the stack which should make this somewhat safe.
BUG: 395346
Test Plan:
Couldn't reproduce original crash. Based purely on the incomplete backtrace and code reading
Set an Aurorae theme. Closed some windows. Things still worked as before
Reviewers: #kwin, #plasma, mart
Reviewed By: #kwin, #plasma, mart
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13614
Summary:
x and y are always relative to the parent, adding parent.width to
calculate the position doesn't make sense.
Original author meant just "x: parent.width-1"
But we may as well just use anchors. Programatically it comes out the
same.
Test Plan:
No more weird vertical lines in the KCM when view is slightly less than 2 previews wide.
Modded colour to hardcoded "red" for easier visualisation, checked it looked ok when set as a real deco.
Reviewers: #plasma
Subscribers: plasma-devel, kwin, #kwin
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9776
Summary:
KWin was quite good in ensuring that you don't need to install by
passing paths to the tests. The new way is much nicer, so code is
adjusted for the new way. Also if we require a newer ECM in future we
need to support the new way.
No guarantee that the tests don't pick something up from the system env,
that needs more testing.
References: https://community.kde.org/Guidelines_and_HOWTOs/Making_apps_run_uninstalled
Test Plan: The tests which loaded helpers pass
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D7543
Summary:
For software QtQuick rendering we want to create a pixmap buffer and
render our contents in there.
m_rendercontrol->grab does this, but also covers the GL side in pretty
much the same way that we were currently doing.
In doing so I found a bug in Qt, that's submitted upstream, and also worked round.
Test Plan:
Tested with forced software mode, could see an Aurorae decorations
Tested without (so normal code), could see an Aurorae decorations
Tested wayland on nvidia with software rendering, didn't freeze
Whether we then end up using GL, painter or xrender rendering is irrelevant
(but I tested two of them anyway)
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, apol, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D8039
Summary:
Aurorae did not render correctly. This change addresses the problem for
both maximized and restored windows.
BUG: 373319
FIXED-IN: 5.10.4
Test Plan: shaded windows with Plastik and SVG based theme
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6719
Summary:
On Wayland aurorae was creating a lot of stress for the system and
basically turning the system unusable in a short time. This was due to
a recursion starting to create OpenGL contexts. The window created a
decoration (aurorae) which created a QQuickWindow. For that KWin creates
an internal window which in turn triggers the creation of a window
decoration and so on and on.
By simply setting the render QQuickWindow as frameless we can prevent
this recursion.
Test Plan: Tested on Wayland and X11. On Wayland the recursion is gone.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6726
