The view is never shown or used in any way except to create the
QDeclarativeEngine. So instead of using a view as a wrapper, let's create
a QDeclarativeEngine and a Component and create the script from the
Component.
To have Plasma.Dialog working we also need to add the created script item
to a QGraphicsScene.
Following the approaches of other split out functionality Screens is a
singleton class created by Workspace.
The class takes over the responsibility for:
* screenChanged signal delayed by timer
* number of screens
* geometry of given screen
* active screen
* config option for active screen follows mouse
The class contains a small abstraction layer and has a concrete subclass
wrapping around QDesktopWidget, but the idea is to go more low level and
interact with XRandR directly to get more detailed information.
All over KWin the usage from QDesktopWidget is ported over to the new
Screens class.
REVIEW: 109839
This allows to move the slot to reset the decoration when compositing
got toggled from Workspace to DecorationPlugin and the custom cleanup
is no longer needed.
REVIEW: 109909
The define KWIN_SINGLETON adds to a class definition:
public:
static Foo *create(QObject *parent = 0);
static Foo *self() { return s_self; }
protected:
explicit Foo(QObject *parent = 0);
private:
static Foo *s_self;
There is an additional define KWIN_SINGLETON_VARIABLE to set a different
name than s_self.
The define KWIN_SINGLETON_FACTORY can be used to generate the create
method. It expands to:
Foo *Foo::s_self = 0;
Foo *Foo::create(QObject *parent)
{
Q_ASSERT(!s_self);
s_self = new Foo(parent);
return s_self;
}
In addition there are defines to again set a different variable name and
to create an object of another inheriting class.
All the classes currently using this pattern are adjusted to use these
new defines. In a few places the name was adjusted. E.g. in Compositor
the factory method was called createCompositor instead of create.
REVIEW: 109865
This code never worked (git blame ends at 05507ee2). The event type is
ColormapNotify (32) and not ColormapChangeMask (1<<23).
Nobody noticed for years so it seems like unneeded to be fixed.
REVIEW: 109912
There is only one instance hold by Workspace which means it should follow
the common approach with ::self and ::create.
The hasTabBox is completely removed as it's rather useless and the same
as the ifdef around the usages any way.
REVIEW: 109851
All activities related code moves into new singleton class Activities.
This class gets only included into the build if the build option is
enabled which means there are less ifdefs all over the code and it also
handles better the moc doesn't like ifdef case.
The class holds the list of open and all activites, the current and the
previous activity and the KActivities::Controller. It also emits the
signals for any activities related changes.
Workspace still contains some activities related code. That is the
adjustment on change of current activity. Nevertheless the code looks
much cleaner now and does not contain the confusing naming conflict with
takeActivity() which existed before.
In all the places where Activities got used the code got adjusted and
quite often the ifdef got added with a fallback for the disabled case.
LanczosFilter tries to discard all cached textures in the timer event by
getting the stacking order and iterating over it. But this approach seems
wrong from several aspects.
First of all the xStackingOrder does not include Deleted windows. So if
a cached texture still exists on an EffectWindow for a Deleted it would
not be discarded.
Also the xStackingOrder could result in an update from X because the
stacking order is currently considered dirty.
Last but not least the EffectsHandler::stackingOrder creates a temporary
list of EffectWindows - good for Effects but not necessarily useful
inside KWin core.
Instead the LanczosFilter gets the list of Clients, desktops, unmanaged
and deleted and iterates over them to check whether there is a texture to
discard.
REVIEW: 109954
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.
