Bug 68015: Variables/Watch Window closes on first view

[Vladimir Prus]

On Thursday 19 May 2005 00:18, Alexander Neundorf wrote:
> On Wednesday 18 May 2005 11:55, Vladimir Prus wrote:
> ...
>
> > 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.
>
> I also had a look at exactly the same issue some time ago and found out the
> same.
> Another idea would be to make some panels always sticky (e.g. the debug
> panel), but this is AFAIk currently not possible with KMDI.
> So my personal workaround is to make the debug panel manually sticky :-/
> Would be nice if you would find a better way :-)

Let's clean up the terminology -- are you talking about the "overlap" button 
on tool windows? Yea, I think having it clicked by default for variables view
would be great. Is it really true that KMDI does allow to control this 
programmatically?

Actually, I think I have issues with framewidget as well. Suppose I have
two threads -- first is opened and first frame is selected. Frameview is in 
"overlap" mode. I open second thread, and framewidget immediately switches to
to first frame of that other thread. Why? I did not ask it to switch, and
I might (real example), have 15 threads only two of them are of interest to 
me. So, I'll open each thread in turn until I find (by looking at backtrace),
the one I need. With the current design, I can get several windows, showing 
source files where those "uniniresting" threads are.
When I'm not in "overlap" mode, opening a thread immediately closes the
framestack window. Again, if I'm looking for a specific thread, this is not 
good.


There's some strange interaction between variables view and framestack view.
When I click on a frame in a framestack view, the source window is updated to
show the location corresponding to that view. The variables view (which shows
frames too) is not updated -- the current item is not changed.

When I open a frame in variables view, the framestack view is updated to show
that frame. However when I click on an already opened frame in variables view,
the framestack view is not updated. This behaviour is not consistent -- either
there should be no frame switch when I look at frame vars in variables view, 
or there should be frame switch when I click on a frame in variables view, no
matter if that frame is closed or not.

I think the the best interface would be:

1. Opening a tree item in framestack view does not switch current frame
and does not switch shows source file.
2. Only explicit selection of a frame in framestack view changes current 
frame, and shows the source.
3. The variables view should show only variables in the current frame.

If point 3) is not OK, then at least the variables view can be modified to
not switch stack when opening item corresponding to frame.

Opinions?

I think this can be implemented by making variables and framestack widget
emit some other (new) signals, not 'slotSelectFrame'. Currently, 
slotSelectFrame does many jobs -- it's switches the frame for showing the 
frame in source view, it produces backtrace, and it produces info about local 
vars. If more specific 'slotShowBacktrace' is introduced, we can avoid 
accidental switching to different frame in source view.

- Volodya












>
> Bye
> Alex