QML Tooltip progression. Hitting a few snags.

[Mark]

Hi,

Today was quite an interesting day with QML tooltips. One issue after
the other popped up.

What i have right now are working tooltips in a very rough shape. The
icon provided is also being shown in the tooltip and overall it looks
somewhat decent to continue to the next step. That would be to make
Dolphin and System Settings usable with these tooltips.

Sadly, while improving it further, i've hit a blocking issue that i
can't fix. The following issues arose of which the 2nd one is blocking
me right now.
1. Somehow when moving the cursor from an item that shows a tooltip
(like the tasks) to another item that shows a bigger tooltip (like the
pager) the result is a messed up layout: http://ompldr.org/vZWUyNw
This doesn't happen if i directly hover over the pager icon for the
tooltip. I haven't found a cause for this. (note, the position itself
is OK here, but done manually which is wrong)
2. Tooltips positioned using popupPosition are positioned directly
above the item where they need to be positioned:
http://ompldr.org/vZWUyNg This is the way it's currently designed and
Marco doesn't want to break the design in the KDE 4.x series. This is
something he will look into for KF5.
3. The height of the tooltips cannot be animated because height (and
width) are read-only. Furthermore, since it's a window, it's likely to
be slow as well due to X11 resizing stuff.
4. added to this is my dislike against PlasmaCore.Dialog. I simply
don't like it but gave it my best try to use it.

The first one is something i can work around. Third is also something
i can live with, but combined with the issues i had before and along
with my dislike for PlasmaCore.Dialog and the fundamental design
change that needs to happen to make it usable for tooltips makes me
think that i should perhaps do things a bit differently.

Marco also suggested that i copy the current PlasmaCore.Dialog C++
side and adjust it for the tooltip needs. That's the part where i
really could use some help in deciding how i should go further with
this. The side effects are not really what i'd like to see. If i
follow this approach it means that the (to be made) libTooltip (which
was supposed to be as clean as possible with as little dependencies as
possible) is suddenly going to link against Plasma. Which was the
exact reason why it should be split in it's own library to prevent a
plasma dependency! Note that any application using the lib will need
plasma, but if i could have used PlasmaCore.Dialog it would be a
runtime dependency. Now it looks like it's going to be a compile time
dependency as well which kinda beats the purpose of making a library
out of it.

So these are the options i currently see:

- Abandon PlasmaCore.Dialog, copy the C++ side behind it and fix it
according to my needs. This also means that i will have a custom QML
import where that new component will be living. Added dependency of
plasma.
- Add a experimental imports folder "experimentalcomponents" where we
don't promise backwards compatibility or even that the import exists
in the next release. Add a ExperimentalComponents.Tooltip (or Dialog)
which is tailored for tooltips and my needs and probably based on the
current PlasmaCore.Dialog or directly on Plasma::Dialog. I would
continue with continue with the tooltip stuff in a library that can
exist without a dependency on plasma.

Which option is the way to go? I prefer the "experimentalcomponents"
way. Or is there another (easier) way that i haven't even considered
yet?

Your input would be very helpful.

Cheers,
Mark