Re: <Ctrl-C> in the Console Window

[Fernando Nasser <fnasser@cygnus.com>]

Keith Seitz wrote:
> 
> Fernando Nasser wrote:
> >
> > John wrote:
> > >
> > > What is the copy key under windows going to be?
> > >
> >
> > That is a good point, but I would be surprised if it ever worked
> > on the console window on NT anyway.
> >
> > What would be more important: simulate the real gdb console and accept
> > <Ctrl-C> as interrupt or allow cut-and-paste with the Windows standard keys?
> >
> > We can also add cut-and-paste based on selection and a right click menu
> > with Copy/Paste on it (I would not have Cut).
> >
> > Well, it is open to debate.
> 
> Ugh. I don't think that we should override the default behavior of the
> window manager like this... Something about using "^C" to mean "stop"
> instead of the usual "copy" makes me nervous. Originally, I intended to
> use the escape key in Insight as a generic "stop whatever you're doing".
> I've already snuck it in at a few places. For example, if you
> double-click a variable for editing in the var windows, hitting escape
> will cancel the edit. I believe we have the same thing in the Memory and
> Register windows.
> 
> This is a can of worms, really. I think that no matter what happens,
> someone is going to dislike the decision. Since I'm the appeasing type
> (stop laughing, JimI!), I would probably default ^C to "cut" and add a
> preference for making it "stop" (in the console window). This is even
> uglier, though, 'cause I think that we use ^C in the source window to
> mean "copy". If we change it to "stop", we would have the same key bound
> to two completely different functions.
> 

Yes, you are right.  And someone out there, for some reason may be using this
as copy (I checked and it works both on Linux and on NT).


> Yich. I'm dizzy. Perhaps we've learned just one thing from this:
> whatever you decide to do, make sure that it is consistent.
> 

I think I will withdraw this suggestion.  At least now I have some support to dismiss
these requests for doing <Ctrl-C> in the simulated console.

Maybe I should look for a way to better educate users instead.  For instance,
if the preferences file is not yet present in the users home directory, we can
add a popup offering to display a "primer".  In this primer we would explain
that you are not supposed to do things like "target remote blah" in the console
window and that one must use the STOP button, not <Ctrl-C>.

I find this really funny.  These people seem to want to type commands but, instead of
starting gdb in command line mode they try to use the GUI Console Window.
There are too many of these people to be just a coincidence.

My guess is that the GUI widgets for displaying registers, memory, source code
etc are so nice that even hard-core command line users want to see them.
But they want to type commands.  Well, they have to if they are using hardware
breakpoints for instance (I hope to fix this one but there may be other things
like a few target specific set commands that will always be necessary).

What about adding a command line entry widget to the bottom ot the source window?
People could type commands there without even open the console and the STOP
button will be close...

We also have to detect and prohibit things like "target" commands (I don't like
closing doors though) or at least issue a warning if the user tries it, both
at the console and at the entry widget if we add one.  A better solution is to
add the appropriate notification hooks to gdb.  We can do the former as a temporary
remedy while we implement the latter.







-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9