Tooltip when debugging

[Vladimir Prus]

On Monday 23 February 2009 14:00:50 David Nolden wrote:
> Am Montag 23 Februar 2009 09:10:02 schrieben Sie:
> > David,
> >
> > I have tried the approach you've implemented and I'm not sure it's ideal.
> > Essentially, your approach means that all plugins get hint request, and all
> > plugins try to show a tooltip, and then one with highest priority "wins".
> > This has a number of issues:
> >
> > 1. Given that some plugin might need time to fetch data for display, you
> > can get tooltip from one plugin to appear, immediately followed by tooltip
> > from another.

> I thought this was handled, I don't remember exactly though

> > 2. The 'priority' thing is hard to use. If we have a monolithic codebase,
> > you can globally assign priorities. However, if I'm creating a custom
> > KDevelop-based IDE? pulling plugins from different places, I no longer have
> > this luxury. Given two plugins A and B, the question which one should be
> > preferred provided of tooltip depends on what IDE one is creating, and what
> > perspective is active, and what not. This knowledge cannot be encoded as an
> > integer *inside* plugins A and B respectively.

> But well, you anyway have to prefer one tooltip over the other? We need a way 
> to decide..

Yes, you have to decide. But the decision should be made outside of affected
plugins. And if you make decision outside, you might as well say "I prefer plugin
A over plugin B", there's no need to introduce 'priorities'.

> > 3. It's fairly confusing that you get two different kinds of plugins
> > depending on what element you hover on.

> That's true

> > 4. I sometimes get a bug whereby two tooltips are shown -- one from
> > debugger and another from cpp support -- at different locations.

> Annoying..

> > So, I still would prefer if, in Debug perspective, the debugger be an
> > exclusive provider of tooltips. It's probably possible to implement this by
> > a check in cpp support code, or we can introduce 'itooltipprovider' and
> > allow a perspective to specify names of tooltip providers in priority
> > order.
> >
> > WDYT?
> The only problem is that IMO just because you're in the debug perspective 
> doesn't mean you don't want to navigate through the code. For example to jump 
> to the definition of a function, 

Doesn't Ctrl-Click work in all cases?

> place a breakpoint into it, etc. 

> So ideally we would find a way to use both at the same time. What about having 
> some kind of tab-bar at the bottom of the tooltip when there is multiple 
> tooltips? We could display the one with highest priority first, and allow 
> switching to other ones using the tab. In debug-perspective the debugger could 
> have the highest priority, in the code-perspective the navigation-tooltip.

Look, this is *tooltip* after all, and whilst ActiveToolTip does not place any
limitations on what kind of thing you can put into it, do you think that tooltip
with a tab widget inside it is a good idea? I think it will be very heavy-weight
mechanism, while the primary point of tool tip is that it's quick and small. 
If user wants to nagivate code while debugging, he can open context browser, after
all.

- Volodya