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
thanks to emilsedgh for having the special super power of using precisely
what hasn't been properly implemented ... and then reporting it with
nice simple examples we can test with! THAT, my friends, is how it is done.