some dataengines can have a different set of keys for each item (ie metadata dataengine) the whole mapped roles must be the complete superset
this is not very efficient, but unfortunately is necessary.
(another reason why DataContainers should become models)
Implementation of a proxy to make it easy to declare tooltips in QML,
that will use Plasma::ToolTipManager to display tooltips in any item
that is declared in QML.
The syntax is:
import org.kde.plasma.core 0.1 as PlasmaCore
PlasmaCore.ToolTip {
target: id_of_the_target
mainText: "hello"
subText: "world"
image: "konqueror"
}
The syntax looks pretty straightforward and simple. "id_of_the_target"
is the id of the element which will show the tooltip in case it's hovered.
If the target is a QGraphicsWidget, the code path is really simple but if
it's a QDeclarativeItem, then we create a wrapper (that is a QGraphicsWidget)
and setup that in a way that we set this wrapper as the target on Plasma's
API. For libplasma2 we may want to change this so it's more generic (and
also put this together with the components).
Right now there is two open issues for me:
1) we should use "image" or "icon"? Allowing the use of a image that is
a string that identifies the icon for KIconLoader seems simpler and more
beautiful to me, but it would be nice to specify a random QPixmap. Besides
being able to use the bindings for QIcon it doesn't look very good. Marco,
do you have any thoughts on this issue?
2) for touch oriented UIs, the tooltip as it is right now is not very
useful. Is there any "touch" scenario where we may want to use them?
CCMAIL:mart@kde.org
Signed-off-by: Artur Duque de Souza <asouza@kde.org>
We are going to need the declarative container for the tooltips,
so it makes sense to put this guy in it's own files.
Signed-off-by: Artur Duque de Souza <asouza@kde.org>
We are going to need a proxy for the theme anyway, so we need
this guy complete anyway. Let's forget about the idea of exporting
Plasma::Theme directly.
Signed-off-by: Artur Duque de Souza <asouza@kde.org>
We should export name, font, windowTranslucencyEnabled and homepage
as well. Later we will just put all the properties on the Plasma::Theme
itself and export it.
Signed-off-by: Artur Duque de Souza <asouza@kde.org>
If you try to connect a source that is already connected, it should
return and not create a duplicate of that source.
Signed-off-by: Artur Duque de Souza <asouza@kde.org>
Changing to Qt::QueuedConnection delays setupData().
this makes the dataChanged() signal arrive to qml only when the full
batch of setData has been done.
this in turn doesn't let incomplete data arrive to the model, making an
incomplete role mapping.
should fix the QML version of Lionmail
CCMAIL:sebas@kde.org
setting the mainItem property of a Dialog element, it will create a top level window with that item as the graphicsWidget()
right now it works only with QGraphicsWidget{} elements, Plasma::Dialog will be given the api to make this work with any QGraphicsObject as well.
* possible to connect multiple sources
* use a normal QMap instead of the quirky qdeclarativepropertymap
* DataModel can be connected to multiple sources as well
* possible to use them with dataengines such as activities and tasks where the first level keys are the "roles" themselves
(all examples in playground have to be adapted)
svn path=/trunk/KDE/kdebase/runtime/; revision=1194216
some have many keys one for each item.
bind a new DataModel into QML that will be associated to a specific DataSource and a key pattern
an exact one like "items" of rss
or a partial regexp one like "KnowledgeBase-[\d]*" like the ocs engine
in this way is not necessary to change how those dataengine works and is possible to use them in QML without headaches
svn path=/trunk/KDE/kdebase/runtime/; revision=1189953
make it available as a QAbstractModel, so will be possible to categorize it
(considering to put it behind a qsortfilterproxymodel to make it easy to do filtering)
svn path=/trunk/KDE/kdebase/runtime/; revision=1189920
