In many cases it's irrelevant, what we care about is whether given effect
is loaded and performs its function. So remove these paranoid checks
except the tests where it's important to use OpenGL compositing.
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.
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.
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.
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.
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.
Currently windows are scattered in a few separate lists. If you need to
go through the windows, you have to do it piece by piece. On the other
hand, with the overhaul of window types, we've started converging
towards one universal type: Window. Keeping windows in the separate
buckets goes against this design.
Workspace::stackingOrder() already contains all windows. This change
repurposes Workspace::allClientList() from a list of "normal" windows to
all windows, i.e. Workspace::windows(), to be consistent.
There's one API change though. Scripting API will expose other window
types too. This is an intentional change so scripted effects could
operate with all windows. It also matches the current behavior observed
in libkwineffects, which exposes all windows as well.
Currently Deleted are destroyed with a delay to avoid dangling pointers
within the middle of painting.
On the other hand, it's reasonable to require not to delete windows when
kwin starts painting the screen.
Over the years, we refactored how deleted windows. They are always
unreferenced after finishing the current frame. So it should be fine to
destroy Deleted immediately now.
Use input device specific apis to change the position of the cursor. The
main reason to do so is to break the assumption that Cursor position is
the same as pointer position, which I would like to rely on later to
merge tablet and pointer cursors.
The test waits longer than needed to determine whether effects stopped
playing animations
Before
Executed in 22.41 secs fish external
usr time 997.42 millis 722.00 micros 996.70 millis
sys time 744.81 millis 79.00 micros 744.73 millis
After
Executed in 9.71 secs fish external
usr time 894.42 millis 1.03 millis 893.38 millis
sys time 689.80 millis 0.11 millis 689.69 millis
We use the PMF syntax so the isValid() check is unnecessary as the
compiler will notify about wrong signal at compile time. It makes
writing autotests feel less boilerplaty.
This enables again the crossfade between the old window picture and the new one in the maximize and morphingpopup effects.
It does that with the OffScreenEffect redirect() feature.
BUG:439689
BUG:435423
Things such as Output, InputDevice and so on are made to be
multi-purpose. In order to make this separation more clear, this change
moves that code in the core directory. Some things still link to the
abstraction level above (kwin), they can be tackled in future refactors.
Ideally code in core/ should depend either on other code in core/ or
system libs.
With fractional scaling integer based logical geometry may not match
device pixels. Once we have a floating point base we can fix that. This
also is
important for our X11 scale override, with a scale of 2 we could
get logical sizes with halves.
We already have all input being floating point, this doubles down on it
for all remaining geometry.
- Outputs remain integer to ensure that any screen on the right remains
aligned.
- Placement also remains integer based for now.
- Repainting is untouched as we always expand outwards
(QRectF::toAdjustedRect().
- Decoration is untouched for now
- Rules are integer in the config, but floating in the adjusting/API
This should also be fine.
At some point we'll add a method to snap to the device pixel
grid. Effectively `round(value * dpr) / dpr` though right now things
mostly work.
This also gets rid of a lot of hacks for QRect right and bottom which
are very
confusing.
Parts to watch out in the port are:
QRectF::contains now includes edges
QRectF::right and bottom are now sane so previous hacks have to be
removed
QRectF(QPoint, QPoint) behaves differently for the same reason
QRectF::center too
In test results some adjusted values which are the result of
QRect.center because using QRectF's center should behave the same to the
user.
The .clang-format file is based on the one in ECM except the following
style options:
- AlwaysBreakBeforeMultilineStrings
- BinPackArguments
- BinPackParameters
- ColumnLimit
- BreakBeforeBraces
- KeepEmptyLinesAtTheStartOfBlocks
[5/6] Make autotests create fake input devices
Migrate all input simulation functions from kwinApp()->platform()->...
to the their counter part in the Test namespace.
It's not practical, regular users don't care about window geometry. One
could argue that it can be useful for creating window rules, but window
rules kcm pulls relevant properties from kwin.
If needed, one can reimplement this feature as a QtQuick script that creates
an overlay window positioned above the window that is being interactively
moved or resized.
Currently, if a window switches between SSD and CSD, it is possible to
encounter a "corrupted" state where the server-side decoration is wrapped
around the window while it still has the client-side decoration.
The xdg-decoration protocol fixes this problem by saying that decoration
updates are bound to xdg_surface configure events.
At the moment, kwin sort of applies decoration updates immediately. With
this change, decoration updates will be done according to the spec.
If the compositor wants to create a decoration, it will send a configure
event and apply the decoration when the configure event is acked by the
client. In order to send the configure event with a good window geometry
size, kwin will create the decoration to query the border size but not
assign it to the client yet. As is, KDecoration api doesn't make
querying the border size ahead of time easy. The decoration plugin can
assign arbitrary border sizes to windows as it pleases it. We could change
that, but it effectively means starting KDecoration3 and setting existing
window deco ecosystem around kwin on fire the second time, that's off the
table.
If the compositor wants to remove the decoration, it will send a
configure event. When the configure event is acked and the surface is
committed, the window decoration will be destroyed.
Sync'ing decoration updates to configure events ensures that we cannot
end up with having both client-side and server-side decoration. It also
helps us to fix a bunch of geometry related issues caused by creating
and destroying the decoration without any surface buffer attached yet.
BUG: 445259
It's more common to see the parent object being the last argument in Qt
and this way you won't need to specify nullptr parent explicitly if the
xdg-popup or the xdg-toplevel surface doesn't need to be configured
implicitly, which makes tests slightly easier to read.
The main idea behind the render backend is to decouple low level bits
from scenes. The end goal is to make the render backend provide render
targets where the scene can render.
Design-wise, such a split is more flexible than the current state, for
example we could start experimenting with using qtquick (assuming that
the legacy scene is properly encapsulated) or creating multiple scenes,
for example for each output layer, etc.
So far, the RenderBackend class only contains one getter, more stuff will
be moved from the Scene as it makes sense.
