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

[Emdek]

On 09-06-2009 at 20:09:34 Aaron J. Seigo <aseigo at kde.org> wrote:
> 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.

OK, right.
I'm not sure if click position is really needed, I can imagine only that  
it could be used for positioning window menu for preview or something like  
that.


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

What about showing them in grid (if there is more than x windows)?
Scrolling could be also good idea, for example we could show two arrows on  
sides of tool tip and scroll previews when hovering over arrow (maybe also  
with mouse wheel).


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

And what with idea of using tool tips instead of group menu?
I think taht if "window symbol" could be clicked and used to manipulate  
window state with Composite then it should also work without it, but in  
different way (for example vertical list of clickable window titles).
It is more consistent and clickable property won't be ignored in that case.