Bug 68015

Summary: Variables/Watch Window closes on first view in IDEA1 mode
Product: [Applications] kdevelop Reporter: Robert Shideleff <bigbob>
Component: CPP DebuggerAssignee: KDevelop Developers <kdevelop-devel>
Status: RESOLVED FIXED    
Severity: normal CC: steven_risner
Priority: NOR    
Version: 3.0.0b1   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Robert Shideleff 2003-11-12 17:27:21 UTC
Version:           3.0.0b1 (using KDE 3.1.4)
Installed from:    Gentoo
Compiler:          gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice)
OS:          Linux (i686) release 2.4.22-ac4

When debugging, the first time I open the Variable/Watch Window in a C++ file, in order to view the local variables, I must click open the current frame of local varaiables. This appears in the window as '#0 fooClass::foobar(...)' with a little + tree thingy to click it open.

The first time I click this open, the IDEA1 window closes. The GDB windows shows several command lines to load and identify the variables. If I re-open the IDEA1 window, then the current frame is open for viewing, and I can then proceed normally with viewing the variables.
Comment 1 Jens Dagerbo 2003-11-12 17:56:15 UTC
This is argued to be a feature, not a bug. :)

The idea is that in IDEAl mode (both the beta1 version, and the new one currently in CVS) you need to "stick" docked views with either the small "dot" (beta1) or the small square (CVS) in order for them to stay open after you've clicked them.

The feature is meant as a way to have as much room as possible for the code area all the time. This works well with some docked plugins, and less so with others. In the debugger case, it appears to be "less so".

I'm closing this report. Please reopen if you disagree or I've misunderstood your report.
Comment 2 Robert Shideleff 2003-11-12 19:29:24 UTC
Perhaps I didn't explain this properly. I clicked on something (the little plus sign) within the IDEA1 window that was supposed to reveal more information WITHIN THE SAME IDEA1 WINDOW, but instead the window closed, hiding everything. When I re-open the window, the information appears with the info tree opened up and more + signs revealed. Now when I click on these, the window stays open (as it should) and simply reveals the next branch on the tree.
Comment 3 Jens Dagerbo 2003-11-12 19:40:37 UTC
Point taken. :)

The workaround is to lock the window open, but as you discribe it, it is definitely unwanted (and unexpected) behaviour, and a bug.
Comment 4 Jens Dagerbo 2005-01-08 03:24:15 UTC
*** Bug 96294 has been marked as a duplicate of this bug. ***
Comment 5 Jens Dagerbo 2005-01-08 03:25:49 UTC
I think putting this one on kmdi is wrong(!!), I'm pretty sure it's the debugger that confuses things.
Comment 6 Vladimir Prus 2005-06-22 15:44:45 UTC
SVN commit 427960 by vprus:

Improve variables display and frame display views.

1. 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/033098.html
for rationale.

2. Show only variables for the current frame in variables view

3. Allow to either evaluate an expression, and add it to the list of watched
   expressions.

4. Refactor communication between gdbcontroller and variableswidget to reduce
   the number of direct calls from gdbcontroller to methods of
   variableswidget.

* 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.
  (GDBController::slotProduceVariablesInfo): New slot. Gets info about
  parameters and local variables of a function. 
  (GDBController::parametersReady, GDBController::localsReady): New signals,
  emitted whenever gdb parses the corresponding reply from gdb. 
  (GDBController::currentFrame): New signal, emitted after current frame might
   have changed.  
  (GDBController::actOnProgramPause): Do not issue "info locals". Emit   
  'currentFrame'.
  (GDBController::programNoApp): Don't invoke variablewidget method. Rely
   instead on proper handling of the dbgStatus.
  (GDBController::parseBacktraceList): Don't trim frames in variables view.
   This will be done anyway on first currentFrame signal after program pause.
  (GDBController::parseLocals): Just emit parametersReady and localsReady.
 
* variablewidget.h
  variablewidget.cpp:
  (VariableWidget::slotEvaluateExpression): New slot.
  (VariableTree::setLocalViewState, setCurrentThread): Remove.
  (VariableTree::produceVariablesInfo): New signal.
  (VariableWidget::VariableWidget): Create new "Eval" button.
  (VariableTree::slotDbgStatus): New slot. Trim everything when the
   program no longer exists, and set a flag immediately after restart.
  (VariableTree::slotCurrentFrame): New slot. Hide VarFrameRoot corresponding
  to the previous frame, show the one corresponding to the selected one,
  and populate it with variables if needed.


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

BUG: 68015
GUI: 


 M  +15 -0     debuggerpart.cpp  
 M  +20 -2     framestackwidget.cpp  
 M  +3 -0      framestackwidget.h  
 M  +28 -73    gdbcontroller.cpp  
 M  +13 -1     gdbcontroller.h  
 M  +224 -58   variablewidget.cpp  
 M  +44 -5     variablewidget.h