Ensures that e.g. context menus move about with their parents when they
get moved around.
However, as per spec don't re-constrain the window when its positioner
is non-reactive. This change calculates the offset from its parent window
once initially and places the window relative to that whenever the parent
moves.
Only when the positioner is reactive, will it recalculate the placement fully.
BUG: 461994
`Placements::placeSmart` searches for an optimal position for windows, attempting to minimize overlap. The core of this algorithm tracks the
client's height and width in `ch` and `cw`, which have been adjusted by -1. This simplifies logic determining the bottom and right points of a
window when you are starting at the top and left points.
However, this decision requires adjusting that number by +1 when doing the opposite: determining the top and left points when you start with
the bottom and right points.
placeSmart cycles through window locations, searching for acceptable nooks and crannies to fit a window in, nicely. It begins by checking
for places to put the top left corner of the window which abut another constraint. If that fails, it then tries to place the bottom right
abutting a constraining feature.
After finding a suitable bottom (or right) location, the top (or left) location must be determined, requiring the -1 adjustment to be undone.
This patch adds that +1 back in.
# The bug it solves
This error can be seen by opening a bunch of windows that are placed using the "Minimal Overlapping" rule. The open space on the screen will be tiled from left to right, and then top to bottom in the windows. Once no more windows can be placed like that, the next window will be placed at the extreme bottom-right corner. However, it will be one pixel too low and one pixel too far to the right---if you try to move the window, it will "snap" to the correct spot.
This single pixel may seem minor or even irrelevant, but when you use the "Present Windows" desktop effect on a multiple-monitor setup, this one pixel will cause the window to show up on both monitors.
* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
There are use cases for the headers to be used, e.g. when implementing
wayland-specific workflows from an Effect.
In order to be able to use these, we also need to expose libkwin to be
imported as it carries the interfaces' symbols.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
Static plugins being linked with shared libraries doesn't work smoothly.
POSITION_INDEPENDENT_CODE target property needs to be set for
every such plugin. However, there can be targets that we have no control
over, which need POSITION_INDEPENDENT_CODE to be set too. Asking such
projects to add this property and them refusing to do so would be
reasonable because kwin's entire static plugin pipeline is weird.
The test framework was made a shared library because kwin build
directory used to get really big (in 10s of gigabytes).
Due to the -fPIC issues, this change makes the test framework a static
lib again. Obviously, this brings back the big build directory problem.
But, it's not as terrible as it used to be. With this change, kwin build
directory is a couple of gigabytes in debug build, which is a lot but
not as bad as it used to be before.
The InputConfig was introduced to handle tests that don't have valid
kwinApp object. Those tests have been either reworked or dropped, so
let's drop the InputConfig to tidy the config stuff.
Interactions with KScreen cause settings to be reset to the default when the lid
gets closed, so handling lid closing in KWin needs to wait until KScreen no longer
writes configs
BUG: 471282
This change makes the EffectsHandler emit the windowAdded signal as soon
as the Workspace::windowAdded signal is received and minimize the
difference between the states observed in kwin core and effects.
The test is flaky. We work around it by passing --repeat until-pass, but
lately even it doesn't help us with this issue.
So skip the test when running it inside KDE CI for a few months until
it gets a newer kernel.
It makes decorations lighter as they don't need to bundle its
configuration logic.
Deprecates the kcmodule property in favour of kcmoduleName which instead
of assuming that the kcm is local to the plugin, it provides the plugin
name to find and load.
The Effects API has one signal screenEdgeApproaching with effects
monitoring the last signal to stay in sync.
If an Edge is destroyed whilst visible, effects currently do not get
notified and it can stay there forever.
This patch emits screenEdgeApproaching if appropriate with a factor of 0
when an edge is destroyed.
BUG: 403354
StrutsTest::testLeftScreenSmallerBottomAligned() used to pass because
one of the previous tests changes the maximize policy to maximize.
A window will be maximized only if it's larger than the maximize area
but smaller than the screen area. That's not the case and the test makes
an incorrect assumption about how X11Windows are placed.
Make the total padding between windows equal to the padding against the
screen borders by applying just half of it on the common borders.
Adjust tests accordingly.
BUG: 469720
FIXED-IN: 5.27.6
Use CursorSource::image() instead.
Cursor caching in the ScreenCastStream has been changed so
QImage::cacheKey() is not being used. This is rather a preparation for
making kwin grab the contents of the cursor scene.
This change introduces InputDevice::pointerFrame(). The main motivation
behind it is to allow batching multiple pointer events within a single
event frame.
BUG: 454428
Qt requires xcb-icccm 0.3.9. On the other hand, 0.3.9 contains all the
types and functions used by kwin, so remove the corresponding
XCB_ICCM_FOUND checks to simplify the code.
The quick tile test waits 1s to ensure that the quick tile combine timer
is not active. On the other hand, if the active window changes, it makes
sense to reset quick tile combine status. That also lets us get rid of
the QTest::qWait() in QuickTilingTest::testShortcut().
The test used to verify that kwin doesn't crash when ShellClient sets
new geometry. ShellClient used to access decoration borders without
checking whether decoration() is null.
On the other hand, we've added a bunch of new test cases in
testXdgShellWindow, so let's remove this one. If the bug is back, that
test will fail.
The test needs OpenGL in order to ensure that the window view effect is
loaded and it registers a screen edge. On the other hand, we could
register a screen edge ourselves and thus allow running the test on
freebsd.
testXdgShellWindow already tests intricate subsurface size changes. The
surface pixmaps are handled differently now too, so the test is not
useful as it used to be 4 or 5 years ago.
Before Deleted merge, it used to be equivalent to waiting until the
window is closed.
This fixes tests waiting until the window closing animation completes
and the Window object is destroyed.
testPointerInput requires OpenGL compositing because it wants to test
cursor push back in the window view effect and the window view effect is
available only if OpenGL is supported.
On the other hand, ScreenEdgesTest::testPushBack() already tests similar
scenario, so let's drop relevant test in testPointerInput to allow
running it when using software rendering.
The virtual backend uses the surfaceless platform. On the other hand, we
move in a direction where the graphics buffer type is explicit, which
creates issues for the virtual backend.
This change ports the virtual backend to gbm so we could manually
allocate dmabuf buffers in order to unify buffer handling in kwin.
Its main drawback is that you won't be able to use the virtual backend
on setups without render nodes. On the other hand, given that the
compositor is meaningless without clients being able to share buffers
with it, it's reasonable to require some way to create and export prime
buffers.
