RFC: Obsolete TUI _before_ 5.1?

RFC: Obsolete TUI _before_ 5.1?

[Andrew Cagney]

Hello,

Up until now I've been of the opinion that the TUI should be left alone 
until after 5.1.  Given that I've dragged my feet on 5.1, I'm thinking 
that the question should be re-considered.

The person I'm really interested in hearing an opinion from is Stephane 
since he played with the TUI a little and got it to build.  Stephane, do 
you think that the TUI is salvageable or that a re-implementation would 
be better.

One thing to keep in mind is that we're (I'm?) trying to reduce the 
number of interfaces into GDB core with ui-out/ui-file and ``libgdb'' 
becomming the only interfaces.  For the TUI to survive it would need a 
major rewrite anyway.

	Andrew

Re: RFC: Obsolete TUI _before_ 5.1?

[Stephane Carrez]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]

Hi Andrew,

Andrew Cagney a écrit :
> 
> Hello,
> 
> Up until now I've been of the opinion that the TUI should be left alone
> until after 5.1.  Given that I've dragged my feet on 5.1, I'm thinking
> that the question should be re-considered.
> 
> The person I'm really interested in hearing an opinion from is Stephane
> since he played with the TUI a little and got it to build.  Stephane, do
> you think that the TUI is salvageable or that a re-implementation would
> be better.
> 

The point I reached is not perfect but I can build and use the gdb-tui
for i386 and m6811.

  - I removed all readline/termcap hacks;
  - I cleaned up various hacks in gdb and started to use
    several hooks used by insight;
  - I introduced a specific readline keymap for tui-mode and
    the ability to switch between the normal keymap (command line)
    and tui (a kind of short-cut, or, single key command)

There are several issues:

  - There are few TUI hacks inside GDB that I've not yet solved.
    For some of them, some kind of callback like `create_breakpoint_hook'
    would be nice to have.  So, I guess they are fixable in a clean way.

  - For a robust curses management, it is necessary to know (within tui)
    when gdb switches to the terminal inferior or to the gdb terminal.
    Typically, what would be necessary is to catch some of the 
    target `to_terminal_*' (without overriding them).

  - Readline is not clean in its management of output.  The way HP solved
    this is really terminal dependent, by defining a locked scroll region
    on the terminal.  This does not work very well and readline output
    interact badly with curses (which is not aware of that).  I solve this
    by in a Unix way.  I created a pipe that is read by tui code and that
    serves as output for readline.  It is clean as far as gdb/readline are
    concerned.  But this is really Unix oriented.


I think it's a little bit too early (for me) to declare TUI obsolete.  
I suggest I spend some more time on it to see if I can do something 
useful and acceptable for it (let's say before mid or end July).

When do you plan to do a 5.1 release?

Could you state a date when no new feature should be integrated?


> One thing to keep in mind is that we're (I'm?) trying to reduce the
> number of interfaces into GDB core with ui-out/ui-file and ``libgdb''
> becomming the only interfaces.  For the TUI to survive it would need a
> major rewrite anyway.
> 
>         Andrew

Yes. Clean GDB API is important.

	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France

Re: RFC: Obsolete TUI _before_ 5.1?

[Andrew Cagney]

> I think it's a little bit too early (for me) to declare TUI obsolete.  
> I suggest I spend some more time on it to see if I can do something 
> useful and acceptable for it (let's say before mid or end July).
> 
> When do you plan to do a 5.1 release?


``soon''.


> Could you state a date when no new feature should be integrated?


FWIW, I largely don't believe in feature freezes.

Instead I believe that since people are trying to keep GDB stable (while 
still allowing change) a branch can be made, well in theory, at any 
time.  When it comes down to it, GDB is a user interface, and user 
interfaces are best implemented iterativly.

enjoy,
	Andrew

PS: I'd just like to take this oportunity to deny all rumors that the ``bunyip'' is a figment of

the Australian imagination (It is real, I've been attacked by one and 
can show the scars .... ;-) and that Toronto has an air polution problem 
(cough, splutter, ...) :-)