The backend can now optionally wait for the scene to be created before
it updates its outputs, which is necessary for better atomic tests in
the DRM backend.
The SurfaceItemXwayland has to re-build quads if the shape changes.
The SurfaceItemX11 doesn't need a similar fix as it already discards
quads whenever the shape region changes.
The rnew name is applied when the user hits the return or enter key to
finish renaming, but this is an invisible UI and the user might not
think to do that. This commit replaces the "Rename" button with a
"Confirm new name" button while the text field is editable, so that it's
visibly clear how to finish renaming.
Similar to the feature to allow inline renaming in file managers, you
can now trigger renaming for a desktop by double-clicking on its list
item.
BUG: 421882
FIXED-IN: 5.23
Currently, the implementation of the DecoratedClient and the decoration
renderer are strongly coupled. This poses a problem with the item based
design as the ultimate goal is to have scene items construct paint nodes
which are then fed to the renderer. The DecorationItem has to have
control over the decoration texture. Another issue is that the scene
cannot smoothly cross-fade between two window states if the decoration
is removed, e.g. from fullscreen mode to normal and vice versa.
This change moves the decoration renderer to the decoration item. With
the introduction of a generic scene texture atlas, we hope to get rid of
the decoration renderer altogether.
AbstractClient::doPerformInteractiveMoveResize() is only used by the
X11Client to reset a boolean flag when the client doesn't support sync
counters.
X11Client can call performInteractiveMoveResize() only in two cases: the
sync request timer expires or the client increments the sync counter.
This change removes the AbstractClient::doPerformInteractiveMoveResize()
function and adds a function to handle the case where the sync timer
expires explicitly. This removes a virtual function in the AbstractClient
and makes code more readable.
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.
We have 2 equivalent code paths for x11 and wayland unnecessarily, unify
them under the same method.
Rename m_clients to m_x11Clients so that it's clear what the difference
is between m_clients and m_allClients.
If textFromValue is set, valueFromText must be.
A lot of other implemenetations were using parseInt() which fails at
reading "3,000" due to the comma. Qt's fromLocaleString handles that but
needs any text stripping.
This implementation isn't perfect, but really we need to work on a good
upstream solution.
BUG: 437472
kwayland-server was updated to follow the result of whether the data
offer was accepted before calling drop.
Our bridge was not updated.
We don't have enough data to know which mimeType the XWayland client
actually has accepted, as that doesn't exist at an X11 level, but it
doesn't have a big actual impact. Despite which mime type gets accepted
any mimetype can be retrieved in the drop event.
Tested against "dropsite" from QtBase widget examples forced into xcb
mode using dolphin as a source.
BUG: 437406
attachStreamConsumer and resetOutput are not called as part of the scene
render and as such the context might not be set.
All credit goes to Simon Spinner for his investigation.
BUG: 437573
Ensures that m_active and the input context do not get out of sync and
that the right signals are always emitted by always using setActive to
activate.
Uses the context to define InputMethod::isActive.
Detach from the serials that the client send us, since they don't really
matter to the input method and track our own.
Also issue a commit state whenever we adopt a new input context. This
can happen for reasons that don't come from the client, like for example
the input method has just been enabled.
In practice, this solves an issue that we can easily see with maliit
where it would be left in a half-initialised state and would show
autocorrection fields on terminal applications when unnecessary and
possibly similar problems every now and then.
The current UI allows to remove the last desktop, but:
- If you remove it it will reappear on the next KCM launch
- The Add button does not work then
Prevent removing the last desktop by disabling the action
BUG: 437561
When the user applies a change like adding a desktop
DesktopsModel::syncWithServer is called and m_synchronizing is set to
true. The server then sends some kind of response (e.g. desktopCreated)
and updateModifiedState is called which sets m_synchronizing to false
again.
However if a setting is changed that does not trigger any server change
(e.g. the show OSD setting) m_synchonizing is never set to false again,
causing problems down the line.
Instead of relying on updateModifiedState to reset m_synchronizing track
the syncronizing state by refcounting the DBus calls
BUG: 437466
Not choosing any virtual keyboard is a valid option. In this case do not show the SNI since it isn't very useful then and takes up some space in the system tray.
BUG: 437171
Most distros use either systemd's logind or consolekit for session
management.
The main reason why there's direct session is because up to some point,
kwin had a class called VirtualTerminal which was kind of like a direct
session backend.
The VirtualTerminal was used in the fbdev backend in conjuction with the
logind session backend, which looked odd.
Since the drm backend supported only logind and consolekit for very
long time and we hadn't received any complaints about it, the fact that
direct session is unsupported should not be noticeable.
Given that, this change removes the support for direct session in order
to reduce the amount of platform-specific code and make it easier to
maintain kwin.
Currently the apply button will only be enabled when you press enter or
change focus away from the text field which is somewhat inintuitive.
Instead enable the apply button as soon as the text changed.
BUG: 435014
With high DPI we can't use the image size as a logical size directly.
The other change is use of QPainter::drawImage(QRect target, QImage
image, QRect source)
This slightly confusing method uses logical pixels for the target, but
the source rect is in native pixels of the source.
BUG: 422342
If the egl backend gets deleted this leaves a dangling pointer. In
order to prevent crashes with QPainter or EglStreams also don't try
to create dmabuf textures without a EglGbmBackend.
One can think that Item::scheduleRepaint() will trigger repaint of the
whole item, but it actually only schedules the next frame. If nothing
has changed on the screen, no real painting will be done unless maybe if
the rendering backend needs to repair the back buffer.
They are used only by X11Client, so make X11Client call relevants
methods on the surface item directly instead. In hindsight, it will be a
really good idea to make SurfaceItemX11 and SurfaceItemXwayland(?)
automatically manage the window pixmap. However, it can be done once
an item freezing api is added and we fix the cross-fade animation.
Currently, items depend on scene windows for creating pixmaps, repaint
scheduling, and caching quads.
This change moves repaint scheduling from scene windows to items to
make the scene items depend less on scene windows.
In hindsight, we may clean up the repaint scheduling machinery further
by introducing view objects.
So far we had a composition setup within kwinrc and kscreen. This
produces flickering sometime and makes the state a bit more flimsy.
This patch changes the kwin's behaviour to use the files produced by
kscreen which are anyways available down the line.
THis simplifies our behaviour down to just one format that we write to
and feed from. This also allows us to leverage it further by using this
format for default setups (which consist in the right file in
~/.local/share/kscreen).
With the introduction of scene items, the Scene::Window::bufferShape()
method was removed as it makes no sense on wayland - a window may have
several sub-surfaces, so a single region to indicate the shape of the
window won't work.
SurfaceItem::shape() returns the shape of a surface. On Wayland, it
corresponds to the rect of the wl_surface. On X11, it corresponds to the
client window rect inside the frame window, or custom shape region if
the client has set one.
On the other hand, EffectWindow::shape() wants a completely different
thing. If the window is decorated, it needs to return the rect of the
decoration. Otherwise it has to return the shape region if there's one.
In the future, the EffectWindow::shape() function must be removed as it
doesn't fit the item based design. The main reason why we have it at
all is because the x server doesn't support translucency, setting a
shape region is a (hacky) way to work around that limitation, xeyes is
a notable example.
BUG: 437138
BUG: 435862
