Bug 68015: Variables/Watch Window closes on first view

[jbb]

[snip]
> 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.

Hmm, yes, nicely reasoned.

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

1 and 2 sound good to me.
Is 3 an improvement? Well, yes, it probably is :-)

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


Does anybody disagreed that this should be done?

> - Volodya

Would you like to attempt this?

jbb