For the following KCM :
* KWin Options
* KWin Screen Edges
* KWin Tabbox
KCModule introduce an indicator to show which settings have changed from
default value. Unfortunately some KCM have settings' states which are not managed
automatically by the KCModule thus we have to handle it manually.
see https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/9
VirtualKeyboard class does not implement the relevant VirtualKeyboard
protocol but rather implements the InputMethod protcol and can in theory
be used by other input method like e.g. ibus.
Make class name consistent with what it does to avoid confusion in
future.
For now only rename of main class is done and dbus service is kept as-is
to provide retro-compatibility, when input method protocol is
implemented fully, we can think of what to do wrt the dbus interface
later when we fully implement zwp_input_method_unstable_v1 protocol.
When deciding do OSD or not, we need to consider not only last saved layout,
but last actual layout also, when comparing it to current one.
DIGEST:
BUG: 425590
Currently, internal on screen display windows have the bypass window
manager hint set. If that hint is set, the osds must place themselves,
but they don't do it.
As far as I know, there is no any reason why internal OSDs have that
flag set.
By removing the Qt::BypassWindowManagerHint flag, we let kwin core
know that it's okay to place internal OSD windows.
BUG: 400675
Currently, if some script attempts to resize a window while it's being
interactively resized, the corresponding change won't be propagated to
the X server.
The main reason for that is that we don't want to configure the frame
window, the wrapper window, and the client window twice. However, since
Xcb::Window keeps track of the last configured geometry, we can adjust
X11Client::updateServerGeometry() so it only configures windows that
have mismatching geometry.
By doing so, the setFrameGeometry() function can be called by scripts
even when the associated X11 window is being interactively resized.
Note that this bug doesn't affect Wayland windows.
BUG: 426988
If the shadow is destroyed immediately before the window is destroyed,
we need to schedule a workspace repaint in order to prevent showing a
"ghost" shadow.
BUG: 425294
We need to schedule a workspace repaint in case no effect is going to
animate the window.
The workspace repaint is issued before creating a Deleted because the
latter takes the owner of the effect window, which means that after an
instance of Deleted has been created, visibleRect() returns the frame
geometry.
CCBUG: 425294
If an X11 event filter has been activated and it unregisters another X11
event filter, then the window manager may crash because the foreach macro
in Workspace::workspaceEvent() makes a copy of m_genericEventFilters or
m_eventFilters and we can call the event() method for an already defunct
filter.
With this change, X11 event filters can be safely removed and installed
at any particular moment.
BUG: 423319
By marking as part of graphical-session we get a more graceful shutdown.
Also switched to explicit restart inside the unit. Originally I did this
with drop-ins, but this complicates wayland for now.
If the opaque area covers all the window's shape, it means that it's an
opaque window.
This is how GTK presents opacity right now, so we'll get to skip
rendering under GTK clients and other compatible ones.
Qt is still not emitting opacity.
The main motivation for this change is to enable support for our
proprietary shadow protocol in LayerShellV1Client.
Previously we couldn't move code that handles shadows in WaylandClient
because WaylandClient::bufferGeometry() was a pure virtual method.
This reverts commit 9d4c8fda09.
Unlike other effects this wasn't using hide/show as a hack for not
having a created/destroyed signal but because the window is internally
hidden when it's in auto-hide mode despite being still mapped.
BUG: 426686
Currently, if kwin/wayland runs without xwayland, the order in which
windows are painted doesn't actually reflect the true stacking order.
If the stacking order has been changed, we need to invalidate the
cached x stacking order. But it's done only when RootInfo is present.
If Xwayland doesn't run, RootInfo is not available and thus window
raising is completely broken.
With this change, the x stacking order will be invalidated every time
some window has been raised, no matter what mode kwin operates in.
If showOnScreenEdge is called, immediately followed by the client's destruction, it's possible that the next event queue process will call raiseClient with a destroyed client.
We avoid this by using singleShot that is lifetime-aware.
This change replaces the remaining usages of the old connect syntax with
the new connect syntax.
Unfortunately, there are still places where we have to use SIGNAL() and
SLOT() macros, for example the stuff that deals with d-bus business.
Clazy was used to create this change. There were a few cases that needed
manual intervention, the majority of those cases were about resolving
ambiguity caused by overloaded signals.
Currently, we do some sort of window placement only for decorated
internal windows, which feels hacky.
With this change, all internal clients will go through the window
placement code, unless it's a popup or the BypassWindowManagerHint
flag is set.
If the BypassWindowManagerHint flag is set, the window must have
valid position.
CCBUG: 400675
Currently, whenever the focused text input surface changes, the virtual
keyboard will create a bunch of excessive connections. This is leftover
after the old design.
