Double tooltips

[David Nolden]

2010/9/8 Vladimir Prus <ghost at cs.msu.su>:
> On Wednesday 08 September 2010 16:31:32 Niko Sams wrote:
>
>> On Tue, Sep 7, 2010 at 21:43, Vladimir Prus <ghost at cs.msu.su> wrote:
>> >
>> > I see that while in Debug area, hovering over a variable gives me two
>> > tooltips -- one from contextbrowser and another from debugger, which
>> > is clearly not nice. The contextbrowser tooltip is created in
>> > kdevplatform/plugins/contextbrowser/contextbrowser.cpp, see viewCreated
>> > and textHintRequested.
>> >
>> > Does anybody have any opinion how this should be fixed? It seems ideal to
>> > - Make each View aware of the Area it belongs too
>> > - Make each Area specify a list of 'tooltip providers' it allows
>> > - When installing tooltip handler, check if the area of the view allows
>> > what we're trying to install.
>> >
>> What do you think about a priority system? So if debug+contextbrowser are
>> avaliable debug has a higher priority.
>> I think the implementation would be much easier....
>
> Why do you think implementation will be easier? I think that priority system
> using numerical priority would be wrong, since it's impossible to assign
> integer priorities if you don't know all possible plugins. It's much
> better to use explicit priority comparisons, like "org.kdevelop.tooltips.Debugger
> is higher priority that org.kdevelop.tooltips.Context", but if such explicit
> comparisons are used, the implementation complexity will be around the same.

Any functional priority comparison system can also be mapped to an
integer priority comparison system, and the integers are much easier
to manage.

 I actually think the priority system already exists. It is used to
order the tooltips (highest priority should be upmost).

@Vladimir:
In KDevelop tooltips have grown so useful that it's not that important
anymore that they are "Small & Light". It's more important that they
are available when the user requires them, because else it may lead to
a lot of frustration (the user gets used to all the information the
code-tooltip delivers, and gets frustrated when the info isn't
delivered in a moment he requires it).

I will try to fix the overlap-problem very soon. I've proposed already
earlier that a tooltip could also have an "exclusive" flag, allowing
it to hide all other tooltips. The debugger could use this to enforce
its tooltip being shown alone. However since you don't know the
usecases, you cannot really be sure which tooltip you really need to
show right now to fulfil the users demand.