Tool tips ideas

Emdek emdeck at gmail.com
Sat Apr 4 12:27:51 CEST 2009


> what are the use cases?

For example my friend is working on STasks plasmoid (that Windows 7 taskbar clone) and he completely changed the layout of task tool tip, added close icon, moved text to top and later he want to make title text scrollable when it is too long to show it in one line (personally I don't like scrolling idea...).
In my applet there are launcher together with tasks and for consistency I'm displaying previews of files (for example if there is entry for image or video etc.) and it looks nice only when it is shown in the same way like windows live previews (this could be maybe solved by adding kind of method that adds file preview or set image as preview that looks like current window preview, with frame).
I'm using also middle click on preview to close or left to raise it or iconify.
Currently I'm using these tool tips also as kind of group menu when left clicking (there could be added support for raising - shown in grid - and iconifing groups of windows) and there is even kind of context menu (yes, I know, context menu in tool tip is something strange, but this is only experiment).
Additionally my applet tries to add window previews also when there is no Compositing or we don't use KWin also could be solved by adding possibility to set image that has frame decoration and is placed instead of window preview).



> what we don't want however are random things inserted into these tips  
> because
> then:
>
> * we can not guarantee consistency
> * we can not easily change how toolitps are displayed (due to external
> assumptions about them)
> * we can not provide non-visual tooltips mechanisms (think about the
> possibility of showing tips on a remote system or display, for instance)

Maybe there could be still possible to set current properties as fallback?



> so.. instead of starting with a "solution", let's start with some use  
> cases
> and figure out how to fulfill them.

Yes, of course, if it is possible to do in better way, then we don't need this, because this is only ultimate solution if there is no other and better way to do it.



> it's not just the move animation. never, ever assume that what you see  
> right
> now is what it will be like tomorrow or on a different type of computer
> system. so even if these implementations managed to get the moving  
> animation
> working through some magical line of code, it would still be wrong. :)

Right, this is why I don't want to use custom things too much, it is better when they are done upstream (like finally multiple previews).




More information about the Plasma-devel mailing list