Double tooltips

Vladimir Prus ghost at cs.msu.su
Wed Sep 8 14:22:54 UTC 2010


On Wednesday 08 September 2010 17:49:14 David Nolden wrote:

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

It will work fine, because author of new plugin will specify

 - "lower priority that A"
 - "higher priority than B"

where A and B are just strings. And this works completely independently
from the order of other elements.

In other words, numeric priority (integer or float) requires that you
establish a total order on the set of all possible plugins
(including third-party closed source not-yet-written plugins).
An alternative is to allow plugins, perspectives or something else
to establish partial order, and then have kdevelop compute total
order at runtime. Because at each moment when KDevelop runs, it has
a fixed set of loaded plugins, computing a total order is straight-forward.


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

I don't think I ever had this question -- even when not debugging. Presumably, because it's
common practice to use special naming for data members.

> is it defined in one of its parent classes?

Well, it's generally considered very bad idea to have non-protected
data members, so if one can access a data member in the current
class, it's defined in the same class ;-

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

I guess this is useful sometimes when browsing the code.

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

You must be joking here. I never in my life saw any C++ code, or Java code,
which has significant number of comments on variables. Instead, naming
variables as necessary is used, like 'number_of_iterations'.

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

Except that when debugging, you most of the times care about the values,
not about randomly poking at code.

Imagine that you debug a loop that appends elements to variable 'result' declared
above the loop. You want to check the current value, and in addition to the value,
see a second tooltip which informs you about the name, type, the scope and
declaration location. This is just not useful because you've just stepped through
declaration of 'result' and getting "this might be interesting" tooltips
on each step will be a distraction.

In fact, when you are wondering why 'result', or any other variable, has the
value it has, you should really know what type it has, where it is defined,
and what should it contain. In most debugging cases, you have quite local
context, and where a local context is not sufficient, you better have some
global understanding of the code -- for example achieved through browising
the code in the "Code" area.

- Volodya




More information about the KDevelop-devel mailing list