Tooltips to QML: PlasmaCore.Dialog questions

[Marco Martin]

On Monday 18 June 2012, Mark wrote:
> On Mon, Jun 18, 2012 at 1:52 PM, Marco Martin <notmart at gmail.com> wrote:
> > On Monday 18 June 2012, Mark wrote:
> >> Here is what's wrong with it.
> >> 1. I "need" to use the popupPosition function. But for which purpose?
> >> I can perfectly align my tooltip using X and Y based on the component.
> >> Actually, my earlier issue of having a default 100x100 sized dialog is
> >> because i wasn't using popupPosition! Yeah, go figure that one out. I
> >> just don't like the fact that i need to use that function. What i am
> >> doing right now is calling popupPosition (because it has to be done)
> >> then just use my own X and Y since the popupPosition isn't even
> >> working as i want it. So yeah, i'm really doing
> >> dialog.popupPosition(null, Qt.AlignCenter) because i have to..
> > 
> > yes, this function is ugly, however, let's backtrack a bit to see why it
> > does exists:
> > this is about positioning an x11 top level window on screen, coordinates
> > you have no idea in qml because they don't have a relationship with the
> > position x and y of an item or even the position mapped to the scene
> > coordinates, so you need somebody that tells you a "correct" position
> > that has also to take into accound problems like actially fitting into
> > the screen (and not cut a piece away), popping up in the right screen,
> > taking into account extended struts to take panels into account.
> > 
> > that's why as soon you touch an x11 window things get ugly ;)
> 
> I fully understand your case and it makes sense. No issue about that.
> The issue i have have is that i simply don't have an Item object to
> run popupPosition against! What i'm getting is just a simple QRect

so, two different problems here:
is the dialog not appearing if you don't run popupposition before? if this is 
the case this is indeed a bug that should be fixed, but is completely 
unrelated from what is needed there.

let's take a step back, so what's needed here.. a tooltip.
that's how they work in plasma:
an item (qgraphicswidget at the moment, what we want is for them to work on 
any graphical item, ie any object with x,y,width,height properties) has some 
extra information attached to it (TooltipData in libplasma) and after some 
trigger (ie mouse over) it get displayed.
maybe in a tooltip, maybe discarded on touchscreen, maybe spoken with 
texttospeech if some accessibility option is on. (note that in libplasma, the 
ToolTip class is private and not exposed in any way)
in the idealworld(tm) the fact that the actual representation is a tooltip is 
utterly irrelevant.
I would also love if the qml version would still be as private as the old one, 
but unfortunately is very difficult to have properly private qml components.

so, the two actually relevant things here (and thus that should be api 
accessible in some way) are the information and the item is attached to.

> with the position of where a given widget is positioned that should
> have a Dialog on top of it. Then i manually calculate the position in
> QML with this exact code: http://paste.kde.org/502508/

positions should never, ever be calculated in javascript, there are corner 
cases that you can't even notice because you don't have info on the usable 
work area geometry.
 
> Now i could go a few ways here.
> - Don't send the QRect to QML, but send the QGraphicsWidget to QML
> which seems to be very well hidden. I won't say it's impossible
> because nothing is in C++, but it certainly is very difficult and
> something i'd like to prevent

that is the way is designed to work and certainly the way it should work. so 
if it has become very difficult for some reason, there is some layer of 
implementation that is not doing the right thing.

the code that actually positions windows should be only a centralised one, for 
behavior consistency and for the previously mentioned corner cases that may 
lead to an incorrect position in so many ways.
and that centralised libplasma function is binded there in popupposition.

> In my case i simply don't need popupPosition and i don't even have a
> use for it. What i would really like is if PlasmaCore.Dialog could
> start working without that function. That would really help me.

again, it is indeed a bug if the dialog doesn't appear without having called 
it once. however it should never, ever be manually positioned

> >> 2. This is a very important one which is not possible in the current
> >> dialog. When you hover your taskbar to some element that has a bigger
> >> tooltip (like the network manager icon) i want the tooltip to resize
> >> in an animated way. That's not possible because width and height are
> >> read-only!
> > 
> > resizing X11 windows is quite slow (and asynchronous, even), so accessing
> > it directly from qml would have quite slow and cpu intensive results.
> > until wayland the only possibility would be approximating smooth
> > resizing with a kwin plugin
> 
> Right, so this one is probably impossible in it's current form.
> Unless we make the window the full vertical screen height and simply
> position a QML element inside it. That would be very nasty but make
> the animation fluid without the need to resize the window. I don't
> know how feasible this option is.

tought about it and is indeed a possibility, but there are problems with it:
* it requires composite to be on
* it blocks mouse input on the whole screen unless setting complex input masks
* it's afterall still a fullscreen argb window so again an huge performance 
bottleneck

Cheers, 
Marco Martin