[PATCH] Re: Bug 68015: Variables/Watch Window closes on first view

[jbb]

I've tried this patch and it does not seem quite right to me.

When stopping on a breakpoint the first frame is not selected and you have to 
click the frame to get the variables to be displayed.

I don't think we should force the user to click on a frame to get to see the 
current state of the local variables when we stop.

I suspect this isn't the intended behaviour?

jbb

On Sat, 21 May 2005 03:08, Vladimir Prus wrote:
> On Friday 20 May 2005 12:10, jbb wrote:
> > > 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 :-)
>
> ......
>
> > Would you like to attempt this?
>
> Attached is a patch which avoid switching the frames on opening a thread
> item in framestack view. To simplify my task, I've used the "thread apply
> XXX backtrace" command, which produces backtrace without switching current
> thread.
>
> Below is proposed log message. Opinions?
>
> - Volodya
>
> Log message:
> Do not immediately switch frames and hide framestack widget, when
> opening an item corresponding to a frame. Switch frame only when frame
> item is explicitly selected.
>
> See
> http://barney.cs.uni-potsdam.de/mailman/private/kdevelop-devel/2005-May/033
>098.html for rationale.
>
> * gdbcontroller.h
>   gdbcontroller.cpp:
>   (GDBController::slotProduceBacktrace): New slot. Gets backtrace for
>   a thread via "thread apply XXX backtrace" and so doesn't change current
>   thread.
>
> * framestackwidget.h
>   framestackwidget.cpp:
>   (FramestackWidget::produceBacktrace): New signal.
>   (FramestackWidget::getBacktrace): New method.
>   (ThreadStackItem::setOpen): Only fetch backtrace when there are no
>   children. Otherwise, when viewedThread_->setOpen(true) is called
>   after parsing backtrace we immediately emit another signal.