A new ClientModel is added which provides multiple different views on
KWin's Clients. The model is organized as a tree model supporting the
following levels:
* activities
* virtual desktops
* screens
* none
The levels can be ordered in whatever way one wants. That is the tree
structure can have an ordering of activities then virtual desktops or
the other way around.
In addition the model provides Exclusion flags to exclude clients of
certain types. E.g. it's possible to exclude all windows which are not on
the current desktop or all windows which are of type dock.
The model gets automatically updated whenever a Client is added/removed
or changes a state in a way that it should be excluded/included.
The ClientModel is not directly exported to QML. Instead there are
specific sub classes for certain common orderings. This solutions is
chosen to workaround some limitations of QML. The initial idea was to
use a property taking a list of the levels, but this doesn't work because
we are not notified when the QDeclarativeListProperty changes.
Currently the following models are provided to QML:
* ClientModel -> no restrictions
* ClientModelByScreen -> ordering by screen
* ClientModelByScreenAndDesktop -> screen, then desktop
These can be used to get all Clients:
ClientModel {
}
Or to get the classic Present Windows on current desktop:
ClientModelByScreen {
exclusions: ClientModel.OtherDesktopsExclusion | ClientModel.NotAcceptingFocusExclusion | ...
}
Or to get the classic Present Windows on all desktops:
ClientModelByScreen {
exclusions: ClientModel.NotAcceptingFocusExclusion | ...
}
Or our well known desktop grid:
ClientModelByScreenAndDesktop {
id: desktopGrid
exclusions: ClientModel.NotAcceptingFocusExclusion | ...
}
To support filtering as known by the Present Windows effect one can use
a ClientFilterModel, which is a QSortFilterProxyModel filtering on
window caption, role and class:
ClientFilterModel {
id: filterModel
clientModel: desktopGrid
filter: filterItem.text
}
In case it's a tree level obviously QML does not support this correctly.
So we need to use a VisualDataModel:
VisualDataModel {
id: clientModel
model: filterModel
Component.onCompleted: {
clientModel.rootIndex = modelIndex(0);
clientModel.rootIndex = modelIndex(0);
clientModel.delegate = thumbnailDelegate;
}
}
As we can see, the rootIndex has to be set to the level which contains
the Clients. Also it seems to be important to create the delegate after
the model index has been set. The idea is to have only one ClientModel
and multiple VisualDataModels if multiple views on the data is needed.
The model has been tested with a painful modeltest session. It looks good
so far modulo the listed limitations and that modeltest is not liking
closing Yakuake in the ClientModelByScreenAndDesktop setup, though it
works fine in real world testing.
REVIEW: 109604
Makes it a little bit easier to use a ThumbnailItem for a Client. E.g.
ThumbnailItem {
client: model.client
}
instead of mapping the windowIds, which is rather uncomfty.
Two new properties saturation and brightness are added to the
ThumbnailItem which can be set from QML.
The properties are honoured by the Scene when rendering the thumbnail.
Instead of calculating the screen number each time screen() is invoked,
the screen number gets stored in a private member variable and evaluated
whenever either the screen count changes or the Toplevel's geometry
changes. During move/resize the screen property doesn't get updated. The
update is delayed till the end of the move/resize operation.
REVIEW: 109715
and btw. replace legacy "ignoreposition" by "ignoregeometry"
this will allow to use "apply initially" as "force" used to act
(ignore position on placement) and "force" to prevent clients
from reconfiguring themselves (to not break a tabgroup or to just
not be annoying)
BUG: 311720
CCBUG: 252314
REVIEW: 109691
FIXED-IN: 4.11
Also harmonize script parsing - any combination of animationarray
and global animation setting that results in a valid animation is
possible using the global settings as default on the array values
REVIEW: 109212
this broke re-embedding clients
XReparentWindow causes an unmap of mapped clients, currently leading into releaseClient()
This will (among other) eg. reparent the client to the root and this is (usually?) executed after the original XReparentWindow, so the client does not end up where it's supposed to be.
REVIEW: 109484
REVIEW: 103948
BUG: 91703
BUG: 299245
FIXED-IN: 4.11
- The setting is ignored, the decoration always gets a "true" for it
- moving a maximized window requires breaking a "strong" snap (1/16 of screen height - unless you use quick maximization)
- all snapping is done towards the client, not the frame
- QuickTileMode is exported to the decoration (just as the maximizeMode) so that it can fix the bordersize alongside that.
not that i really like using QWidgetAction, but it'll
prevent the popup from autoclosing.
Introduce activityUpdateBlocking to prevent users from
removing the popup under their fingertips
BUG: 283309
FIXED-IN: 4.10.2
REVIEW: 107762
I've no real idea what breaks the theme -> qml assignment but the patch
re/creates the theme object (just as the engine and component) with the theme
BUG: 316033
FIXED-IN: 4.10.2
REVIEW: 109273
The complete dialog is moved into a Loader item and it gets loaded on
first change of virtual desktop. This change should result in less
parsing on startup and moving the cost of the loading to the time when
its really needed.
REVIEW: 109639
The hack used to be used to hide windows before they get embedded into
another window. This has been wrong on multiple levels:
1. it does not belong into a window manager - the window should take care
of this by itself
2. Window title is not a proper way to identify windows
3. Using D-Bus to inform an X11 window manager about windows which should
not get managed is rather strange
4. The hack only works with KWin, but not with any other X Window Manager
5. Windows identified with this hack still appear in Alt+Tab, that is
they are managed after all. Only a flicker is suppressed
6. Such windows are shown in the taskbar which nicely illustrates how
wrong a D-Bus call to the window manager is
That the hack has been introduced for Java Applets in KHTML also shows
that this is wrong. Why does Gecko and WebKit not need such a hack? Why
is KHTML tied so closely to X11 and KWin? Having a hack for a technology
which is obsoleted (Java Applets) and shouldn't be used due to security
issues is another reason to no longer support this hack. This usage has
been removed from KHTML as of 67939b1 of kdelibs git repo.
REVIEW: 109450
With 4933f08ae49328e36e2654434d28917310882ee5 the KDecorationBridge
interface became public to allow Compiz to easily implement the class.
From a KWin perspective this change did not make much sense. The Bridge
is meant to be the interface towards KWin. It is an internal interface
and exporting it doesn't change the fact that it is internal.
The change got introduced in a time when it was still common to use
Compiz in the kde-workspaces. This has changed. None of the top ten
distributions on distrowatch are shipping the integration parts of Compiz
in an up to date version. Most distros are still on Compiz 0.8, which
requires manual patching to keep up with changes in the decoration API.
Distros on Compiz 0.9 are not shipping the KDE integration - this
includes Ubuntu.
Given this development it is no longer justified to have additional work
on KWin side and because of that the API which should be internal is
marked as internal again.
In case Compiz is still interested in providing the kde-window-decorator
the header file can easily be pulled from our repository. In addition
this patch includes a method
int decoration_bridge_version()
which returns the current bridge API version. Kde-window-decorator can
resolve this method and verify that the version is not higher than what
is supported. The version number is provided in kdecoration.h by the
define KWIN_DECORATION_BRIDGE_API_VERSION. We will increate the version
number once per release in case the bridge changed. 4.11 will have the
version number 1.
This change in behavior has been discussed and agreed in [1].
The change also unexports KDecorationBridgeUnstable. This class should
have never been exported, it was incorrect and the parent class had not
been exported anyway. This is just a note to indicate that it is not an
ABI break and there is no reason to increase the so number.
[1] http://lists.kde.org/?l=kwin&m=136335502805911&w=2
CCMAIL: compiz@lists.freedesktop.org
CCMAIL: dev@lists.compiz.org
REVIEW: 109536
