Re: Review Request 109604: Model to provide easy access to KWin's Clients from QML
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)
Hash/Map do not work as I need the ordering of Clients and not of the ids
- Martin
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109604/#review29660
---
On March 20, 2013, 1:07 p.m., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109604/
---
(Updated March 20, 2013, 1:07 p.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 Exclude 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 {
excludes: ClientModel.ExcludeOtherDesktops |
ClientModel.ExcludeNotAcceptingFocus | ...
}
Or to get the classic Present Windows on all desktops:
ClientModelByScreen {
excludes: ClientModel.ExcludeNotAcceptingFocus | ...
}
Or our well known desktop grid:
ClientModelByScreenAndDesktop {
id: desktopGrid
excludes: ClientModel.ExcludeNotAcceptingFocus | ...
}
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.
===
Plasma devs are added to get access to their QML knowledge :-)
Diffs
-
kwin/CMakeLists.txt ecddc55ed89cb4fcb143561e57534b1bb4ea3832
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
Re: Review Request 109604: Model to provide easy access to KWin's Clients from QML
---
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.
Changes
---
readding plasma - my script always deletes that...
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
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 109711: Fixes a bug in the KDE dataengine to use the POST method instead of GET which allows large text to be sent to the server
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109711/ --- Review request for Plasma. Description --- Fixes a bug where the default text engine 'kde' fails when pasting text longer than 513/741 characters in the PasteBin widget. The problem is that the generic dataengine 'kde' uses a GET request to send data to the http://paste.kde.org server which does not allow large text to be sent to the server. This patch changes the GET request to a POST request which fixes the bug. Bug Report: https://bugs.kde.org/show_bug.cgi?id=289647 This addresses bug 289647. http://bugs.kde.org/show_bug.cgi?id=289647 Diffs - plasma/generic/dataengines/share/backends/kde/contents/code/main.js 600950d Diff: http://git.reviewboard.kde.org/r/109711/diff/ Testing --- Thanks, Bhaskar Kandiyal ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
FYI: Platform content discussion in Qt
Hi, I can't find it now, but there was a note on one of the Plasma wiki pages about some of the limitations of how QML files are 'switched out' with platform content versions in a Plasma package (from memory, stuff like requiring a qmldir and not working with C++ plugins). I've chosen the longest possible path to fix that, and am working on adding platformcontent-like functionality into Qt (which the QML engine and Plasma could then easily use). There's a discussion going on in the qt-devel ML right now if anyone's interested: http://lists.qt-project.org/pipermail/development/2013-March/010564.html . -- Alan Alpert ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma Media Center meeting on 27th March
Hi, Thanks for filling out the doodle! From the entries, the best time to have this is on Wednesday 27th March at 3:15 PM - 4:00 PM UTC. Lets have the meeting then and get some awesome stuff for PMC! Cheers, -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Nepomukcontroller rewritten in QML
[...] These things should really be async. Especially if there can be multiple services that you have no control about, they will hang at some point, and then your UI is blocked -- never a good thing. We've had a non-funny amount of UI problems due to sync calls across IPC, or into Nepomuk (and sometimes both), and it gets you a blocking UI, and it really deteriorate the user experience. I agree, I have already changed all calls to use the async dbus api instead. So blocking the UI shouldn't be a problem anymore. I've added a new branch (nepomukcontroller-qml) to kde-workspace and asked for review on kde-core-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Nepomukcontroller rewritten in QML
On Tue, Mar 26, 2013 at 11:29 AM, Jörg Ehrichs joerg.ehri...@gmx.de wrote:
[...]
These things should really be async.
Especially if there can be multiple services that you have no control
about,
they will hang at some point, and then your UI is blocked -- never a good
thing.
We've had a non-funny amount of UI problems due to sync calls across
IPC, or
into Nepomuk (and sometimes both), and it gets you a blocking UI, and it
really deteriorate the user experience.
I agree, I have already changed all calls to use the async dbus api
instead.
So blocking the UI shouldn't be a problem anymore.
Nicely done! I did a quick look over the code and you're still using
QDBusConnection::sessionBus().interface()-isServiceRegistered
which unfortunately is a blocking DBus call. You can however replace it
with something like
QDBusPendingCall async =
QDBusConnection::sessionBus().interface()-asyncCall(QLatin1String(NameHasOwner),
QLatin1String(org.kde.NepomukServer));
QDBusPendingCallWatcher *callWatcher = new QDBusPendingCallWatcher(async,
this);
connect(callWatcher, SIGNAL(finished(QDBusPendingCallWatcher*)),
this, SLOT(serviceNameFetchFinished(QDBusPendingCallWatcher*)));
and in serviceNameFetchFinished you do:
::serviceNameFetchFinished(QDBusPendingCallWatcher *callWatcher) {
QDBusPendingReplybool reply = *callWatcher;
if (reply.isError()) { return; }
bool isRegistered = reply.value();
callWatcher-deleteLater();
And you're done.
There might be a possible race condition between this
and QDBusServiceWatcher though (unlikely, but still), so you might want to
initiate the QDBusServiceWatcher only in the serviceNameFetchFinished (or
whatever you'll call it) slot.
Cheers
--
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FYI: Platform content discussion in Qt
On Tuesday 26 March 2013, Alan Alpert wrote: Hi, I can't find it now, but there was a note on one of the Plasma wiki pages about some of the limitations of how QML files are 'switched out' with platform content versions in a Plasma package (from memory, stuff like requiring a qmldir and not working with C++ plugins). I've chosen the longest possible path to fix that, and am working on adding platformcontent-like functionality into Qt (which the QML engine and Plasma could then easily use). There's a discussion going on in the qt-devel ML right now if anyone's interested: http://lists.qt-project.org/pipermail/development/2013-March/010564.html . Thanks for the heads up, looking into it. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FYI: Platform content discussion in Qt
On Tuesday 26 March 2013, Alan Alpert wrote: Hi, I can't find it now, but there was a note on one of the Plasma wiki pages about some of the limitations of how QML files are 'switched out' with platform content versions in a Plasma package (from memory, stuff like requiring a qmldir and not working with C++ plugins). iirc only part on the wiki that talked about packages was: http://techbase.kde.org/Development/Tutorials/Plasma/PackageOverview#Device_specific_user_interface i think the limitation was on another thing, that wasn't about packages: we have also components (as in the hopefully standard qtcomponents set) in multiple versions for desktop and touch. we have just some components that are actually rewritten for touch usage, while most are just fine, but we have to install the whole set two times, because what we would want is: import org.kde.plasma.components 1.0 as... and import the right set, but the ideal way is (if we are importing touch components) to have a set of just the components that are rewritten for touchscreen, while falling back to the common ones for everything else, that now we can't do, so we have the whole set installed two times and we change the import paths depending from the platform, and that's not optimal. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109711: Fixes a bug in the KDE dataengine to use the POST method instead of GET which allows large text to be sent to the server
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109711/#review29910 --- Ship it! Ship It! - Aaron J. Seigo On March 25, 2013, 6:50 p.m., Bhaskar Kandiyal wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109711/ --- (Updated March 25, 2013, 6:50 p.m.) Review request for Plasma. Description --- Fixes a bug where the default text engine 'kde' fails when pasting text longer than 513/741 characters in the PasteBin widget. The problem is that the generic dataengine 'kde' uses a GET request to send data to the http://paste.kde.org server which does not allow large text to be sent to the server. This patch changes the GET request to a POST request which fixes the bug. Bug Report: https://bugs.kde.org/show_bug.cgi?id=289647 This addresses bug 289647. http://bugs.kde.org/show_bug.cgi?id=289647 Diffs - plasma/generic/dataengines/share/backends/kde/contents/code/main.js 600950d Diff: http://git.reviewboard.kde.org/r/109711/diff/ Testing --- Thanks, Bhaskar Kandiyal ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109712: Make it possible to use action groups with QMenuItem
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109712/#review29911 --- Ship it! Ship It! - Aaron J. Seigo On March 25, 2013, 7:24 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109712/ --- (Updated March 25, 2013, 7:24 p.m.) Review request for Plasma. Description --- Makes it possible to use the setActionGroup method. It's interesting in case we are displaying options in a menu, since this way we can offer a more appropriate UI. Diffs - plasma/declarativeimports/core/corebindingsplugin.cpp 169fd35 plasma/declarativeimports/plasmacomponents/qmenuitem.h 0f43418 plasma/declarativeimports/plasmacomponents/qmenuitem.cpp e8d590d Diff: http://git.reviewboard.kde.org/r/109712/diff/ Testing --- I have some code using it locally in muon. It works fine. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109712: Make it possible to use action groups with QMenuItem
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109712/ --- (Updated March 26, 2013, 8 p.m.) Status -- This change has been discarded. Review request for Plasma. Description --- Makes it possible to use the setActionGroup method. It's interesting in case we are displaying options in a menu, since this way we can offer a more appropriate UI. Diffs - plasma/declarativeimports/core/corebindingsplugin.cpp 169fd35 plasma/declarativeimports/plasmacomponents/qmenuitem.h 0f43418 plasma/declarativeimports/plasmacomponents/qmenuitem.cpp e8d590d Diff: http://git.reviewboard.kde.org/r/109712/diff/ Testing --- I have some code using it locally in muon. It works fine. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109699: Simplify the behavior of the main UI file in the chat plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109699/#review29912 --- This review has been submitted with commit ee48913d565524d37a32926554a0d3455d0d6574 by Aleix Pol to branch kde-telepathy-0.6. - Commit Hook On March 25, 2013, 2:18 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109699/ --- (Updated March 25, 2013, 2:18 a.m.) Review request for Plasma and Telepathy. Description --- These are some ideas I got from the last commit, let's see: * Provide a bigger minimum size, I thought it would never get to the minimum but it does sometimes, so we can better give a bigger minimum (which is still too small for a proper usage). * Rename preferredWidth/Height - implicit*. It seems like it's the proper way to call these. * When the plasmoid is empty, offer an empty preferred (uh implicit) size. Diffs - chat/org.kde.ktp-chat/contents/ui/main.qml 1ee042a Diff: http://git.reviewboard.kde.org/r/109699/diff/ Testing --- Tested it in plasma-desktop (it's very hard to test sizes with plasmoidviewer and such), I still have the Icon Tasks eating up my space, but I guess I have to debug other code to get around that. At least now it doesn't get as squeezed. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109699: Simplify the behavior of the main UI file in the chat plasmoid
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109699/ --- (Updated March 26, 2013, 8:03 p.m.) Status -- This change has been marked as submitted. Review request for Plasma and Telepathy. Description --- These are some ideas I got from the last commit, let's see: * Provide a bigger minimum size, I thought it would never get to the minimum but it does sometimes, so we can better give a bigger minimum (which is still too small for a proper usage). * Rename preferredWidth/Height - implicit*. It seems like it's the proper way to call these. * When the plasmoid is empty, offer an empty preferred (uh implicit) size. Diffs - chat/org.kde.ktp-chat/contents/ui/main.qml 1ee042a Diff: http://git.reviewboard.kde.org/r/109699/diff/ Testing --- Tested it in plasma-desktop (it's very hard to test sizes with plasmoidviewer and such), I still have the Icon Tasks eating up my space, but I guess I have to debug other code to get around that. At least now it doesn't get as squeezed. Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 109604: Model to provide easy access to KWin's Clients from QML
On March 21, 2013, 9: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
It did not look like you'd require any particular order - if this is correct,
you could just use Client* as keys.
- Thomas
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109604/#review29660
---
On March 26, 2013, 9: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, 9: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
Re: FYI: Platform content discussion in Qt
On Tue, Mar 26, 2013 at 6:07 AM, Marco Martin notm...@gmail.com wrote: On Tuesday 26 March 2013, Alan Alpert wrote: Hi, I can't find it now, but there was a note on one of the Plasma wiki pages about some of the limitations of how QML files are 'switched out' with platform content versions in a Plasma package (from memory, stuff like requiring a qmldir and not working with C++ plugins). iirc only part on the wiki that talked about packages was: http://techbase.kde.org/Development/Tutorials/Plasma/PackageOverview#Device_specific_user_interface Maybe it wasn't written down :P . There is the issue that by redirecting to files using a custom QNAM set on the QQmlEngine means that remote file limitations are applied, which means requiring a qmldir and not loading C++ plugins. i think the limitation was on another thing, that wasn't about packages: we have also components (as in the hopefully standard qtcomponents set) in multiple versions for desktop and touch. we have just some components that are actually rewritten for touch usage, while most are just fine, but we have to install the whole set two times, because what we would want is: import org.kde.plasma.components 1.0 as... and import the right set, but the ideal way is (if we are importing touch components) to have a set of just the components that are rewritten for touchscreen, while falling back to the common ones for everything else, that now we can't do, so we have the whole set installed two times and we change the import paths depending from the platform, and that's not optimal. If the selectors were implemented at a Qt or QML level, then you could easily apply them in your imports the same as you would in plasma packages. So that problem would be solved too. -- Alan Alpert ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
