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
Summary:
As noted by Thomas L we're casting the scaleFactor to an int far too
early, which in the worst case means we end up with Aurorare themes not
rendering.
This moves the rounding to where it's used per border.
BUG: 380524
Test Plan:
Forced Xft.DPI to 95 with xrdb. Confirmed that it was broken
Applied this patch. Got decoration again
Reviewers: #plasma, mart
Reviewed By: #plasma, mart
Subscribers: mart, rikmills, plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D6099
This makes clicking the application menu button trigger the menu.
CHANGELOG: Aurorae window decorations now support global menu button
BUG: 375862
FIXED-IN: 5.9.5
Differential Revision: https://phabricator.kde.org/D5130
Summary:
aurorae themes have hardoded sizes in pixels in their config files,
but the framesvgs scale by themselves based on font dpi leading
to corrupt results
scale all sizes using the same logic(that's also used in c++ based
kdecorations), gives correct looking scaled decorations
BUG:375868
Test Plan: see screenshot
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: plasma-devel, kwin, #kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D5114
Summary:
In the current code we update the shadows during the decoration paint.
Because this is called in the middle of the Scene::paintWindow and we
have already painted the shadows/built quads, the setShadow() was
deferred to avoid the obvious bugs updating the shadow would cause.
This sucks because it means we're always out by one frame, and it means
we always do two updates.
As the shadow is taken from the buffer, we can solve that problem by
updating the shadow before any painting at the same time that we update the
buffer. This means we don't need the deferring hack.
This patch also fixes a related issue that m_padding could have
changed after the buffer is rendered, but before painting. This would lead to rendering a mess.
This patch caches the relevant padding at the time the buffer is
created.
@Notmart, this is subtly different from the patch I showed you last night,
for me it fixes things without your other patch, but I don't know. If it doesn't it's
still (IMHO) a lot cleaner.
Test Plan:
Ran an Aurorae theme
Maximised, restored, resized. Everything.
Reviewers: #plasma, graesslin
Reviewed By: #plasma, graesslin
Subscribers: graesslin, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D4990
