QML Tooltip progression. Hitting a few snags.

[Marco Martin]

On Tuesday 19 June 2012, Mark wrote:
> Hi,
> 
> Today was quite an interesting day with QML tooltips. One issue after
> the other popped up.

but it's *very* useful that you made those issues pop up, don't see it as 
wasted time ;)

> 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

having seen a bit of the code, i think there is still the possibility that is 
the tooltip mainitem having the wrong size (otherwise would be clipped only at 
bottom)
would need some debug to say what is the size of mainitem and what is the size 
of the things it contains

> 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.

this doesn't depend from the position, that is correct.
depends from the fact that Dialog doesn't paint the borders that are near to 
the screen edge or to a panel.

now, this is ok for the use case of popups, because a) they are designed as 
objects that come out from the panel, b) when is attached to the screen edge 
it will accept input from the mouse until the very border (fitts law)

> 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.

yeah, i don't much see solutions to this one on x11 (waylaaand;).
iirc there was a kwin plugin in the works that tried to fake a smooth resize 
of windows with a transition of their pixmaps? is that thing still alive?

in brief, is not pretty, bit don't worry about size animation for now

> 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.

It's done for popups, and in order for popups to be consistent, freedom to do 
whatever with it must be sacrified

> 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.

I'm still not sold about moving tooltips outside libplasma. If this is so, 
using a different qml file that doesn't import plasma when an app is not ran 
in kde wouldn't be hard tough.
if it's outside libplasma also means quite a lot of code to be duplicated, 
tooltipmanager, tooltipdata, tooltip and pieces of corona such as 
popupposition (eh, there is really no way around every single corner case that 
function takes care has to be managed) at that point plasma2 could use that 
library and not provide a tooltip anymore, that's also an option.

It also means the tooltip won't use corona but a private scene. I always tried 
to limit the proliferation of private qgraphicsscenes, but looks like in qml2 
won't matter anymore since there is 1:1 correspondence scene/view.

in the end the easiest solution would be taking the current ToolTip private 
class, showel a QDeclarativeView in it as the main layout element and be done.

the reasons why Dialog is at the moment suitable are mainly two:
* it removes the borders when it goes at the edge of the screen
* it uses dialogs/background.svgz instead of widgets/tooltip.svgz for its 
background

i would really rather not add api to control those two things, given kdelibs 
is frozen and i don't think would be a good approach anyways.

> 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.

no, it doesn't have to be an import there are several other ways to do it, 
that in this case are more suitable.

a class name that will instantiate a c++ object can be registered from the c++ 
part with qmlRegisterType
or in this case even better, the whole qgraphicsview would be instantiated 
from the c++ part in the tooltipmanager itself (would be what is the ToolTip 
private class nowdays) so the qml would only manage the layout and won't know 
about the window at all (if in the end is decided to do an independent thing 
where is not an issue to have its own private scene it may even be a 
qdeclarativeview).
this is imo the best option.

Cheers,
Marco Martin