Summary:
Current implementation of buildQuads assumes that corner shadow tiles
are always present:
const QRectF leftRect(
topLeftRect.bottomLeft(),
bottomLeftRect.topRight());
but that assumption is wrong. For example, if the default panel is on
the bottom screen edge, then the calendar popup won't have the
bottom-left shadow tile(at least on Wayland). Which means that the left
shadow tile won't be visible because
topLeftRect.left() == bottomLeftRect.right().
Corner rectangles only have to influence height of the left/right tile
and width of the top/bottom tile. Width of the left/right tile and
height of the top/bottom tile should not be controlled by corner tiles.
Overall, this is how shadow quads are computed:
* Compute the outer rectangle;
* Compute target rectangle for each corner tile. If some corner tile is
missing, move the target rectangle to the corresponding corner of the
inner shadow rect and set its width and height to 0. We need to do
that to prevent top/right/bottom/left tiles from spanning over
corners:
{F6190219, layout=center, size=full}
We would rather prefer something like this if the top-left tile is
missing:
{F6190233, layout=center, size=full}
* Fix overlaps between corner tiles;
* Compute target rectangles for top, right, bottom, and left tiles;
* Fix overlaps between left/right and top/bottom shadow tiles.
Test Plan:
* Ran tests;
* Resized Konsole to its minimimum size(on X11 and Wayland);
* Opened the calendar popup(on X11 and Wayland):
Before:
{F6190344, layout=center, size=full}
After:
{F6190346, layout=center, size=full}
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: abetts, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14783
Summary: At least one test requires the physical size to be set.
Test Plan:
Lock screen screen edges test is passing again. Without the change the corner
offset in the ScreenEdges class is not calculated correctly via the
physicalDpiX() and physicalDpiY() values of an auxilliary QWidget.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15183
Summary:
With the new Output class we can set the gamma directly here. This is also
a stepping stone to adjust individual output gamma adjustment later on.
This means any future backend, which aims to support the color correction
frontend needs to use the Output class.
Test Plan: Night Color test still passes.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11803
Summary:
Let VirtualOutput be a child class of the new generic class Output.
This allows code sharing and a very similar behavior of the Virtual backend
in comparision to the Drm backend.
Test Plan:
Autotests succesful with two exceptions: The decoration input test fails on
testDoubleTap, row topLeft. This is to be expected because now the
ScreenEdgeInputFilter captures the event at position (0,0) before the
DecorationEventFilter can capture it. The autotest was adapted to take this
special case into account.
Also the lockscreen test fails, because the virtual output is currently missing
the physical size yet.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11789
Summary:
Lift high-level properties into new Screens child class for platform plugins
using the Output class.
Directly make DrmScreens a child class of OutputScreens.
Test Plan: Manually and auto tests with 94%.
Reviewers: #kwin
Differential Revision: https://phabricator.kde.org/D11782
Summary:
In order to separate high-level properties of individual outputs from
hardware-specific ones and access these, introduce a new generic class Output.
Also make the DrmOutput class directly a child class of this generic class.
The long-term goal is to get rid of the Screens global object on Wayland and
instead directly work with Output objects on compositing level.
This should enable us long-term to do direct scanout to hardware planes, what
I predict needs this generic output representation at one point.
Test Plan: Manually.
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D11781
Test Plan:
Won't make a practical difference, anything that used before
would have crashed. Only now it's tidier.
Unit tests still pass
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15171
Summary:
In loading tests. Effects are deleted in a deleteLater potentially
outside the scope of our test. Our MockEffectsHandler (which contains
the global static "effects") has the lifespan of the test.
Fixes failing unit test.
Test Plan: Ran test
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D15167
Summary:
While BuiltInEffects has effectData() function, many functions repeat
s_effectData.at(index(effect)), which is what effectData() is doing.
By using effectData(), we'll get rid of those repetitions and maybe make
easier transition to other underlying data structure that stores metadata
for builtin effects.
Test Plan: Compiles, all enabled builtin effects are loaded and working.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13587
(cherry picked from commit 7bfaa6e913)
Summary:
The Dim Inactive effect sees the world a little bit differently.
m_activeWindow is currently active window that can be dimmed later on.
In most cases, it's the same as effects->activeWindow(). In rare cases,
it can be nullptr, even when effects->activeWindow() is not equal to nullptr
(e.g. when active window is a context menu popup).
canDimWindow is a helper that returns true if a given window should be
dimmed, otherwise it returns false. It has one special case: if a given
window is equal to m_activeWindow, return false. I.e. don't dim active
windows.
Currently, if user changes config of this effect, active window becomes
dimmed.
The reason for that is we hit that special case when deciding whether
effects->activeWindow() should be m_activeWindow.
This change addresses that problem by resetting m_activeWindow so we
don't hit that special case.
Test Plan:
* Opened KCM of this effect;
* Changed strength;
* (the KCM window stayed bright after I clicked "Apply" button).
(everything else works as expected)
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14973
Summary:
The Dim Inactive effect was rewritten mostly to fix most of issues with
it, e.g. after leaving a full screen effect(e.g. Desktop Grid) windows
sometimes are not dimmed back, or when a window becomes inactive there
is no smooth transition, etc.
{F5956124}
//Before: the window is not smoothly dimmed.//
{F5956127}
//After: the window is smoothly dimmed.//
In combination with an effect that animates the disappearing of windows,
e.g. Glide, the rewritten Dim Inactive effect doesn't "flash" windows.
If an active window has been closed, it will stay bright. If an inactive
window has been closed, it will stay dimmed.
Among other changes, the KCM has been re-designed to follow common KCM
design in Plasma:
{F5956128, layout=center, size=full}
The way the rewritten Dim Inactive effect handles flashing/flickering problem can be
reused in the Dialog Parent effect.
### Demo
{F5959885}
//Before: dimming of a window group.//
{F5959886}
//After: Dimming of a window group.//
Depends on D13740
CCBUG: 359251
Test Plan:
Test plan #1
* Activated the Desktop Grid effect
* Dimmed windows smoothly brightened
* Left desktop grid
* Windows dimmed back
Test plan #2
* Opened Dolphin and its Preferences window
* Clicked on desktop, both Dolphin and the Preferences window dimmed
* Clicked on Dolphin, both windows smoothly brightened back
Reviewers: #kwin, #plasma, #vdg, davidedmundson
Reviewed By: #kwin, #plasma, #vdg, davidedmundson
Subscribers: davidedmundson, abetts, ngraham, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D13720
stackingOrder is an interesting property which needed
special handling in the port. Add an explicit test.
Test Plan: #kwin
Reviewers: broulik
Reviewed By: broulik
Subscribers: zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14533
Summary:
* Slightly improve readability;
* Check that offset and location have been passed;
* Sanitize slide in/out duration (if any of those is equal to 0, KWin
will crash).
Test Plan:
* Launched Yakuake;
* Pressed F12 several times (Yakuake still slides in/out).
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14862
Summary:
Comments like "// Call the next effect." are sort of
// Add 1 to foo.
foo += 1
they don't give any useful information and it would be better without
them.
Test Plan: Still compiles.
Reviewers: #kwin
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14728
Summary:
We don't have anymore the following effects:
* Box Switch (was removed in 4.11);
* Explosion (was removed in 4.11);
* Outline (was removed in 4.11);
* Scale In (will be removed in 5.14);
* Taskbar Thumbnails (was removed in 4.95).
So, keywords for those effects should not be among search suggestions in
System Settings.
Reviewers: #kwin, #plasma, davidedmundson
Reviewed By: #kwin, #plasma, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14765
Summary:
Using QtQuick.Controls for Label and TextField can result in blurry font rendering for a fractional scaling (e.g. 1,5). There is a work around for QtQuick.Controls 2.x therefore using QtQuick.Controls 2.0 for Label and TextField resolves the problem
BUG: 366451
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: ngraham, zzag, davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14495
Test Plan: Compiles and the Application Launcher is still sliding.
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14823
Summary:
The existing Data struct has some serious problems:
(a) naming is not intuitive, SlideInterface uses more cleaner terminology
so let's use that (and because Wayland is the future);
(b) fadeInTime and fadeOutTime should be slideInDuration and slideOutDuration
respectively. The Sliding popups effect doesn't fade windows, it slides
them;
(c) mWindowsData should be m_animationsData because other parts of this
effect refer to it as "anim data"(e.g. setupAnimData).
This effect uses its own Location enum class instead of KWayland::
Server::SlideInterface::Location because it would be better to not
depend on platform specific data structures.
As a side effect, this change also fixes QHash abuse. The Sliding popups
effect is still hashing windows twice in prePaintWindow and paintWindow.
But I think that's acceptable because usually there would be only one
active sliding window.
CCBUG: 331118
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14301
Summary:
Slided popups are clipped twice:
* first, when filtering window quads in prePaintWindow;
* then, when doing scissor test (the opengl scene plugin does scissor
test for transformed windows).
Because of that, we don't need to filter window quads. Filtering window
quads only adds overhead.
This change simplifies code and "fixes" incorrect clipping when a slided
popup has shadows.
Test Plan:
* Put Plasma panel on the left screen edge;
* Open and close the Application Launcher.
(repeat for top/right/bottom screen edge)
Reviewers: #kwin, davidedmundson
Reviewed By: #kwin, davidedmundson
Subscribers: davidedmundson, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14450
Summary:
Weston does something similar
https://cgit.freedesktop.org/wayland/weston/tree/libweston/compositor-fbdev.c#n315
...and it seems that the non-primary framebuffer devices start completely off. (the screen is off on my Displayport device, and the window for the second vga card in qemu is much smaller than the primary one, and all black for my qemu vm) .
In my testing, sending the ioctl FBIOPUT_VSCREENINFO with a *changed* &varinfo allows it to wake up, and turns on the screen.
doing FBIOGET_VSCREENINFO and then FBIOPUT_VSCREENINFO in my testing does not work.
I think really the values that end up getting changed are varinfo.transp.offset and varinfo.transp.length. at least on the qemu system, but in this patch I am aligning all of them for completeness, because the drivers might do it differently for qemu
Test Plan: This causes the window for /dev/fb1 (remote-viewer, and a qemu vm with two "VGA" (bochsdrm) cards) to resize from the smaller size when specifying it as the --fb-device on seat0, and kwin draws on the device.
Reviewers: #kwin, davidedmundson, graesslin
Reviewed By: #kwin, graesslin
Subscribers: zzag, davidedmundson, rkflx, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D9572
