Review Request 109604: Model to provide easy access to KWin's Clients from QML

Wed Mar 27 07:19:58 UTC 2013

> On March 21, 2013, 10:06 p.m., Thomas Lübking wrote:
> > kwin/scripting/scripting_model.cpp, line 190
> > <http://git.reviewboard.kde.org/r/109604/diff/1/?file=120515#file120515line190>
> >
> >     considered to keep m_clients and m_ids as hash/map or at least a pair (implicitly documenting "this is assigned and has to be in sync")
> 
> Martin Gräßlin wrote:
>     Hash/Map do not work as I need the ordering of Clients and not of the ids
> 
> Thomas Lübking wrote:
>     It did not look like you'd require any particular order - if this is correct, you could just use Client* as keys.

the ordering needs to be somewhat stable. Currently new Clients are only added to the list, that's what I mean with it needs ordering. But thinking about it: the ids should apply to this ordering constraint as whenever a new Client is added to the list, the new id will be larger than all existing ids.

- Martin

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109604/#review29660
-----------------------------------------------------------

On March 26, 2013, 10:35 a.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109604/
> -----------------------------------------------------------
> 
> (Updated March 26, 2013, 10:35 a.m.)
> 
> 
> Review request for kwin and Plasma.
> 
> 
> Description
> -------
> 
> Model to provide easy access to KWin's Clients from QML
> 
> 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. This is
> currently still rather limited, as some signals from KWin core are not
> yet available. Also the model does not yet react on screen, desktop and
> activity changes.
> 
> 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.
> 
> Support saturation/brightness in ThumbnailItem
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   kwin/CMakeLists.txt f0795b4873ac58a06c737b200559fa76e3c9c11e 
>   kwin/scene.cpp 939f000f0c3d09ffacccb0b25c50f83f0010ef47 
>   kwin/scripting/scripting.cpp e124827174317ab6adbfdb90cec796a02e7bd2b7 
>   kwin/scripting/scripting_model.h PRE-CREATION 
>   kwin/scripting/scripting_model.cpp PRE-CREATION 
>   kwin/thumbnailitem.h f7dc4fe621e9cf2786794d1be55930ce79ca5c7c 
>   kwin/thumbnailitem.cpp 66b665a685188767201ada7d5cfbb32a0ea7ff0a 
> 
> Diff: http://git.reviewboard.kde.org/r/109604/diff/
> 
> 
> Testing
> -------
> 
> 
> File Attachments
> ----------------
> 
> Example PresentWindows/DesktopGrid QML
>   http://git.reviewboard.kde.org/media/uploaded/files/2013/03/20/main.qml
> WindowItemComponent.qml - needed for the example
>   http://git.reviewboard.kde.org/media/uploaded/files/2013/03/20/WindowItemComponent.qml
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130327/fef87cd5/attachment-0001.html>