Summary:
So far KWin used the window title provided from the window directly
without any sanitizing. This could result in broken window decorations
if the title included line breaks. Those were passed to the decoration
and depending on the way how the decoration renders the title, it could
result in visual breakage.
Having line breaks in a window title doesn't make sense. Given that KWin
now simplifies the title when copying it to it's own structure. This
also ensures that the title passed to e.g. task manager does not have
any line breaks on Wayland.
BUG: 323798
FIXED-IN: 5.8.4
Test Plan: Opened the web page in a nested KWin, properly rendered now.
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3215
Summary:
KWindowSystem provides a KDE specific property for the desktop file
name. This allows KWin to take the icon from the desktop file. The
advantage from the desktop file is that KWin normally gets higher
resolution icons than provided through the xproperty based icons used
previously. If the desktop file does not provide an icon name, KWin
falls back to the previous implementation.
As on Wayland the icon is taken from the desktop file name already the
code for X11 and Wayland is merged in AbstractClient. Also to the
PlasmaWindowInterface the appId is taken from the new desktop file
instead of the resourceName. Due to that for Xwayland windows where KWin
knows the desktop file name it can be passed to PlasmaWindowInterface.
This allows e.g. the task manager to better map the windows to
applications and provide better icons. Also it means that icons do not
need to be passed as bitmap data to the clients.
Test Plan:
Verified that icon is taking from desktop file if provided and
from X property if not provided and that Wayland windows still have icon.
Reviewers: #kwin, #plasma_on_wayland, hein
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D3177
Summary:
Client::updateInputWindow operates with the decoration size. The method
gets called from various points when changing the window geometry. If at
that moment the decoration has not updated yet, the borders might be at
a wrong position.
This behavior could be triggered when a window requested to change the
state to maximized. During maximization the decoration still had the
wrong size when updateInputWindow was called, thus an interactive area
inside the window was created.
To circumvent this problem updateInputWindow is now also called whenever
the window decoration changes.
As a note: that a maximized window has resize only borders is wrong. Kwin
should be protected against that.
BUG: 371284
FIXED-IN: 5.8.3
Test Plan: Checked xwininfo for the deco extends window
Reviewers: #kwin, #plasma
Subscribers: plasma-devel, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D3151
Summary:
From feedback we got it seems that not all users agree to games and
other applications blocking compositing. Some users prefer to have
compositing always on even if this gives a small performance penelity.
This change introduces a dedicated config option to specify whether games
are allowed to block compositing. By default this option is enabled.
The setting can be overwritten with a window specific rule. So usecases
like all windows except this very specific one are supported.
In the user interface the config option is shown where previously the
unredirect fullscreen option was shown.
Test Plan:
Run a game which should block compositing, verified it blocks.
Changed the setting, run the game again, verified it doesn't block. And
once more for with allowing to block.
Reviewers: #kwin, #plasma_on_wayland, #vdg
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2584
Summary:
This allows Client to use the Wayland-specific implementation if there
is no icon geometry set through the X11 way. That way Xwayland windows
have an icon geometry even if Plasma is using Wayland and setting the
icon geometry in the Wayland way. Which is expected as Plasma is
ignorant about the windowing system a PlasmaWindow uses.
In order to move the code from ShellClient to AbstractClient
WaylandServer gained a new findAbstractClient(Surface*) method which
is just like findClient(Surface*) with the difference that it returns
an AbstractClient instead of a ShellClient*.
Test Plan:
minimized/unminimized an X client on Wayland, verified
animation is correct (though broken in general for minimize)
Reviewers: #kwin, #plasma_on_wayland
Subscribers: plasma-devel, kwin
Tags: #plasma_on_wayland, #kwin
Differential Revision: https://phabricator.kde.org/D2530
Summary:
This fixes a bug I had where Session Management restored a window on an
activity that didn't exist that, meaning I was unable to access it.
setOnActivity() already has this check
BUG: 362620
Test Plan:
Using my broken session, restored and got my ghost process back
on all activities
Added a window to activity 2, checked it came back there and
only there.
Reviewers: #plasma, graesslin
Subscribers: ivan, luebking, graesslin, kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D1982
Summary:
Rational: unredirect fullscreen windows is a weird beast. It's intended
to make fullscreen windows "faster" by not compositing that screen. But
that doesn't really work as KWin jumps out of that condition pretty
quickly. E.g. whenever a tooltip window is shown. KWin itself has a
better functionality by supporting to block compositing completely.
The complete code was full of hacks around it to try to ensure that
things don't break.
Overall unredirect fullscreen has always been the odd one. We had it
because a compositor needs to have it, but it never got truly integrated.
E.g. effects don't interact with it properly so that some things randomly
work, others don't. Will it trigger the screenedge, probably yes, but
will it show the highlight: properly no.
By removing the functionality we finally acknowledge that this mode is
not maintained and has not been maintained for years and that we do not
intend to support it better in future. Over the years we tried to make
it more and more hidden: it's disabled for Intel GPUs, because it used
to crash KWin. It's marked as an "expert" option, etc.
It's clearly something we tried to hide from the user that it exists.
For Wayland the whole unredirect infrastructure doesn't make sense
either. There is no such thing as "unredirecting". We might make use
of passing buffers directly to the underlying stack, but that will be
done automatically when we know it can be done, not by some magic is
this a window of specific size.
Test Plan:
Compiles, cannot really test as I am an Intel user who never
had that working.
Reviewers: #kwin, #plasma, #vdg
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2180
Summary:
With this change auto-hiding panels are animated again by SlidingPopups
effect.
Test Plan: Test case adjusted, and tested in VM
Reviewers: #kwin
Subscribers: kwin
Tags: #kwin
Differential Revision: https://phabricator.kde.org/D2157
BUG: 354407
FIXED-IN: 5.8.0
Summary:
Client uses a static Xcb::Window helper. This so far didn't get
explicitly destroyed, so the application finalize cleaned it up.
To destroy the window the xcb_connection_t* is used which the
QGuiApplication already destroyed.
This change ensures that the window gets destroyed before the xcb
connection gets destroyed.
In addition an assert is added to KWin::connection() to ensure that
we still have the QGuiApplication::instance() when it's invoked.
This way we'll notice if we have more cases where we call into xcb
after the application went down.
Reviewers: #plasma
Subscribers: plasma-devel
Projects: #plasma
Differential Revision: https://phabricator.kde.org/D1573
The damage event of the Surface does not consider the offset through
the server side decoration. Due to that we need to have a different
repaint and damage area. As Toplevel::addDamage(QRegion) is only used
in the Wayland case the repaint adjustment is removed from the generic
implementation and moved into the specific implementations. While it
wouldn't hurt to have the repaint adjustment in Toplevel, it would
trigger a repaint of an unchanged area.
For Client I'm not sure whether it's correct without considering the
clientPos. My testing shows it's working, but that might also just be
do to Xwayland using OpenGL buffers. Needs further testing.
The only clients that really seem to rely on it are
Java and they're apparently "broken", resp. extremely
picky on the tiemstamp and probably happily refuse focus
if it's *not* equal to the current server time (ie. anything else
happens at this moment) and overmore feel oblieged to act as WM
by juggling around VDs at all.
BUG: 347153
FIXED-IN: 5.6
REVIEW: 126753
Replacement for calls to info->input() which is only valid for the Client
sub class, but not for ShellClient.
In ShellClient the implementation is swapped with wantsInput() and
wantsInput() has a new implementation which properly delegates to rules()
just like Client does.
This includes the methods:
* decoration()
* decoration() const
* isDecorated() const
In addition new protected methods are added to destroy the Decoration
and to set it.
Usage of m_decoration in Client code is adjusted.
-use qstringliteral only when necessary (i.e. not in concat or comparison)
-use qbytearray instead of qstring when dealing with latin1 input and output (glplatform)
-use qstringref to extract numbers from strings (glplatform)
-define qt_use_qstringbuilder to optimize all string concatenations
-anidata: use ctor init lists, add windowType member initialization
REVIEW: 125933
If a rule minus the title match matches,
the captionChanged signal is bound to re-evaluate
the rules for that client, ie. the tracking overhead
only exists for those clients where title matching
is relevant and costs rematching all rules when such
client changes its title (yes, the partial matching
rules could be stored for faster re-check, but that
would make the patch bigger and is probably not worth
it; just some string comparisms)
additional tracking of wm_class or wm_role
(what is iirc a netwm violation anyway) would require
to monitor the resp. property for changes (not done atm.)
BUG: 220227
FIXED-IN: 5.5
REVIEW: 125427
Methods are no longer virtual. The only x11 specific usage in these
methods (resizeInc) is replaced by a virtual method. Default resize
increments is QSize(1,1) for AbstractClient.
Implementation is moved to abstract_client.cpp as so far events.cpp
does not have any code from AbstractClient.
This includes moving the electricMaximizingDelay from Client to
AbstractClient.
Includes moving the m_cursor and Qt::CursorShape cursor() method to
AbstractClient. In addition AbstractClient now emits a signal whenever
the shape changes allowing Client to react on it (update the low level
cursor) and also hopefully the Wayland Backends to react to it, so that
we have the cursor.
Method added so that we can call into TabGroup::updateStates from code
in AbstractClient. Default implementation does nothing, implementation
in Client performs the actuall call.
As a first case added to Client::move in order to be able to move the
implementation to AbstractClient.
Add action type to screen edge show to allow raise/lower as well as
autohide
Add an action type to screen edge show to allow raise/lower as well as
autohide. This uses the same atom, using a mask to separate type and
location.
The logic for handling geometry changes is moved from the screenedge to
the client so that we can handle both types without screenedge needing
to know what the raise is for.
REVIEW: 124272
Merges together the code from ShellClient and Client and removes the
starting differences. Long term it's better to have only one
implementation to prevent diversions in the implementation.
As it doesn't match exactly protected virtual methods are called
which allow more specific implementations for a certain aspect of the
layer resolving.
AbstractClient::mainClients is virtual and overriden in Client,
allMainClients has only a common implementation in AbstractClient.
In activation.cpp we still need one case where a temporary ClientList
needs to be constructed. Once transients are fully migrated that should
be removable again.
The user might just want to move the window from
one screen to another, no point in wasting time to
show the indicator
BUG: 352050
REVIEW: 125024
FIXED-IN: 5.5
notably *after* storing the old values.
Otherwise the old value is polluted because of
m_hints being nullptr, thus a default value is
returned (instead of the actual old value)
BUG: 347818
FIXED-IN: 5.4.2
REVIEW: 125007
The creation of PlasmaWindowInterface is moved from WaylandServer into
AbstractClient. This allows the sub classes to better control when to
create/destroy the Client.
For creation it's bound to becoming visible - that is Windows which are
only created but never shown are not announced at all.
For Client it's destroyed with the normal tear-down of a Client, for
ShellClient it's destroyed on unmapped (which also means a new one
will be created again in case of another mapping of the surface).
As a side effect, this works around the problem that ShellClients do not
yet get destroyed for QtWayland's menus (needs further investigation).
Martin Gräßlin
David Edmundson
Kevin Funk
Thomas Lübking
Nick Shaforostoff