# $Id: TODO,v 1.144 1997/05/27 14:39:21 zeller Exp $ -*- Text -*-
# The DDD projects.

This is a list of frequently suggested DDD features, which should be
realized in some future DDD release.  If you want to realize one or
more of these projects, please ask us (ddd@ips.cs.tu-bs.de) whether
there are already people working on that project.  Similar, if you
have a project idea, be sure to send it to us such that we may realize
it (or include it in this list :-)

Projects marked with an `*' represent work in progress.
Volunteers for these and other projects are welcome!

001. Have DDD ported to a free widget set -- Athena or lwlib, for
     example.  DDD could then be included in the GNU distribution.
     [Discarded; wait for LessTif people to finish.  -AZ]

003. Support full annotation mode (`gdb --annotate=2').  This would
     make prompt recognition easier and allow full trace of the current
     GDB status.  Disadvantage: won't work with earlier GDBs and requires
     a major redesign.
     [Discarded; won't work with DBX and XDB.  -AZ]

004. Have interactive help -- a wrapper to the GDB `help' command.

006. With GDB 4.14 and later, define `graph display' command such that
     a special code is issued which causes DDD to show the display.
     Thus, one could use `graph display' in own definitions.
     See also 067, below.

008. Have buttons arranged such that they do not disappear when the
     window is narrowed.

017. Have the graph editor scroll automatically when the pointer drags
     something out of the visible part of the window.

021. In the manual index, use special fonts for bold keywords.
     [Requires Motif 2.0 and CMText.]

025. Have auto-unfolding for recursive data structures.  Dereferencing
     a pointer P * would automatically select all P * members in the
     referenced structure.

026. Have optional abstraction levels, hiding implementation details.
     Every data type would be assigned an individual VSL function
     determining its representation.

031. Have a three-dimensional data display (using red/green glasses) :-)

033. Call for bug report if `make' fails.  But how?

     J.H.M. Dassen <jdassen@wi.leidenuniv.nl> suggests using two
     makefiles: Makefile.real (which does all the hard work, and
     touches a file "buildcompleted" [1]; if 1. is implemented,
     "buildcompleted" means that the build is indeed completed) and
     Makefile (a wrapper that executes Makefile.real, and that
     displays the error message if "buildcompleted" doesn't exist
     after executing Makefile.real).  Alternatively, you can merge
     these into one makefile.

     [1] Of course, as long as DDD produces only one executable, you could
     ddd/ddd instead.

034. Call for bug report if a fatal X error occurs.

037. Group dereference.  If multiple pointers are selected,
     dereference them all.

049. albrecht@igpm.rwth-aachen.de (Harald Albrecht):
     The dialog windows (especially the backtrace dialog) should not
     exceed a specific size (at least, they should not be larger than
     the screen :-).  Also, the DDD dialogs should be iconified on
     their own, without always laying on top of the main windows.

050. Include algorithm animation; for instance, in a way similar to
     LENS (see ftp.cc.gatech.edu:pub/people/stasko).  Suggested by
     bruce@liverpool.ac.uk (Bruce Stephens).

060. When using a dynamic version of libstdc++, configure fails
     to add its location to the -R flag.

067. Andy Gill (andy@dcs.gla.ac.uk) wants more options to
     `graph display': ``for example,

        graph display[x=100,y=100,rotate] foo

     where foo is an array. This means put the object at location
     (x=100,y=100), and rotate the array.  Using this in conjunction
     with with the TODO 006 means that when restarting a program that
     you are debugging you could have a script of what vars you are
     looking at, and where you want them to go on your
     canvas. Furthermore, there could be an option on the graph window
     that let you dump such scripts automatically generated from the
     current layout on the canvas.''
     [See also 076 -AZ]

069. Yves Arrouye <Yves.Arrouye@marin.fdn.fr> states:

     3. Add a way to cast a display. What I mean is that when I debug some
        code with a `generic' C function which takes a void* and a tag that
        indicates the kind of stuff the void* is really, I'd like to be able
        to cast the displayed void* (maybe by editing the text
        field---dangerous---or simply by having a 'Cast' item in the popup
        menu). The fastest way to do that actually is to select `Dependent
        display', type the cast there, and then delete the original display
        (because what we want is in the casted display).

     4. Let one colorize the displays. By using regexps on types or
        names of the fields, it would already be extremely useful (or
        with a match on the typed expression, having a list of regexps
        to match, the first match giving color, so that given blue for
        ` pr_.*' and red for `^int .*' one would see `int pr_var' in
        blue but all other int variables in red). Does VSL support
        colors ?

070. Matthias Kurz <mk@baerlap.north.de> suggests an option to set
     debuggee arguments when invoking DDD.  A simple way of
     implementing that would be: if more than one argument is given,
     or if the 1st argument is neither a core file nor a process ID,
     use the remaining arguments as debugee execution arguments.  [In
     DDD, this is difficult to implement while conserving remote mode.
     This should be an extension to GDB, not to DDD.  - AZ]

071. Matthias Kurz <mk@baerlap.north.de> suggests code annotations
     (i.e. comments and graphics that are associated with certain
     variable/function names in the code).

075. Andre Cormeau <ac@enci.ucalgary.ca> says:

     Apparently ddd does not fully support fortran. A problem is in
     variable names, with capital letters and underscores (not strict
     f77).  I need to change the variable names to small caps and add
     underscores to the end of the names, which is a bit annoying
     after a while.  Is there a filter to do this out there?
     [This is a problem in the underlying debugger.  -AZ]

076. Henrik Seidel <henrik@satchmo.physik.tu-berlin.de> says:

     I am missing a feature which would be very useful (but, maybe,
     difficult to implement). Maybe it is already there and I just
     don't see it: I would love to be able to save the layout and the
     variables of the graphic display, so that I can use the same
     layout if I continue debugging the program tomorrow. More
     important, I do not like it so much that I have to re-establish
     the graphic display each time I recompile. Currently, after
     recompiling all variables displayed in the previous version of
     the program are now undefined, probably because addresses have
     changed. Is there a trick to make them be defined again? If not,
     it might be a good idea to save the displayed variables not by
     their address but, more source-code oriented, by their scope and
     name. That way, it shouldn't be too difficult to save the
     displayed variables and find the corresponding variables even
     after recompiling.
     [See also 067 -AZ]

078. Have mirror sites for the DDD WWW page.  Maybe via the DDD FTP
     mirrors?

080* Include the FAQ in the DDD manual.  Better yet, include all
     top-level documentation in the DDD manual (including news,
     problems, etc.) and generate it from this single source.

083. Include graphplace (or other graph layout) support.

085. Include xDuel support.  See `http://www.math.tau.ac.il/~frangy/'
     for details.

088* Some suggestions by Oyvind Yrke <oyvind@stavanger.geoquest.slb.com>:

     o When setting a breakpoint, it should be possible to select from
       a list matching a regexp.  This feature would be particularly
       useful when working with c++ code with overloading, templates
       and member functions.

     o In data display, it would be extremely useful to select which
       fields of a (big) struct should be displayed.  In the current
       version, you have to display the whole struct, or display
       individual elements in separate boxes which wastes space.

     o Ability to group variables as selections that can be
       enabled/disabled separately.  For big applications, the data
       display quickly gets overcrowded.  Disabling data display of
       these variables will not save much screen space.  So if I can
       select some of the variable boxes in the data display, and save
       them for later retrieval would be use very useful.

     o Display of variables are disabled when stepping into a new
       function, i.e. variables in functions "above" the current frame
       are not displayed.  Although I can circumvent this problem by
       typing the full path (e.g.  graph display
       /some/deeply/nested/directory/file.c:a, this is quite
       inconvenient.  The function/file prefix should probably be
       omitted (at least as an option), since otherwise the data
       display would be messed up with very long variable names as in
       SunOS dbxtool/debugger.  Displaying an element of an array in
       dbxtool as you iterate through the array looks like

         '/a_very/long/path/'funcname'data['/a_very/long/path'funcname'i] = 17

       Some sort of user customization is probably needed here to
       avoid lengthy names (e.g. by specifying how many directories
       should be displayed).  An alternative is to have a status line
       in the data window too specifying the full path of the data box
       where the cursor is pointing.
        
     o Since you supply ddd binaries, why not supply gdb binaries as
       well?

094. Have a VSL 'string()' function that extracts the string from a
     box.  With an additional VSL 'matches()' function that matches
     regexps, one may display different types in different
     colors, fonts, etc.

095. Have a colored DDD icon (requires Xpm).

099. Add a history mechanism to the `()' fields (cursor up / cursor
     down).

102. Have a WWW tutorial for DDD.  Any volunteers?

108. David M. Karr <dkarr@nmo.gtegsc.com> suggests:
     In the SparcWorks debugger, if I use the "list" command at the
     internal dbx prompt, it lists the object or lines I specify in the
     source window.  I believe that "ddd" should work this way.  Is there a
     way to get this behavior, or is it simply not designed for this?

110. N. Dan Zou <zou@hooked.net> suggests a way to display the class
     structure of an existing program graphically.  [Should be
     implemented as follows: use the `ptype' output to display types
     graphically; dereference type names as required.  -AZ]

115. Have a link from help texts to appropriate sections of the DDD manual.

117. Paul Courbis <plc@lexem.fr> says: upon dereferencing a pointer, 
     it would be nice to have a menu to say: display hex data for 255
     bytes.

118. In the source view and the data display, forward all keyboard
     events except position changes to the debugger console.

119. Try whether the `-fno-implement-inlines' option in DDD reduces
     executable size.

120. Check whether `dbxenv output_short_file_name off' helps in
     debugging DBX code.

122. Have a window that shows DDD/GDB communication, with the ability
     to modify commands before they are processed.

126. `shorten' may need some improvements (count `(' and `)'
     occurrences, etc.)

127. Include `jdb' (Java debugger) support.  For details, see
     `http://www.javasoft.com/products/JDK/tools/solaris/jdb.html'.

128. Have a way to completely remove selected struct members from the
     view.  Suggested by marjeta@mccabe.com (Marjeta Cedilnik).
     [Could this done by pressing `delete' on them?  And should other
      displayed items be affected, too?  -AZ]

129. Detect self-modifying code.

130. Have a `bookmarks' menu like the `Highlight' menu in tkman.

131. Include the Athena Panner widget in the DDD distribution, such
     that Athena/Motif conflicts are removed.

132. Include NEWS, INSTALL, COPYING and the FAQ in the DDD Manual,
     and have the DDD `Help' menu items invoke the appropriate
     sections.

135. Have node reference points be at the upper left instead of the
     center.

143. Have a list of regexes that suppress or hide displays when
     matched.  See also #128 and #088.

144. When moving the source window, move the command tool, too.

151. When `Disable/Enable' is applied to a display part, make it act like
     `Show/Hide'; `Show/Hide' would no more be required.  Likewise,
     apply `Delete' to display parts only.  See also 143, 128, and
     088.

152. When dereferencing, make new displays inherit the show/hide,
     enable/disable state of their ancestors.  How about selection
     state?

153. Include assembler support for Sun DBX (they have a `dis'
     command).

154. Allow users to specify geometries for dialog windows.

155. Allow users to specify start-up commands that open specific
     windows (for instance, open-backtrace(X, Y) would open the
     backtrace window at X, Y; open-backtrace() would open it in some
     default position).  See also #154, above.

160. Support DEC `decladebug'.  Jens Albrecht
     <Jens.Albrecht@informatik.uni-erlangen.de> has a trace.

161. Daniel Lyddy <sprocket27@earthlink.net> suggests: Would it be
     feasible to allow the user to select multiple commands in the
     "Command History" window?  One could hold down the "Shift" key
     while selecting a contiguous block of commands and the "Control"
     key to select non-contiguous commands, a la Windoze File Manager.

163. Install `sample.dddinit' and `ddd.man' on the FTP server.

164. Matthias Kurz <mk@baerlap.north.de> suggests:
     - Recognize 'complete' variables; example "ptr->struct.field": if
       one points inside this string always show the value of
       ptr->struct.field.
     [ A selection followed by a click on `Print ()' will do. - AZ]
     - Selection: Double click to select words - moving the mouse then
       expands on the basis of words
     - possibility to select the base (dec, hex, oct ...) for
       displayed values; Attach this as attributes to variables,
       fields of structs/unions; load/save
     - detecting when graph display takes too long (n seconds
       configurable) if it takes too long switch in mode where updates
       are only done on request
     - Dump inspector hex[+/]ascii/octal dump of length n starting at
       address a. Possibility to 'group' data : selecting bytes in
       dump with mouse; declare them to be a particular data type
       (2/4/8 Byte integer/unsigned, float, real, pointer; select
       numeric base and byte order); load and store such definitions;
       apply such definition starting at a specified point.
       Possibility to 'graph display', modify and write back values
       from the dump.
     - recognize URLs in source window; follow on click (call external
       browser)

164. It would be very nice if the data displayed in the Display window was
     color highlighted whenever it changes.

165. Have an optional mode where line numbers are shown in the status line.
     The source layout may be changed such that line numbers are shown
     no more.

166. When the inferior debugger crashes, offer to restart it.  This
     may be done by replaying all previously issued commands (except
     the last one, of course).  Commands with external side-effects
     (such as running or making the program as well as shell commands)
     should be ignored.

167. The `Show/Hide' operation could revert to `Enable/Disable' if the
     entire display is selected.  The `Enable' button would no more be
     needed.

168. Rename `Lookup' to `List' and recognize the `list' command.  See
     also #108.

169. When a program has crashed, show the program counters as little
     bombs ;-)

170. (Insert your project idea here)
