At 03:30 PM 1/10/00 +0100, you wrote:
>Here my reply:
>
>1) Multiple dedicated windows:
>
> I began working with computers in the early time of VT100 and still
> like the keyboards of these terminals, but however, X11 and the
possibility
> to have multiple windows is definitely a plus.....
> So, I am speaking about a ui assuming a windowed display system, and
> not at all adapted to an alphanumeric terminal.
>
> I have been influenced by debuggers I got to use for c/c++ dev. where I
> always have 2 or 3 running at the same time (to develop network client/
> server apps.).
> --> one main window (well, frame in elisp speaking) per debugger and
> some other windows with info in (the most important beeing the
> stdout/sterr (what I call the execution view) window, that I an
> accustomed to see for every running program, even when I don't
> interract with it (i.e. the main window is iconified and doesn't
> consume screen space)
> (I plan also to reduce the size of the other windows by a better
choice
> of fonts)
>
You can do this right now with the JDE. For example, suppose that you want
to have the Process CLI in a separate window. Simply select the CLI buffer
and do
Files->Make New Frame (C-x 5 2).
I've given a lot of thought to this issue since our last exchange. I've
concluded that there is no need for the JDE to try to impose some complex
window management scheme on the user. This is because Emacs already has
commands that easily let you set up your windows in any way you want. So my
plan is to continue with a three-pane window where the top pane is the
source, the bottom pane shows debugger session messages, and the middle
pane is multipurpose:
Source Pane
-------------------
Multipurpose Pane
-------------------
Messages Pane
When you launch a process, the debugger will display the Local Variables
buffer in the Multipurpose pane. This buffer displays the values of local
variables at the current breakpoint or step point. It is automatically
updated as the program hits breakpoints or stepped.
The JDEbug menu will include a Show Buffer submenu that will allow you to
display any of the target process's buffers in the Multipurpose Pane. If
you want to have a buffer displayed in a separate window (i.e, frame0, you
can first display it in the Multipurpose Pane and then use Make New Frame
to put it into a separate window.
I believe this design is easy to understand and combines simplicity with
flexibility.
> --> several instances of debugger running at the same time, with an
> easy way to interact with all their components (maybe we could
> use different background colors for each one ?), view/hide component
> windows with commands (menubar and keyboard)
>
With JDEbug, you can use a single instance of the debugger to debug as many
processes as you want, running anywhere on the network. There is no need to
run multiple sessions of the debugger. JDEbug has a Set Target Process
command that allows you to specify which of the processes are currently
targeted by debugger commands. Thus, to set a breakpoint in Process 2, you
would make Process 2 the target process and then issue a Set Breakpoint
command.
Of course, there is nothing to prevent you from running multiple sessions
of the debugger if you want. To do this, you would need to run multiple
Emacs sessions, since you can have only one debugger sesssion per Emacs
session.
>2) Read-only source window:
>
> Often, I feel the need to edit the source during debugging (correct minor
> bugs, or just put some hints/comments at the right locations), but without
> disturbing the debugger (related this this: in the debugger,it would be
> fine to have a way to modify a variable ant to jump to a give location
> in order to pursue debugging; I don't know if JPDA allows this; this is
> possible in all good C/C++ debuggers)
>
You can use the Evaluate Expression command to set the value of any variable
that is currently in scope (I believe the same restriction applies to C/C++
debuggers), e.g., you can evaluate, "x = 5", to set the value of x to 5. Then
set a breakpoint where you want to continue execution.
>3) The threads buffer
>
> Today, you display a tree of threads with info about the state of each
> thread. But each thread has also an other piece of info wich is it's
> method activation stack (of call stack, or just the stack), and a
> representation of this stack is a good thing for debugging, for:
> - information: where is a given thread ? (in a blocking function ?,
> in a method with a loop ?, aso.)
> - for debugging actions: use the stacks to easely reach the source
> in order to have a look at it, display
variables
> and to set/remove breakpoints for example.
>
My plan is to provide some of this functionality with Up Stack and Down
Stack commands.
These commands will move up and down the call stack in which the target
process is currently suspended. When you move up, the text cursor will move
to show the corresponding source line and the Locals buffer will be updated
to show the local variables for the current frame.
I will consider providing some UI for arbitrarily navigating the stack
through a tree representation of the process's threads.
>My intention is not to make you switch from your point of view to mine
>(excuse my "raw english", I'm a french guy without a good english background)
>(for ex. about the mono/multi frame), but to see with you how the today's
code
>could be restructered to allow several ui implementations. I thought already
>about the fact that there might be a way to define an interface of my
>multi-frame debugger ui that would allow it to be used for every GUD
supported
>language (yes, I would like to use it also for C++ and perl on Linux).
>
JDEbug has two parts: a front-end GUI written in elisp and a backend
debugger, called jdebug, written in Java. The backend debugger was
deliberately designed to be independent of any GUI design.
You are free to write your own elisp GUI front-end to jdebug. I would be
happy to post it on the JDE web site on the Contributed Software page.
As for me rewriting the JDE GUI front-end to make it more useable for you,
I don't have the time or the inclination. It is arduous enough trying to
meet the goal of providing a complete GUI front-end to jdebug without
having to meet simultaneously the goal of designing and implementing an
elisp abstraction layer that other developers could reuse to implement
other, possibly radically different GUIs.
Thanks for your suggestions and comments.
Regards,
- Paul
