gdb-3.5
[deliverable/binutils-gdb.git] / gdb / XGDB-README
1 XGDB is an attempt at a graphical interface from GDB to X windows.
2 Its source code is in xgdb.c. The decision of whether to include this
3 file is made at *link time*; compile-time conditionals for xgdb are not
4 allowed. See the Makefile.
5
6 The current version does run with X11R2 but does not completely work.
7 For one thing it encounters an apparent bug in the predefined widget
8 used to display source files. This bug (which I have reported) causes
9 parts of the source-code display to appear blank.
10
11 But XGDB has bugs also. I suspect that xgdb_display_source passes the
12 wrong line-number arguments to that widget and it may work in an
13 overcomplicated manner. Also, at a deeper level, it does not handle
14 X-events while either the inferior or a command is running. This
15 certainly means that the window won't refresh at such times. It's
16 possible that events also fail to be handled at other times, such as
17 after a button has been clicked, and if so this would account for some
18 of the failure to display the source text fully.
19
20 I think that someone who really understands the X toolkit ought to write
21 something which will handle events asynchronously.
22
23 The user interface currently implemented is not very convenient to
24 use. For example, it is necessary to move the mouse back and forth
25 often between the XGDB window and the window where XGDB's text I/O is
26 done. XGDB should arrange to receive keyboard input via the XGDB
27 window so the mouse can be left there all the time. These chars may
28 need to be echoed explicitly and stuffed into the keyboard buffer so
29 they intermix properly with those typed in the text I/O window.
30
31 Is it worth while to have several buttons that simply use the
32 selection as keyboard input with a few extra characters before and
33 after? Perhaps it would be better to have just one button (or a mouse
34 click) to use the selection as text input, since this would work in
35 any GDB command. You would first type the command yourself, then use
36 the selection as input, then type RET yourself. If this is done with
37 a mouse click, and if keyboard input is allowed through the XGDB
38 window, then all this can be done with no extra mouse motion.
39
40 There needs to be a command to find out the line number of the
41 selected line (or it should be displayed all the time); otherwise how
42 do you use the "jump" command, or go to the editor and find that line
43 easily? Alternatively there should be buttons for these two things.
44
45 Some of the buttons' meanings aren't evident. For example, how does
46 "Brk in" differ from "Brk at"? What is "print *"? I intuitively
47 expected to click on a button and then select what it should apply to,
48 and I was surprised to find that one must do it in the other order.
49 There should be a "Help" button which displays a screen which explains
50 all the features of the graphical interface, and perhaps an "Info"
51 button which runs the info program to display the on-line GDB manual.
52
53 I would suggest that someone look at other graphical debuggers
54 (including Sun's dbxtool) and consider how to change the interface to
55 be easier to use in practice.
56
57 -- RMS
This page took 0.040103 seconds and 4 git commands to generate.