Double tooltips

[Vladimir Prus]

On Wednesday 08 September 2010 17:08:59 David Nolden wrote:

> 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 don't believe this to be true in any extensible system. If you have
a complete set of items, and partial order of those, then you can indeed
intoroduce a total order and then assign integers. However, if you have
10 elements in total order and assigned integers and 11th element comes
along that must have more priority that 6th and less priority than 7th,
then you're stuck in two ways:

1. There is just no integer that satisfied 6 < i < 7
2. Given that 11th element is provided by a third-party, its author does
not actually know how many standard elements are provided by KDevelop,
and that the "reference" elements were assigned priorities of 6 and 7
respectively.

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

Can we look at context toolview? It has:

- Name of variable
- Type of variable
- Scope (e.g. function name)
- Kind (e.g. "Variable definition")
- The file:line of declaration (clickable link)
- "Show uses" link.

The two actions are available from the keyboard and/or mouse, so let's focus
on the information.

I bet that 100% of users don't actually care about actual line where something
is defined. I also doubt they care about the name of the file, as soon as they
can nagivate to declaration. The "Kind" bit does not seem so much useful to
me either -- what was the last time you could not tell variable definition 
from a class name or from a function just by looking at the code. The Scope
item is likewise of limited use.

So, what is the exact information you want to see when *debugging* that
warrants confusing double-tooltip?

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

I know that every other IDE, when debugging, shows only debug tooltip,
and that users are fine with that.

- Volodya