octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging and the GUI Editor; Qt help needed


From: Torsten
Subject: Re: Debugging and the GUI Editor; Qt help needed
Date: Thu, 28 Mar 2013 15:55:33 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4

On 28.03.2013 15:44, John W. Eaton wrote:
> On 03/28/2013 07:44 AM, Torsten wrote:
>> On 28.03.2013 08:43, John W. Eaton wrote:
> 
>>> The cursor is often displayed at the bottom of the window.  It might be
>>> nice to automatically recenter.  Does someone know how to do that with
>>> QScintilla?  I looked, but couldn't see how to do it easily.
>>
>> Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/f3c93e387865
>> should fix this.
> 
> Thanks.  Should we also scroll the window to keep the position marker
> (the yellow arrow) near the center?

After the debugger has stopped, the yellow arrow points to the line with
the cursor which is in the center. Or do I get you wrong?

>> If the command and editor widgets are tabbed or if the editor widget is
>> floating and overlapping with the main window it is not possible to have
>> both visible. Should the command widget keep the focus when the
>> breakpoint was set from the command line?
>>
>> What should be done if the debugger stops at a breakpoint? I suggest to
>> bring the editor on top.
> 
> If both editor and command window are tabbed, is it possible to split
> the area where the editor and command window tabs appear so that one is
> above the other?  If either is detached, then I think it is fine to
> leave them alone as presumably the user has arranged them in some way.

Showing command ans editor window side by side is possible but should we
really destroy the users window layout during debugging?

>> The directory in octave has to be set to the one of the script opened in
>> the editor if the breakpoints are set in the editor. Maybe this can be
>> done by just setting the directory before calling dpstop.
> 
> I think this problem is not limited to the GUI.  The debugger is
> currently limited to setting breakpoints using only a function name. The
> file found then depends in some way on the symbol table.  It should
> probably be possible to set a breakpoint in a file directly.

What I do not understand is that the directory of the function is
correctly set before setting the breakpoint but obviously without having
any effect. Changing the directory manually and then setting the
breakpoint works fine.

Torsten



reply via email to

[Prev in Thread] Current Thread [Next in Thread]