Double tooltips

[David Nolden]

2010/9/8 Vladimir Prus <ghost at cs.msu.su>:
>> 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
That's why in practice we simply use float. ;-)

> 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.
However then the rule-based approach cannot find a solution too.

>>
>>  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
This one is often very useful.
> - Scope (e.g. function name)
Also very useful. Is this a global variable, is it defined in the
enclosing class, is it defined in one of its parent classes?
> - Kind (e.g. "Variable definition")
This also contains important information whether the thing is static,
whether the function is virtual, and all such stuff. You would have to
look at the declaration otherwise to get this info. It also contains
whether the function is inline, which might be important during
debugging.
> - The file:line of declaration (clickable link)
> - "Show uses" link.
>

And one more entry, which might even be most important: The comment.
It should tell you what the item you're dealing with does. Consider
for example you're debugging an integer. Through the debugger-tooltip
you see the actual real value. The code-tooltip below can show you a
comment like "Number of iterations" which describes the meaning of the
variable, and makes debugging easier.

> 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.
With the tooltip you can get a lot of information _without_ jumping to
the declaration, which saves a lot of time in practice. You can just
see the tooltip, and then decide "this is interesting" or "this is not
interesting".

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

Other IDEs don't have that useful code tooltips either. ;-)