We use KWIN_NAME, KWIN_INTERNAL_NAME_X11 and KWIN_INTERNAL_WAYLAND
properly only in a few places. In other, we use hardcoded names.
Let's not bother and hardcode kwin names everywhere rather than have one
foot in and one foot out, it's simpler.
Due to being a compositor, kwin has to conform to some certain
interfaces. It means a lot of virtual functions and function tables to
integrate with C APIs. Naturally, we not always want to use every
argument in such functions.
Since we get -Wunused-parameter from -Wall, we have to plumb those
unused arguments in order to suppress compiler warnings at the moment.
However, I don't think that extra work is worth it. We cannot change or
alter prototypes in any way to fix the warning the desired way. Q_UNUSED
and similar macros are not good indicators of whether an argument is
used too, we tend to overlook putting or removing those macros. I've
also noticed that Q_UNUSED are not used to guide us with the removal no
longer needed parameters.
Therefore, I think it's worth adding -Wno-unused-parameter compiler
option to stop the compiler producing warnings about unused parameters.
It changes nothing except that we don't need to put Q_UNUSED anymore,
which can be really cumbersome sometimes. Note that it doesn't affect
unused variables, you'll still get a -Wunused-variable compiler warning
if a variable is unused.
Makes it possible to follow the dbus service for locale configuration,
making it possible to have third parties integrate with Plasma.
This is done opt-in for now, it can be adopted generally in the future,
if necessary.
The entire approach behind that test is wrong. Even slight changes in
one pixel can make the test fail. There's no human-friendly way to
determine what the difference between reference and actual frames are.
The reference frame is generated in code rather than from an image on
the disk, which makes the tests even more error-prone.
The test is flaky too and constantly blocks merging patch submissions.
We need a different way to test rendering results, not what
testSceneQPainter currently does. Normally, I would say that we need
to add such an infrastructure before dropping the test, but it makes the
merging process so inconvenient and the test doesn't really bring any
value, it tests really basic cases which are noticeable right away after
launching kwin.
With the addition of KGlobalAccel::globalShortcutActiveChanged(),
there's a way to monitor all triggered actions without adding any
boilerplate code.
This change removes the KGlobalAccel bits from the Platform class. This
reduces the amount of boilerplate code; currently we need to be careful
about ensuring that Platform::setupActionForKGlobalAccel() is called.
Another reason behind this change is to simplify the api of Platform and
remove things that don't have anything to do with outputs.
Use isNull on QSizeF to check for a zero delta instead of comparing it
with a default-constructed QSizeF, which in practice initializes to
(-1.0,-1.0). This caused relative motion events to be omitted if the
delta happened to be equal to (-1.0,-1.0), causing mouse jumping in some
applications.
BUG: 444510
Signed-off-by: John Brooks <john@fastquake.com>
The signal will be emitted if text-input-v3 applies a new enable state
if it's already enabled.
In Gtk's implementation, sending text_input_v3.enable for the second
time has the similar semantics of text-input-v2.showInputPanel. Try to
connect them together and add corresponding test.
See also: a95cfb1c45/gtk/gtkimcontextwayland.c (L555)
Writing is what our guard is supposed to prevent, let's try to mmap it
for writing. It seems FreeBSD still allows PROT_READ for sealed-for-writing
mmaps.
When text input gets enabled, the sequence should be
1. enable
2. request to show the panel
3. panel gets added and shown
And showing the panel again after hiding is an important case to cover as
well.
QXkbCommon fails to map `Ё` to `~` when pressing `Shift+grave` and
sequenceEdit seems to have focus now.
On the other hand, does it make sense to bind global shortcuts with key
sequences such as "Shift+`"? The system settings doesn't even allow typing
in such key sequences.
testDbusInterface fails with Qt 6 build because QCOMPARE detects the
type difference between QString and QByteArray.
Since these properties being byte arrays has caused reasonable amount of
discomfort, let's make them QStrings. It will fix the test and make some
scripted effect code more cleaner.
PointerInputTest::testWarpingBetweenWindows() compares
QVariant(QPointF) with QPoint. While this works in Qt 5, Qt 6 seems to
take the type into account when comparing the two.
TestXdgShellWindow::testPointerInputTransform() compares
QVariant(QPointF) with QPoint. While this works in Qt 5, Qt 6 seems to
take the type into account when comparing the two.
In some cases, stateCommitted may fire after a new surface being focused
and in correctly set input method to be inactive. This can be reproduced
by switch client between an active text input v3 client and text input
v2 client.
The Workspace requires at least one output and no output has 0x0 size.
This fixes a crash in confineToBoundingBox() where qBound() asserts that
the min value is less than the max value, in our case the x coordinate
of the left edge of the workspace is less than the x coordinate of the
right edge of the workspace.
Client-side wrappers for input-method-unstable-v1 fail to build because
wl_keyboard_interface is referenced in the header file generated by
wayland-scanner.
Unfortunately, qt6_generate_wayland_protocol_client_sources() forces
--include-core-only argument, this is addressed in Qt 6.4.1, but in
meanwhile let's ship a copy of Qt6WaylandClientMacros.cmake file until
the required Qt version is out.
In libinput 1.19, three new pointer axis events were added in order to
provide support for high-resolution scrolling.
LIBINPUT_EVENT_POINTER_AXIS is de-facto deprecated and new users of
libinput should use instead SCROLL_WHEEL, SCROLL_FINGER, and
SCROLL_CONTINUOUS.
Discrete deltas were replaced with v120 delta values. 120 corresponds to
a single discrete delta. Smaller values correspond to "partial" wheel
ticks.
https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72
This change extends the OutputChangesTest so it also covers the cases
where a maximized and a fullscreen window is moved back to its original
output when it's hotplugged.
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.
It adds more test cases in OutputChangesTest, particularly swapping
outputs.
Swapping outputs is an interesting case because outputs can temporarily
overlap so workspace()->outputAt() can return wrong output and the
window is going to stick to wrong output.
Currently the Workspace processes output updates as they occur, e.g.
when the drm backend scans connectors, the Workspace will handle
hotplugged outputs one by one or if an output configuration changes the
mode of several outputs, the workspace will process output layout
updates one by one instead of handling it in one pass. The main reason
for the current behavior is simplicity.
However, that can create issues because it's possible that the output
layout will be temporarily in degenerate state and features such as
sticking windows to their outputs will be broken.
In order to fix that, this change makes the Workspace process batched
output updates. There are several challenges - disconnected outputs have
to be alive when the outputsQueried signal is emitted, the workspace
needs to determine what outputs have been added or removed on its own.
Separate trigger progress and semantic progress in gesture.
Move effect activation and desktop switching over to semantic progress.
Allow semantic progress to exceed 1 for overshoot in animations.
I've added VerticalAxis, HorizontalAxis, DirectionlessSwipe and BiDirectionalPinch gestures directions.
These are all combinations of other gesture directions that semantically work well together.
I've implemented these gestures as well as changed some labels and improved documentation,
Also,
Add vector signal to SwipeGesture
- Now only 1 GestureDirection enum
- Now only 1 registerGesture() call
- The 4 kinds of gesture (Pinch/Swipe) and (Touchpad/Touchscreen) in globalshortcuts.h/cpp are merged into 1 GestureShortcut
- Change from range to set of finger counts in gestures
No behavior should change, just a refactor.
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.
This class can be used to create an anonymous file, for instance
to pass data between compositor and clients, through means of a
file descriptor, as is done in various Wayland protocols, notably
the keymap exchange.
It also implements sealing the file, so that it can be shared
between multiple clients without them being able to modify it.
If supported, memfd_create is used, otherwise a `QTemporaryFile`
is used.
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
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.
In X11 when a window is maximised if the client is unable to fufill the
space provided we centre align the window.
With the new floating point geometry behaviour of centreing changes.
Instead of a 1 pixel gap at the top, we get a 0.5 pixel gap either side.
When we get into the codepath to "fix" the window in `closeHeight` we
only move the top, giving us an invalid buffer size.
We don't really want to change the logic here; on xwayland with the
scaling opt-out path it's feasible for a floating sized logical size to
still be representable. This code rounds to the native unit after all
the logic has taken effect.
It's important for tablet devices to be able to specify to which section
of the display we'll be fitting the tablet. This setting allows to
specify this by providing some options that will do so relative to the
output size.
CCBUG: 433045
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.
