This might be the root cause of random ASAN errors in testQuickTiling.
From commit 617291c6974d232ee99c4c49e891ce16863e3d6e:
The internal EventQueue is a child of the registry object. This means
that after the registry is destroyed, all proxy objects in that event
queue are going to have invalid reference to it, which is not a problem
as long as the wl_display_dispatch() function is not called.
The wl_display_dispatch() function uses wl_proxy's queue reference to
enqueue incoming events to that queue.
Unfortunately, during teardown, the internal ConnectionThread may
dispatch events right after the registry object has been destroyed,
which can lead to a crash.
In order to fix the crash, we need to destroy all proxy objects and only
after that we can destroy the event queue. It's okay if wayland events
are dispatched in between.
i.e. the EventQueue object must be destroyed last to ensure avoid hitting
dangling pointers.
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.
Other policy enums are declared in options.h so let's do the same for
placement policy. Besides consistency, another advantage of moving the
enum in kwin namespace is that the enum could be forward declared.
An application that does not support text-input has no way of
communicating with the input method, so even if you show the input
method the application receives nothing. As a fallback, instead send
fake key events so the application still gets something at least.
The key events are synthesised based on the text string that the
input method sends, which may result in things that do not actually
correspond to real keys. Unfortunately I do not see a way around that.
CCBUG: 439911
Currently, the main user of these two functions is the X11 standalone
platform.
This change ports that code to Workspace::geometry(), which is not great
but the X11 backend already depends on the Workspace indirectly via the
Screens. Not sure if it's worth making the standalone X11 backend track
the xinerama rect internally.
Since the screen number is well-known, we can look up the default
screen on demand. Note that xcb_get_setup() is pretty cheap as it
simply returns a const pointer to pre-allocated data.
At the moment, a platform should provide two output lists - one that
lists all available outputs, and the other one that contains only
enabled outputs. In general, this amounts to some boilerplate code and
forces backends to be implemented in some certain way, which sometimes
is inconvenient, e.g. if an output is disabled or enabled, it will be
simpler if we only change Output::isEnabled(), otherwise we need to
start accounting for corner cases such as the order in which
Output::isEnabled() and Platform::enabledOutputs() are changed, etc.
The Session can be useful not only to the platform backend but also
input backends and for things such as vt switching, etc. Therefore it's
better to have the Application own the Session.
Platform backends are provided as plugins. This is great for
extensibility, but the disadvantages of this design outweigh the
benefits.
The number of backends will be limited, it's safe to say that we will
have to maintain three backends for many years to come - kms/drm,
virtual, and wayland. The plugin system adds unnecessary complexity.
Startup logic is affected too. At the moment, platform backends provide
the session object, which is awkward as it starts adding dependencies
between backends. It will be nicer if the session is created depending
on the loaded session type.
In some cases, wayland code needs to talk to the backend directly, e.g.
for drm leasing, etc. With the plugin architecture it's hard to do that.
Not impossible though, we can approach it as in Qt 6, but it's still
harder than linking the code directly.
Of course, the main disadvantage of shipping backends in a lib is that
you will need to patch kwin if you need a custom platform, however such
cases will be rare.
Despite that disadvantage, I still think that it's a step in the right
direction where the goal is to have multi-purpose backends and other
reusable components of kwin.
The legacy X11 standalone platform is linked directly to kwin_x11
executable, while the remaining backends are linked to libkwin.
The original intention behind creating plugins before the workspace was
to handle the case where kwin_wayland may need to wait until outputs are
available. However, since things have changed a lot in that regard,
plugins can be loaded after the workspace now.
The main benefit behind this is that plugins can be simpler, they won't
need to track when the workspace is created.
On X11, plugins are already loaded after the workspace is instantiated.
This change adjusts the window management abstractions in kwin for the
drm backend providing more than just "desktop" outputs.
Besides that, it has other potential benefits - for example, the
Workspace could start managing allocation of the placeholder output by
itself, thus leading to some simplifications in the drm backend. Another
is that it lets us move wayland code from the drm backend.
We gain nothing with it. XCB setup logic in the Xwayland server has to
be moved to the workspace layer anyway. For example, this move of
responsibilities will be needed to support running more than just one
instance of Xwayland. Architecture-wise, it would be cleaner too.
Unfortunately, it breaks encapsulation of the Application, but this can
be taken care later.
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 Screens object is created by Workspace on X11. This change makes X11
and Wayland behave more similar. As is, the Screens is a helper for
window management code, don't use it in backends. Note that the X11 backend
already uses the Screens, it needs to be addressed individually.
We don't really care about the window showing up until we're calling
showInputPanel, but since Workspace::windowAdded is triggered for any
window that gets added, the test sometimes fails because count() is 2
instead of 1. To avoid that, only create the spy when it's actually
relevant instead of all the way at the start before any other setup is
done.
The IdleDetector is an idle detection helper. Its purpose is to reduce
code duplication in our private KIdleTime plugin and the idle wayland
protocol, and make user activity simulation less error prone.
Firstly we weren't waiting for a signal at all, we are relying on events
being processed externally which is wrong.
Secondly ScreenLocker::KSldApp::self()->lockState() is tri-state;
unlocked, acquiring, locked. This gets compressed to a boolean where
acquiring and locked are the same.
If we run the tests whilst we're still acquiring the lock screen we can
call unlocked before we've finished locking. The greeter might then be
shown afterwards triggering a re-lock. It's a confused state.
Possibility to implement realtime screenedges gestures in scripted effects,
implement it in the windowsaperture show desktop effect.
* Expose registerRealtimeScreenEdge to JavaScript, the callback will be
a JS function.
* Add the concept of freezeInTime() in the animation js bindings,
it will either create an animation frozen at a given time or freeze a running animation
that can be restored and ran to completition at any time
* add an edges property only for showdesktop as it's not directly on the effect configuration
This makes KWin switch to in-tree copy of KWaylandServer codebase.
KWaylandServer namespace has been left as is. It will be addressed later
by renaming classes in order to fit in the KWin namespace.
When we do more color management stuff we'll need it in more places,
making it a hard requirement reduces the amount of needed ifdefs and
should make adding color management features a little simpler.
AbstractOutput is not so Abstract and it's common to avoid the word
"Abstract" in class names as it doesn't contribute any new information.
It also significantly reduces the line width in some places.
Input event flow has been refactored so all input events originate from
input devices.
The X11 backend uses InputRedirection so make it forward events to
relevant input device handlers.
Reduce the code duplication and boilerplate to create and destroy
the test clients by making the related variables class members.
Handle special cases using an extensible flag mechanism.
With this change, the Workspace would provide clientArea() overloads
that take only AbstractOutput and VirtualDesktop. integer ids are
obsolete as they are unstable.
The .clang-format file is based on the one in ECM except the following
style options:
- AlwaysBreakBeforeMultilineStrings
- BinPackArguments
- BinPackParameters
- ColumnLimit
- BreakBeforeBraces
- KeepEmptyLinesAtTheStartOfBlocks
These are two conceptually different tasks that were intertwined.
On it's own it doesn't accomplish anything but is an important refactor
for longer term goals, namely:
- moving xwayland into kwin_wayland_wrapper with our wayland restart
handling support
- having multiple X connections
Behaviour should be the same.
[6/6] Make autotests create fake input devices
This test was the only one where input() could return a nullptr. With
this test removed, autotests can now expect input() to always return a
sane valid value and are therefor simpler to write.
That test belongs in kwayland-server anyway and kwayland-server's test
suite already tests that starting without XDG_RUNTIME_DIR is a no-no
thing
[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.
[4/6] Make autotests create fake input devices
This translates all required input simulating methods from
kwinApp()->platform()->... to seperate functions in the Test namespace.
[3/6] Make autotests create fake input devices
This commit adds back all three VirtualInputDevices for simulating
keyboard, touch and pointer input events from autotests.
[1/6] Make autotests create fake input devices
The goal of this patch set is simulating user input in unit tests via
InputDevices and no longer use the Platform to fake input. This matches
more closely with how input is processed when running a full plasma
wayland session, i.e. with the DRM and libinput backends.
This ensures that we get a warning if the config header is not included
instead of compiling the code as if it was disabled. Interestingly, some
checks already used #if KWIN_BUILD_*, so those were generating -Wundef
warnings when the feature is disabled. Commit 886173cab assumed that all
those features were already 01, so this unbreaks the build if any of the
features is disabled.
Fixes: 886173cab ("Reduce ifdefs in Workspace::supportInformation()")
It's leftover after the times when widget style was using wayland
connection. Breeze had to destroy all wayland resources before
terminating the internal connection.
Xcursor loading code has hardcoded search paths, in order to take into
account distros installing app data in a different location,
libwayland-cursor sets the ICONDIR to the icon directory computed based
on the install prefix.
However, that won't work with gitlab CI because it relocates binaries. A
more robust way to find cursors would be to use QStandardPaths to find
all the icon directories on the system.
Another advantage of using own cursor loading code is that it allows us
to reuse cursor images that are symlinks. For example, with
breeze_cursors, almost half of the files in the cursors directory are
symlinks.
The main disadvantage of this approach is that we would have to keep the
search paths up to date. However, on the hand, there are not that many
of them, e.g. ~/.icons, ~/.local/share/icons, /usr/share/icons,
/usr/local/share/icons. The last three are implicitly handled by the
QStandardPaths.
With the xdg_toplevel.configure_bounds support, the compositor is
finally able to tell the client the maximum recommended window size.
That approach allows us to keep the compositor side simple and it
prevents (as long as the app is well behaved) annoying visual glitches
such as mapping window with one size and then quickly resizing it to
the final size.
There are two operations failing currently, so we QEXPECT_FAIL
them for now:
- A new client is not moved to the screen set by the rule
(Wayland only). Affects Apply, Force and Remember
- Disabling and enabling an output will not move the client
to the Forced screen (On X11 and Wayland, BUG:409979)
If the user wants to move a tiled window, but changes their mind and
tiles the window back to the previous position, the geometryRestore()
will be corrupted because initialMoveResizeGeometry() is the same as the
geometry of the window in the tiled mode.
This change fixes tracking of the geometry restore by precomputing the
geometry restore when starting interactive move. That way, if the window
is untiled and tiled again without release left pointer button, the
geometry restore will be set to the correct value in setQuickTileMode().
This change also adjusts the test suite so such a subtle case won't be
broken again without noticing it.
It can also be applied to client-side decorations. As long as the
compositor can ask the client to use some specific decoration mode, the
"no border" property can be set.
If there's only one configure event that changes the position of the
window and it gets acknowledged but no buffer is attached yet, and a new
configure is sent, then the ConfigurePosition flag won't be inherited
by the new configure event and the window will be misplaced.
In order to fix that, this change makes XdgSurfaceClient pop the last
acknowledged configure event from the m_configureEvents list only when
it's about to be applied for sure.
BUG: 448856
Historically, noBorder() was used for two things:
* as a substitute for AbstractClient::isDecorated()
* to determine whether the AbstractClient should have a decoration
With async decoration updates refactoring, a few things around
noBorder() have changed, which exposed an existing bug in the handling
of borderless maximized windows.
It's possible to have a case where an initially maximized window makes
an xdg_toplevel.set_maximized request before the initial commit, but
creates the decoration object after the initial commit.
Since XdgToplevelClient::userCanSetNoBorder() would return false when
maximize() is called in XdgToplevelClient::initialize(), m_userNoBorder
won't be updated and therefore the window can end up having a server
side decoration.
Previously, it wasn't the case because kwin would do nothing if the
decoration is installed and its preferred mode changes after the initial
commit but before the surface is mapped. With async decoration fixes,
kwin would react as expected, which unfortunately has exposed the bug.
The root cause of the problem is the fact that noBorder() is overloaded,
which makes it error-prone.
This patch changes how the noBorder property is treated. Now, it only
indicates whether the compositor wants the window to have no borders. If
noBorder() is true, it means that the compositor doesn't want the window
to have a server-side decoration; on the other hand, if noBorder() is
false, it doesn't imply that the window should have a decoration.
BUG: 448740
geometryRestore() is no longer updated after mapping the window, so
setQuickTileMode() has to update geometryRestore() explicitly to the
correct value.
With this change, geometryRestore() will be updated as follows:
* if the window is tiled, geometryRestore() is valid, nothing to do
* the window has been dragged to the top edge, set geometryRestore() to
the geometry that the window had when starting move
* otherwise, use the current move resize geometry
dontInteractiveMoveResize() was added to workaround kwin sending bad
configure events when double clicking mpv to make it fullscreen.
With async geometry updates fixed, dontInteractiveMoveResize() can be
finally removed.
Another reason to remove dontInteractiveMoveResize() is that it can make
kwin crash with a debug build. For example, if you enable resizing
maximized windows in breeze decoration settings and resize a maximized
window, kwin would eventually crash in
the AbstractClient::handleInteractiveMoveResize() function because neither
isInteractiveMove() nor isInteractiveResize() return true.
On Wayland, the move resize geometry and the frame geometry are
completely out of sync.
This change synchronizes emitting of the clientStepUserMovedResized
signal to the move resize geometry changes.
It simplifies code of InternalClient and XdgSurfaceClient, and makes
adding support for other shell surface protocols easier as there's less
boilerplate stuff that you would need to take care of.
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.
Same as real hardware wl_keyboard, key should be sent before modifier
change. For example, Left Ctrl press and release should produce
key events in the order of Control_L and Control+Control_L.
Observed in kdevelop, that isEnabled() could be false when switching
between different tabs with Ctrl+Tab. But Qt may still call show()
if you click on the texteditor widget. This leads to isEnabled == false but
setActive(true) is called. This causes kdevelop in a usable state because
keyboard grab will be created and no key event will reach application
because isEnabled == false. Under normal circumstances, key will reach
widget first and triggers another text_input_v2 enable to make input
method work properly.
text-input-v3 does not have preedit styling, instead, it can only
specify the range of cursor. Try to keep track of any
highlight/selection style range and combine them together. If it matches
the cursor position, use it as the cursor range.
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
The output management test checks the implementation of output
management capabilities in the virtual backend, which is not helpful.
This change replaces it with a more useful test that verifies how
windows are placed after an output change.
TestXdgShellClientRules implicitly assumes that the kwinrc config is
referenced only by the RuleBook object.
However, after changing the default placement policy in the
WaylandTestApplication, that's no longer the case. The kwinApp() object
now also holds a reference to the main config file. Because of that,
previous window rules leak to next tests, which breaks them.
In order to address that issue, this change makes TestXdgShellClientRules
open a separate config and wipe it clean after each test run. Not great,
but there doesn't seem to be other way around with current KSharedConfig
api.
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.
Currently, kwin expects that the xdg-decoration is installed before the
initial commit. However, decoration tests do that after the initial
commit, which makes testMaximizeAndChangeDecorationModeAfterInitialCommit()
silently pass.
On a second look, it seems that the xdg-decoration spec is okay with the
xdg-decoration being created after the first commit (as long as it's
done before the surface is mapped). This needs to be fixed separately.
CCBUG: 445259
If the preferred decoration mode changes after the initial commit but
before the surface is mapped, there's a chance that kwin can send a bad
configure event, it's been the case in the past. Add a test to prevent
such cases go unnoticed.
If the decoration is destroyed before the window is mapped, kwin can
respond with a configure event that has 0x0 size. New tests check that
problematic case.
BUG: 444962
Ever since the effects were changed to static, each test of the
integration tests includes all the effects. The result of this is that
when doing a debug build each test is now 60MiB or more. With the amount
of tests, this results in ~8 GiB of diskspace used just for KWin's
binary output directory, which is rather excessive.
Since the tests all share a common framework library, we can change that
library to a shared library and that way avoid linking all the effects
into each test.
Most of this is shuffling around some link libraries in the integration
test CMakeLists, however, I needed to export the Xwayland class as it is
used by one of the tests but wasn't exported.
The Compositor contains nothing that can potentially get dirty and need
repainting.
As is, the advantages of this move aren't really noticeable, but it
makes sense with multiple scenes.
Backend parts are far from ideal, they can be improved later on as we
progress with the scene redesign.
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.
The main motivation behind this change is to prepare kwin for importing
kwayland-server code in libkwin.
As is, builtin effects are linked with libkwin. Some builtin effects
have wayland specific code. If we move wayland stuff in libkwin, there's
going to be a circular dependency between kwin4_effect_builtins and
libkwin targets.
This change intends to break that dependency by linking builtin effects
to kwin executable.
The main issue with that is that EffectLoader would need to discover the
effects indirectly. QStaticPlugin is used for that purpose.
Besides breaking the cyclic dependency, it makes builtin effects use the
same plugin infrastructure in libkwineffects that external effects use.
Metadata in src/effects/effect_builtins.cpp was converted in a list of
python dictionaries, which was fed to a python script that generated
main.cpp and metadata.json files.
With the LEDs enum being defined in kwinglobals.h, wayland_server.h
won't need to include keyboard_input.h, which is good for compilation
times and wayland_server.h will drag less stuff, e.g. QtWidgets (input.h
includes QAction)
The English word "pack" is not really the correct word for these
actions, and does not succeed in communicating what they will do. Since
the actions simply move the active window as far as it will go in the
specified direction, the actions can be renamed to say that instead.
Also rename the action names in the code to match their new UI text for
clarity.
This change merges the two OpenGL backends into one making the current
default of GLCore the overall default. It becomes the first context to
try to create. If it fails, it will automatically fall back to the
(previous) OpenGL 2 backend.
Reasoning: the differentiation of OpenGL 2 and 3 is a very technical one
and hard to understand for users. It is not obvious which one is better
or should be used. This results in many user discussions like "Which
backend to use?"
Back when the OpenGL 3 backend was introduced the dedicated feature made
sense. It was a new code base using new driver features. Nowadays the
code base in KWin is robust and mature and so are the drivers. A driver
advertising support for OpenGL 3 will support OpenGL 3. We don't have to
plan for driver breakage in this area any more.
Also our code evolved through the context attribute builder which gives
us the possibility to more easily fall back in case we cannot create the
context. Thus the need to select the backend is not so important as it
used to be when the feature got introduced.
If a user still wants to force OpenGL2, it is still possible by setting
the appropriate environment variables like MESA_GL_VERSION_OVERRIDE.
This change brings the improvement that the backend selection is now
completely removed from the compositing KCM.
FAIL! : TestXdgShellClientRules::testSizeApply() 'surfaceConfigureRequestedSpy->wait(10)' returned FALSE. ()
Loc: [/home/jenkins/workspace/Plasma/kwin/kf5-qt5 SUSEQt5.15/autotests/integration/xdgshellclient_rules_test.cpp(731)]
If CI is moderately loaded, 10ms may not be enough. I don't remember why
10ms timeout was added.
Currently, testXdgWindowReactive() is a bit flaky because the parent
window and the popup window are created together. The popup can be
configured again if its global position changes after the parent window
has been placed.
In order to stabilize the test, create the parent window, then the popup
window.
The current code set m_pasteProcess to null, before running the cleanup
function which tells the process to quit.
Which is why it always hung the CI. This patch addresses it in a way
that cleans up helpers even if we abort the test early.
With a "Surface" type in kwin, KWayland::Client::Surface without fully
specified namespace will conflict with kwin's Surface type.
In some way, it also improves readability as it's clear where Surface
comes from.
Port the RuleSettings and KCM to store and use a list of virtual desktop
UUIDs, instead of the previous x11 positional id, continuing the work on
This allows to set a rule with several desktops on Wayland.
On X11 it has no visible change for the user, but internally it uses the
more modern concept, helping to simplify the related code.
The relevant key on kwinrulesrc changes from `desktop` to `desktops`.
A kconf_update script handles the migration.
Due to the screen edges test not being an integration test, it's very
hard to change output related code in libkwin. screens.cpp needs to have
a few ifdefs to successfully compile.
This change rewrites the screen edges test as an integration test in
order to allow us using other components of kwin in screens.cpp and
screenedge.cpp without ifdef guards.
It's not a one-to-one port.
Active output is a window management concept. It indicates what output
new windows have to be placed on if they have no output hint. So
Workspace seems to be a better place for it than the Screens class, which
is obsolete.
This patch has one behavioral change - raiseOrLowerClient() will not
work if the client is not on the current virtual desktop.
However, raiseOrLowerClient() can be called only in two cases:
* user triggers the raise or lower shortcut for the active client. Since
the active client is on the current virtual desktop, it's not an issue
* an x11 window restacks itself. It makes no sense if an x11 window
restacks itself while it's inactive or not on current virtual desktop.
Also, the Opposite restack mode is rarely used, some window managers
don't even bother implementing it. So, having such a constraint should
not be a problem.
The main reason for not allowing raiseOrLowerClient() for windows that
are not on the current virtual desktop is that a window can be on
multiple virtual desktops. If a window is on A and B virtual desktops,
the only logical option is to toggle stacking position if the window is
on the current desktop. It's the only viable option as kwin does not
maintain per virtual desktop stacking order.
toplevel.h is included in many places. Changing virtualdesktops.h may
trigger rebuild of all kwin.
With this change, only cpp files that use virtualdesktops.h will need to
be recompiled.
The main motivation behind the split is to simplify client buffer code
and allow adding new features easier, for example referencing the shm
pool when a shm buffer is destroyed, or monitoring for readable linux
dmabuf file descriptors, etc.
Also, a referenced ClientBuffer cannot be destroyed, unlike the old
BufferInterface.
Since we adapted inputmethod to support methods like ibus, the input
method can be active but not have a visible panel.
This includes an extra property that will indicate us if the panel is
visible at any time. This will allow us to properly render the virtual
keyboard hide button in Plasma Mobile (or wherever we need it).
So far calling setActive(true) would issue a deactivation then another
activation. This sometimes makes maliit crash and we can achieve the
same result just by just issuing a reset.
At the moment, the test depends on the implicit client connection flush
in BufferInterface::unref(). It will be highly desirable if that connection
flush is gone as it allows us batching wayland events better. It also
allows us remove a system call from a hot path.
Drop-shadows with the software render backend impact performance quite
significantly. It also makes it easier to prepare render backends for the
item based design.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
Window management features were written with synchronous geometry
updates in mind. Currently, this poses a big problem on Wayland because
geometry updates are done in asynchronous fashion there.
At the moment, geometry is updated in a so called pseudo-asynchronous
fashion, meaning that the frame geometry will be reset to the old value
once geometry updates are unblocked. The main drawback of this approach
is that it is too error prone, the data flow is hard to comprehend, etc.
It is worth noting that there is already a machinery to perform async
geometry which is used during interactive move/resize operations.
This change extends the move/resize geometry usage beyond interactive
move/resize to make asynchronous geometry updates less error prone and
easier to comprehend.
With the proposed solution, all geometry updates must be done on the
move/resize geometry first. After that, the new geometry is passed on to
the Client-specific implementation of moveResizeInternal().
To be more specific, the frameGeometry() returns the current frame
geometry, it is primarily useful only to the scene. If you want to move
or resize a window, you need to use moveResizeGeometry() because it
corresponds to the last requested frame geometry.
It is worth noting that the moveResizeGeometry() returns the desired
bounding geometry. The client may commit the xdg_toplevel surface with a
slightly smaller window geometry, for example to enforce a specific
aspect ratio. The client is not allowed to resize beyond the size as
indicated in moveResizeGeometry().
The data flow is very simple: moveResize() updates the move/resize
geometry and calls the client-specific implementation of the
moveResizeInternal() method. Based on whether a configure event is
needed, moveResizeInternal() will update the frameGeometry() either
immediately or after the client commits a new buffer.
Unfortunately, both the compositor and xdg-shell clients try to update
the window geometry. It means that it's possible to have conflicts
between the two. With this change, the compositor's move resize geometry
will be synced only if there are no pending configure events, meaning
that the user doesn't try to resize the window.
This is to improve code readability and make it easier to differentiate
between methods that are used during interactive move-resize and normal
move-resize methods in the future.
We need to emit the clientFinishUserMovedResized signal to notify
effects such as translucency that the interactive move-resize is
finished. Otherwise, the set() animation won't be cancelled and the
window will get stuck frozen.
BUG: 409376
The order in which Xwayland surfaces are associated with X11 windows is
undefined, meaning that we cannot assume that a newly created X11 window
won't have a surface associated with it already.
This reduces the number of usages of xStackingOrder(), which simplifies
the reasoning about when it can be marked as dirty.
Since internal windows are now in the regular stack, InternalWindowTest
can use stackingOrder().
As for X11ClientTest, there's no specific reason why it uses the x stack
instead of the regular one.
We need to make sure that the information from
toplevelConfigureRequestedSpy is in place to be used, otherwise we get
an empty size and it doesn't work.
We were expecting a tooltip to be closed when clicking its
transientParent, but it's explicitly not something we are after. We
close popups when we click either other clients or the actual client on
the decoration.
This change makes it so we end up clicking another window instead of the
parent one that is unrelated.
When debugging modifier_only_shortcut_test in _waylandonly mode I saw
that it was failing, among other things, because some aspects were not
initialised.
This changes every test we have to run the new
Test::initWaylandWorkspace() that calls waylandServer()->initWorkspace()
but also makes sure that WaylandServer::initialized is emitted before we
proceed.
Starting with 48c3376927e5e9c13377bf3cfc8b0c411783e7f3 in kglobalaccel,
KGlobalAccel won't work in desktop environments other than Plasma.
We need to set XDG_CURRENT_DESKTOP=KDE to ensure that global shortcuts
still work.
Currently, the fullscreen state is update synchronously, but it needs to
be done in asynchronous fashion.
This change removes some tests as they don't add any value, testFullscreen()
covers them all.
Xcursors don't support hidpi so if a hidpi cursor is needed, kwin will
scale the desired size by the scale factor and ask Xcursor helpers to
load a theme with the given name and the size.
However, the theme loading code doesn't take into account that Xcursor
theme loading helpers may not return cursor sprites of size size * scale
if the theme has no such a size.
For example, if the cursor theme only provides 24, 36, and 48 sizes and
kwin attempts to load cursors of size 48 with a scale factor of 2, we
will get cursors of size 48 instead of 96. Unfortunately, this will
result in the issue where the cursor shrinks when hovering decorations
because kwin doesn't know that the effective scale factor (1) is
different from the requested scale factor (2).
In order to fix loading of HiDPI cursors, we need to approximate the
effective scale factor of every cursor sprite as we load it.
If a decoration is created for an already mapped maximized window, check
the workspace position to ensure that the window still fits the maximize
area.
BUG: 432326
Re-use Qt's implementation of handling non-Latin layouts here
For full ASCII range support (Alt+`, etc.) Qt needs to be patched still,
see QTBUG-90611
BUG: 375518
At the moment, the session code is far from being extensible. If we
decide to add support for libseatd, it will be a challenging task with
the current design of session management code. The goal of this
refactoring is to fix that.
Another motivation behind this change is to prepare session related code
for upstreaming to kwayland-server where it belongs.
Summary:
QScriptEngine is deprecated for years and suffers bitrot.
Plasma hit one super major bug with it in 5.11.0 and has now ported
away.
Main porting notes:
- creating low level functions no longer exists
The old global functions are exposed on the ScriptedEffect instance
and then the QJSValue wrappers of the globalObject are modified to
trampoline the methods at a wrapper level.
- We can then use QJSEngine to automatically do argument error checking
rather than unmarshalling a QJSValue manually which significantly
reduces a lot of code.
- We can't make FPX2 a native type, so these are QJSValue args and
unboxed there.
Long term I want overloads for animate that take int/QSize/QPoint which
are native JS types, but that might be an API break.
Test Plan:
Hopefully comprehensive unit test which passes
Tested fade/fadeDesktop manually.
It's a very invasive change, so I expect some things will be broke
please help test any JS effects.
Reviewers: #kwin, mart, fvogt
Subscribers: fvogt, zzag, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D14536
Otherwise the input method test seems to fail with the following error
"The name org.kde.kwin.testvirtualkeyboard was not provided by any
.service files"
According to the spec, when the pointer enters a surface, the contents
of the cursor becomes undefined. The client should call set_cursor() to
make sure that the cursor image is correct.
In case the compositor wants to cancel a touch sequence, we need to
ignore subsequent touch motion and touch up events until a new sequence
is initiated by the user.
Previously, it was implicitly handled by clearing the mapping table
between the touch slots and touch ids generated by kwayland-server.
Once in a while, we receive complaints from other fellow KDE developers
about the file organization of kwin. This change addresses some of those
complaints by moving all of source code in a separate directory, src/,
thus making the project structure more traditional. Things such as tests
are kept in their own toplevel directories.
This change may wreak havoc on merge requests that add new files to kwin,
but if a patch modifies an already existing file, git should be smart
enough to figure out that the file has been relocated.
We may potentially split the src/ directory further to make navigating
the source code easier, but hopefully this is good enough already.
Occasionally, I see complaints about the file organization of kwin,
which is fair enough.
This change makes the source code more relocatable by removing relative
paths from includes.
CMAKE_CURRENT_SOURCE_DIR was added to the interface include directories
of kwin library. This means that as long as you link against kwin target,
the real location of the source code of the library doesn't matter.
With autotests, things are not as convenient as with kwin target. Some
tests use cpp files from kwin core. If we move all source code in a src/
directory, they will need to be adjusted, but mostly only in build
scripts.
This allows running Xwayland apps as root. Xwayland started with an
empty Xauthority file. After kwin has received the display number, the
file is updated with an actual authority entry.
BUG: 432625
