[PATCH] make window preview support mouse click in plasma tooltip

[Aaron J. Seigo]

On Tuesday 09 June 2009, Emdek wrote:
> > do we need the screen position of the click? not for window previews,
> > probably, but for links it might be useful?
>
> Could it be possible to send whole event object? Then we got position,
> buttons etc.

... and then need to bind the entire event object into all the script runtimes 
and make sure people don't do "unplasma" things with the interface as a 
result. since we need to say "this was clicked" anyways (unless we expose the 
actual tip widget to the user of the tooltips, which is not going to happen), 
passing an actual event object has limited value and is really the easy way 
out. 

we should think about what is needed and what we want to make possible (and 
what we want to not make possible as well) and provide an api that does 
exactly that.

> > i'd like to avoid having multiple signals for what gets clicked as well,
> > though perhaps having one for window previews and one for links might
> > make
> > sense.. hm.
>
> In previous discussion it was decided to always use KUrl (also for passing
> wid) but two similar signals looks cleaner probably.

> >> And now when we will have tool tips that could be hovered then we should
> >> add that glow animation for previews (as discussed).
> >
> > that's an orthogonal feature, but one i'd like to see in there
> > eventually,
> > yes.
>
> OK, so I'll try to prepare path when work on 4.4 will begin. But there is
> small problem, in my applet each preview has own widget (I could simply
> use enter and leave events), but in Plasma there is only one big widget.
> Is there easy and efficient way to check when mouse enter and leaves given
> rectangle in widget (other than calculating it with every mouse move)?

well, calculating on mouse move is how regular widgets do it too, so it's 
probably not less efficient. it's not as easy, but then this:

foreach (const QRect &rect, m_windowPreviewRects) {
     if (rect.contains(event->pos())) {
         hover(rect);
    }
}

isn't exactly rocket science either :)

(the hover() call there is a simplification, admittedly; it would need to 
unhover the old one, and only hover effect the new one if it isn't already 
hovered; which means the need for a state variable to store which is the 
currently hovered rect)

> But in case of default tool tips this would need change in limit of
> windows shown in tool tip

yes; probably need to shrink them or else provide some scrolling interface or 
some combo ... shrinking is probably enough.

> (but are people really grouping more than four
> tasks very often?).

it happens...

> There is also case of Composite less or with thumbnails disabled, but for
> them we can show vertical list of tasks (maybe this could be also used
> when we have more than four tasks in group).

.. in this case the tooltips should be "normal" and not clickable.

> Additionally, as I said some time ago, window titles under preview would
> be very useful (especially when grouping by application).

yes, that would be a nice addition, having seen them in action in your widget.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090609/228f2bc0/attachment.sig