Bug 68015: Variables/Watch Window closes on first view

Vladimir Prus ghost at cs.msu.su
Wed May 18 12:13:02 UTC 2005

jbb wrote:

> [snip]
>> 6. editDocument gets the KPart for the file, then gets widget for the
>> part and finally PartController::activatePart does
>>     widget->setFocus()
>> and KMDI hides the variables window.
> So, if the panel is pinned, why is the window hidden? Doesn't this look
> like the bug?

The panel is not pinned.

> Even if the panel isn't pinned, ideally, the window shouldn't close as we
> shouldn't set the focus away from the window we've just clicked in
> (although I can see why this is being done).
>> The attached patch fixes the problem for the case where you want to look
>> at variables in the current thread, but still does not work when looking
>> at vars in the other thread.
>> It's certainly needed to switch frame to get information about variables,
>> but then it's needed to prevent emitting slotShowStep. And in fact,
>> currently after showning the list of variables for a thread/frame,
>> debugger switches to that thread/frame. This behaviour does not seem
>> intuitive, maybe it's better to:
>> 1. Disable 'slotShowStep'.
>> 2. Switch to needed frame
>> 3. Get local vars.
>> 4. Swithc back to current frame
>> 5. Enable 'slotShowStep'
>> Opinions?
> Hmmm, I would expect that when expanding a list of variables in a
> thread/frame, we'd switch to that thread/frame.

I don't have a strong opinion here.

> Wouldn't it be better to look into the widget->setFocus() being the cause
> of the problems here.

So, in this specific case, we don't want widget->setFocus() call, right?
But that happens in:

   PartController::activate, called from
   PartController::editDocumentInternal, called form
   PartController::editDocument, called from 
   Debugger::gotoExecutionPoint, called from

and there are cases where we do want widget->setFocus() call. For example,
when clicking on specific frame in framestackwidget, we want the source
window to appear and stack windows to disappaer.
One way to selectively avoid setFocus call would be to set 'dont_focus' flag
in debugger part, and propagate this flag down through all the above
functions. That's not nice, and I wonder if there's better solution.

- Volodya

More information about the KDevelop-devel mailing list