Future Features Of Tuba
Note: I haven't been keeping this list up to date. For instance,
the version numbers here are all wrong. Most of the GUI related issues
will be dealt with in the GUI rewrite of version 3.x. The rest will trickle
in.
Below is a list of potentially upcoming features of Tuba and when they
might be rolled out. Many of these features are basically randomly scattered
around to ensure timely releases. If you have any other ideas for improving
Tuba, please send them to me (iliad@doitnow.com).
Also, if you see a feature that's low on the list but you just gotta have
it, drop me a line and I'll try to move it up.
version 2.4
-
Improve the library building process, perhaps using the information found
in tclConfig.sh (installed by the Tcl distribution).
-
Allow entering a proc breakpoint manually (for procs that aren't defined
yet)
version 2.4 (continued)
-
Speed up the Tcl and C++ parsers by rethinking the parsing algorithm. Currently,
code in nested blocks are parsed multiple times, as many times as the nesting
level. This makes for an easier parser, but more inefficient.
-
Incorporate the Java parser (for use with TclBlend) that was sent to me
by Moses DeJong <dejong@cs.umn.edu> into Tuba and make it an optional
parser to use
-
Put parser type (C, Java, or Tcl) in the options menu.
-
Implement online help.
-
Don't instrument "variable" commands if there is not value assigned
-
Support for proc templates. I define a proc template as anything that looks
like this:
proc $name {} $code
At load time Tuba can't put instrumentation in the proc body, so it
defers instrumentation when the proc is defined at runtime. The code in
$code is properly instrumented, but the line numbers don't match
up with the source code in the file that is displayed in the source window.
Support for this will probably involve an embedded window in the source
code window that shows the runtime-expanded proc definition so the user
can step through it.
-
Document dynamic procs in the Users Guide
version 2.5
-
User configurations. Almost all aspects of the GUI will be customizable
by the user. This includes window geometries, colors, fonts, etc. Provide
a couple of canned configurations (styles). For instance, I like the style
of Tix.
-
Fully support keyboard accelerators (configurable, of course).
-
Add a "View All" menu option under the "View" menu bar button. This will
bring up all the windows: variable window, stack window, procs window,
and breakpoints windows.
-
Support temporary breakpoints. When the temporary breakpoint is reached,
it is removed.
-
New command line options:
-
an option to not read in the preferences file.
-
an option to read in a different preferences file than the default (~/.tubarc).
-
Make the "View" command (the magnifying glass icon) a little smarter: if
there is nothing selected, ask the user for a variable.
-
Try to be smart about figuring out what interpreter an application needs
by parsing the information at the begining of the app. I know of three
ways people automate the startup of their script applications (anyone know
of others?):
-
#!/some_path_goes_here/wish8.0
-
#!/bin/env wish8.0 (my personal favorite)
-
# The next line restarts with wish \
exec wish8.0 "$0" "$@"
-
Parser support for some Tk commands: after, bind, ...
version 2.6
-
Be able to expand an array into its elements in the var list and just monitor
a specific element. Tix widget?
-
Display the proc list in a hierarchical fashion, where procs in a namespace
can be seen at lower levels. Another Tix widget?
-
A command window. In this window you can type in a command to be executed
by the application being debugged. You can select the level you want to
execute it in: global, current proc, or any level up. This will be handy
for more in-depth poking around your application.
version 2.7
-
More editor-like features in the source code window:
-
search
-
goto line
-
allow editing of code?
-
line numbers
-
Be able to set proc break points and goto code from the stack window