The idea for this base class is to provide access to all elements which
make up a managed "Client" being it X11 or Wayland. They share a lot,
like they have a caption, they can be minimized, etc. etc.
Of course it would have also been possible to derive a new class from
Client, but that looks like the more difficult task as Client is very
X11 specific.
So far only a very small interface is extracted with pure-virtual
methods. This is going to change by moving the functionality up into
the AbstractClient.
The interface extracted so far is inspired by the usage of FocusChain
and users of FocusChain.
This is an alternative approach suggested by the
NETWM spec.
The advantage is, that windows are not minimized
at all what apparently lead to some confusion
about the nature of the mode (which was abused
to tidy up) and a secret config key to allow for
that unrelated behavior.
Instead the ShowDesktopIsMinimizeAll key is removed
and replaced by a dedicated script + shortcut.
Bonus: less code to remember "minimized" windows =)
Adapt to API changes introduced by b62e8888cd39301e00ad98dfe791fa66676408fb.
It adds DecoratedClient::color(group, role) for getting colors that are
not included in QPalette. Breeze used to read these colors from
kdeglobals, breaking per window color schemes. KWin now handles reading
these colors along with QPalette loading with DecorationPalette.
REVIEW: 122883
We released three versions with it being disabled and it doesn't look
like it will come back any time soon. Also the build was broken at least
since the repo splitting due to incorrect path to dbus xml.
In addition the connection to decorations got dropped already with the
change to kdecoration2. Which means it anyway needs large adjustements
to get the code working again.
Overall it doesn't look like it makes lots of sense to keep the code
around for someone working on it in future. If that happens this change
can be reverted.
On Wayland we get the damage from the SurfaceInterface instead of
using a damage handle. This change ensures that the damage handle
interaction is only used on platform X11, while on Wayland we get
the damage from the SurfaceInterface directly.
point of the calculation is to know how much
the window must be moved to de-compensate for
the deco but calculateGravitation() w/o a
deco (thus now w/o borderTop() etc.) is NOOP.
BUG: 344234
FIXED-IN: 5.2.2
The issue is essentially this - KActivities are now an asynchonous
library, while KWin tries to use them in the old manner.
When kwin restarts, it tries to validate the activity list of a window
against an invalid list of activities it thinks it gets from KAMD
because it does not check for the service status.
This patch disables the validation in the case of kwin restart/crash.
When starting kwin will see KActivities::Consumer::serviceStatus return
Unknown (before the class actually receives a response from the service
and starts syncing the data).
After kwin has started, the response will arrive and the service status
will change either to Running or NotRunning. The patch changes nothing
for this case.
BUG: 335967
REVIEW: 122577
... not dominance - if checking all supported types
eg. a dialog would trump NET::Override as type, thus
get a border despite NET::Override (which Qt would set
for Qt::FramelessWindowHint, alongside the MWM hints)
REVIEW: 122465
when restacking for shaded windows and uncomposited tabboxes
the group check should not be applied since we know better
eg. to restore a former order
CCBUG: 186206
REVIEW: 122469
A wrapper class for MotifHints is added to xcbutils. This class manages
the information about the read Motif hints, so that Client doesn't need
to have a copy of the read states.
The class is designed in a way that during Client::manage we get rid of
another roundtrip.
REVIEW: 122378
Since XCB 1.10 the sync extension is working properly. At the time of
the 5.3 release 1.10 will have been out for ~15 months, enough time
for distros to catch up and should allow us to use it.
As our CI system only supports 1.9 at the moment we cannot hard depend
on the version, instead we use feature info. As soon as our CI system
supports it, we should update the required min version and kick out the
ifdef.
REVIEW: 122377
Only emit paletteChanged signal and repaint decoration if the palette
actually changed. Even more important: check for path.isEmpty() instead
of path.isNull(). ::isNull() returns false for "" causing a costly
creation for default color scheme.
REVIEW: 122083
When map is called we need to repaint the complete area including
decoration shadows (e.g. might be called after unminimize). Therefore
we use a layer repaint with the visibleRect.
BUG: 342085
REVIEW: 121891
When a Client gets created the ::createDecoration method is invoked
from ::manage which is called before the Client is added to the
ClientList in Workspace. Thus processing the update fails in the
DecorationBridge as it cannot find the Client.
By delaying to the end of the event cycle we can be sure that the
Client is completely managed and that the scheduled repaint doesn't
fail.
This fixes the missing repaint when a Client starts as inactive.
We are only using the UrgencyHint, InputHint and GroupLeader from
WMHints. Those are provided by NETWinInfo, so we can use the
functionality provided by NETWinInfo instead of calling XGetWMHints.
REVIEW: 120162
Surprisingly the DecorationShadow is modelled after the Shadow in KWin.
It provides the same offsets and a QImage exactly like the OpenGL
implementation needs it. This makes it easy to hook it into our existing
Shadow implementation with only a few changes.
Shadow now first tries to create a Shadow from the Decoration and only
if that fails it tries the X11 property. The pixmaps are not initialized
for the DecorationShadow and because of that currently only the OpenGL
backend gets initialized for DecorationShadows. The other backends might
need adjustments and also a transition to just using one image.
NOTE: this is not working completely yet, lots of code is still ifdefed
other parts are still broken.
The main difference for the new decoration API is that it is neither
QWidget nor QWindow based. It's just a QObject which processes input
events and has a paint method to render the decoration. This means all
the workarounds for the QWidget interception are removed. Also the paint
redirector is removed. Instead each compositor has now its own renderer
which can be optimized for the specific case. E.g. the OpenGL compositor
renders to a scratch image which gets copied into the combined texture,
the XRender compositor copies into the XPixmaps.
Input events are also changed. The events are composed into QMouseEvents
and passed through the decoration, which might accept them. If they are
not accpted we assume that it's a press on the decoration area allowing
us to resize/move the window. Input events are not completely working
yet, e.g. wheel events are not yet processed and double click on deco
is not yet working.
Overall KDecoration2 is way more stateful and KWin core needs more
adjustments for it. E.g. borders are allowed to be disabled at any time.
This is going to be a controversal change. It enforces KWin decorations
on all client side decorated windows from GTK+. Unfortunately we are
caught between a rock and a hard place. Keeping the status quo means
having broken windows and a more or less broken window manager due to
GTK+ including the shadow in the windows. This is no solution.
Enforcing server side decorations visually breaks the windows. This is
also no solution. So why do it?
It's our task to provide the best possible user experience and KWin is
a window manager which has always done great efforts to fix misbehaving
windows. One can think of the focus stealing prevention, the window rules
and lately the scripts. The best possible window management experience is
our aim. This means we cannot leave the users with the broken windows
from GTK.
The issues we noticed were reported to GTK+ about 2 months ago and we are
working on improving the situation. Unfortunately several issues are not
yet addressed and others will only be addressed in the next GTK+ release.
We are working on improving the NETWM spec (see [1]) to ensure that the
client side decorated windows are not in a broken state. This means the
enforcment is a temporary solution and will be re-evaluated with the next
GTK release. I would prefer to not have to do such a change, if some of
the bugs were fixed or GTK+ would not use client-side-decos on wms not
yet supporting those all of this would be a no issue.
For a complete list of the problems caused by GTK's decos see bug [2] and
the linked bug reports from there.
The change is done in a least inversive way in KWin. We just check for
the property _GTK_FRAME_EXTENTS and create a Q_PROPERTY in Client for it.
If we add support for the frame extents in future we would also need
this. So it's not a change just for enforcing the decoration.
The actual enforcing is done through a KWin script so users can still
disable it.
REVIEW: 119062
[1] https://mail.gnome.org/archives/wm-spec-list/2014-June/msg00002.html
[2] https://bugzilla.gnome.org/show_bug.cgi?id=729721
Qt doesn't like that we reparent the decoration using low level xcb
calls. So let's use a QWindow wrapper for the frame and let Qt do
the reparenting itself.
BUG: 334768
REVIEW: 118159
Also with QWindow based decorations the event filter is needed to
properly react on mouse button release and mouse move. Those are not
passed through KDecoration unlike the button press.
The event filter is adjusted to handle both filters installed on QWidget
and QWindow while QWindow only gets to see a subset of the events.
This fixes mouse interaction in Aurorae.
REVIEW: 117879
The sync protocol with e.g. Qt 4 windows is broken if our app time is
older than the one of the last sync alarm event. Thus we keep a timestamp
in the syncRequest struct of the last sent sync request. If the timestamp
is newer than our xTime when sending the next request, we update the
xTime to ensure that we have a new timestamp again.
BUG: 333512
REVIEW: 117734
The Xcb::Property can wrap the xcb_get_property call and provides
convenient access methods to read the value of the reply with checks
applied. For this it provides a templated ::value method for reading a
single value or reading an array. There's also a ::toBool and
::toByteArray which performs the conversion directly with default values
for the type and format checks.
Xcb::TransientFor is changed to be derived from Property instead of
Wrapper directly, so that the reading of the property value can be
shared.
Xcb::StringProperty is a convenient wrapper derived from Property to
handle the reading of a string property providing a cast to QByteArray
operator. This replaces the ::getStringProperty from utils. Though the
separator functionality from ::getStringProperty is not provided as that
is only used in one function and handled there.
All the custom usages of xcb_get_property or getStringProperty are
replaced to use this new wrapper. That simplifies the code and ensures
that all properties are read in the same way.
REVIEW: 117574
So far the Unmanaged got released after an XCB_UNMAP_NOTIFY. This event
gets created after xcb_unmap_window or after xcb_destroy_window. In the
latter case the window is already distroyed and any of KWin's cleanup
calls will cause a BadWindow (or similar) error.
The idea to circumvent these errors is to try to wait for the
DESTROY_NOTIFY event. To do so the processing of the release is slightly
delayed. If KWin gets the destroy notify before the delay times out the
Unamanged gets released immediately but with a Destroy flag. For this a
new enum ReleaseToplevel is introduced and Unmanage::release takes this
as an argument instead of the bool which indicated OnShutdown. Also this
enum is added to Toplevel::finishCompositing so that it can ignore the
destroyed case and not generate an error.
REVIEW: 117422
Adds NET::WM2BlockCompositing to the Client's properties which allows to
read the state from the NETWinInfo object and get updates without having
to resolve the atom ourselve.
REVIEW: 117561
Excluded are the signals to Appmenu as that's currently excluded from
build.
Private slots with only one connection are turned into lambdas.
REVIEW: 117355
Instead of passing the macro based Predicate to findClient it now
expects a function which can be passed to std::find_if.
Existing code like:
xcb_window_t window; // our test window
Client *c = findClient(WindowMatchPredicated(window));
becomes:
Client *c = findClient([window](const Client *c) {
return c->window() == window;
});
The advantage is that it is way more flexible and has the logic what
to check for directly with the code and not hidden in the macro
definition.
In addition there is a simplified overload for the very common case of
matching a window id against one of Client's windows. This overloaded
method takes a Predicate and the window id.
Above example becomes:
Client *c = findClient(Predicate::WindowMatch, w);
Existing code is migrated to use the simplified method taking
MatchPredicate and window id. The very few cases where a more complex
condition is tested the lambda function is used. As these are very
local tests only used in one function it's not worthwhile to add further
overloads to the findClient method in Workspace.
With this change all the Predicate macro definitions are removed from
utils.h as they are now completely unused.
REVIEW: 116916
As can be seen in [1] the patches to KWin were in CVS HEAD before the
protocol got standardized and it never got any adoption. It's neither in
the NETWM spec, nor implemented in Qt4 nor in Qt5. KWin did not even add
the protocol to the NET::Supported property.
Thus it doesn't make much sense to keep a protocol which nobody speaks.
Still the code around the protocol is kept and also the names are kept.
Only difference is that Client::takeActivity got removed and the code
moved to the only calling place in Workspace. Motivated by that change
the enum defined in utils.h is moved into Workspace, it's turned into
a proper QFlags class and used as a type in the method argument instead
of a generic long.
[1] https://mail.gnome.org/archives/wm-spec-list/2004-April/msg00013.html
REVIEW: 116922
Major new functionality is xkbcommon support. InputRedirection holds an
instance to a small wrapper class which has the xkb context, keymap and
state. The keymap is initialied from the file descriptor we get from the
Wayland backend.
InputRedirection uses this to translate the keycodes into keysymbols and
to QString and to track the modifiers as provided by the
Qt::KeybordModifiers flags.
This provides us enough information for internal usage (e.g. pass through
effects if they have "grabbed" the keyboard).
If KWin doesn't filter out the key events, it passes them on to the
currently active Client respectively an unmanaged on top of the stack.
This needs still some improvement (not each unmanaged should get the
event). The Client/Unmnaged still uses xtest extension to send the key
events to the window. So keylogging is still possible.
InputRedirection keeps track of the Toplevel which is currently the one
which should get pointer events. This is determined by checking whether
there is an Unmanaged or a Client at the pointer position. At the moment
this is still slightly incorrect, e.g. pointer grabs are ignored,
unmanaged are not checked whether they are output only and input shapes
are not yet tracked.
The pointer events are delivered to the Toplevel as:
* enter
* leave
* move
* button press
* axis event
Nevertheless move events are still generated in InputRedirection through
xcb test for simplicity. They are still send to the root window, so all
windows get mouse move.
Button press and axis are generated only in the implementations of the
event handlers and delivered directly to the window, so other windows
won't see it.
In KCommonDecoration the OnAllDesktops button gets hidden or shown
depending on the number of desktops. For that KDecoration is extended
by a new property which delegates to the bridge to return whether
onAllDesktops is available. In KWin Core this is implemented using
the number of desktops.
FEATURE: 321611
FIXED-IN: 5.0.0
REVIEW: 116076
Scripting has proved it's point of being useful so it's time to turn it
into a mandatory part of KWin.
Also I start to use features provided by Scripting in more and more
parts of KWin core (e.g. sharing QQmlEngine) which makes it in the
long to complicated to have a build option and ifdefs for it.
REVIEW: 116587
This provides a new protocol intended to be used by auto-hiding panels
to make use of the centralized screen edges. To use it a Client can
set an X11 property of type _KDE_NET_WM_SCREEN_EDGE_SHOW to KWin.
As value it takes:
* 0: top edge
* 1: right edge
* 2: bottom edge
* 3: left edge
KWin will hide the Client (hide because unmap or minimize would break
it) and create an Edge. If that Edge gets triggered the Client is shown
again and the property gets deleted. If the Client doesn't border the
specified screen edge the Client gets shown immediately so that we
never end in a situation that we cannot unhide the auto-hidden panel
again. The exact process is described in the documentation of
ScreenEdges. The Client can request to be shown again by deleting the
property.
If KWin gets restarted the state is read from the property and it is
tried to create the edge as described.
As this is a KWin specific extension we need to discuss what it means
for Clients using this feature with other WMs: it does nothing. As
the Client gets hidden by KWin and not by the Client, it just doesn't
get hidden if the WM doesn't provide the feature. In case of an
auto-hiding panel this seems like a good solution given that we don't
want to hide it if we cannot unhide it. Of course there's the option
for the Client to provide that feature itself and if that's wanted we
would need to announce the feature in the _NET_SUPPORTED atom. At the
moment that doesn't sound like being needed as Plasma doesn't want to
provide an own implementation.
The implementation comes with a small test application showing how
the feature is intended to be used.
REVIEW: 115910
app_noborder shall be the determined noborder (shape, type)
but relevant noborder shall be determined by rules and respect the
motif hint
BUG: 330573
FIXED-IN: 4.11.6
REVIEW: 115402
Client used to have dedicated methods for different icon sizes instead
of combining all pixmaps into one QIcon. This resulted in various parts
of KWin having different access to the icons:
* effects only got one pixmap of size 32x32
* decorations only got the 16x16 and 32x32 pixmaps combined into a QIcon
* tabbox could request all icon sizes, but only as pixmap
Now all sizes are available in one QIcon allowing to easily access the
best fitting icon in a given UI.
Adds a new force rule to specify the color scheme to use on the window
decoration. The scheme is stored by the name of the .colors file name.
So for Oxygen.colors the value is Oxygen.
When loaded the scheme is located and the full path to the colors file
is used. This is because the X property also uses the full path.
The X property _KDE_NET_WM_COLOR_SCHEME can be set on a window and
specifies the absolute path to a .color file describing the color
scheme of the managed client.
The Client reads this property and creates a QPalette from it. If
the property is not set or the value is incorrect, the Client uses
KWin's default palette.
The idea behind this property is to allow an application with a
custom color scheme to tell KWin which color scheme the window
decoration should use. So that the window looks as a solid pattern
again.
KWin core can access the QWindow of the decoration instead of the
QWidget. This is a preparation step to allow QWidget based window
decorations without any QWidgets at all.
KWin core makes already use of this new accessor to get the window Id
which is also on QWidgets provided through the QWindow.
The xcb sync protocol is incorrectly defined (see [1]) which results in
xcb_sync_create_alarm not creating a valid alarm. To work around this
issue we only create the alarm without setting the int64 values. For
those we use the XLib XSyncChangeAlarm call after we verified that the
alarm got created. This unfortunately reintroduces linking against
libxext. But at least resizing works again.
[1] http://lists.freedesktop.org/archives/xcb/2013-June/008375.html
Behavior seems to have changed in Qt 5. Without doing the move the deco
has a wrong position and all mouse interaction is broken after the first
resize.
And with this change Oxygen windeco in compositing is fully functional!
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
The property is of type bool and maps to isMaximized and not to
maximizeMode.
Replaces the pure virtual method which the Decoration had to
implement. Instead the Decoration can now connect to the signal.
For KCommonDecoration there is no change at all except that the
invoked method is turned into a slot.
Martin Gräßlin