RFC: <Ctrl-C> in the Console Window

RFC: <Ctrl-C> in the Console Window

[Fernando Nasser]

Some user's, instead of clicking the cute red STOP button, insist in
issuing a <Ctrl-C> in the poor simulated GDB console (the Console Window).

I have been asked so many times this same question that, despite the fact
that I would like to tell them to use "gdb -nw" if they want a real console,
I am felling compelled to add this feature.

If there is no objections, I will bind <Ctrl-C> to (something that calls)
gdbtk_stop.

Any reason why I should not do that?


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

Re: <Ctrl-C> in the Console Window

[Fernando Nasser]

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.

Fernando  


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

Re: <Ctrl-C> in the Console Window

[Duane Ellis]

fernado> What would be more important: simulate the real gdb console and accept
fernado> <Ctrl-C> as interrupt or allow cut-and-paste with the Windows standard keys?
fernado> 
fernado> We can also add cut-and-paste based on selection and a right click menu
fernado> with Copy/Paste on it (I would not have Cut).

I would prefer it to be interrupt.

However... I'm a unix guy -moving things to Windows.... I miss my unix
stuff.

If I was a PC Guy... I might feel otherwise.

I've been very busy and not following much, maybe this has been suggested:

     Is there a way of making a user option for ControlC?

     A menu, or preference, or something...  or "set" command in GDB,
     or in some initialization file?

-Duane.

Re: <Ctrl-C> in the Console Window

[Keith Seitz]

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.

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

:-)
Keith

Re: <Ctrl-C> in the Console Window

[Fernando Nasser]

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

Re: <Ctrl-C> in the Console Window

[Syd Polk]

Ctrl+Break is the usual DOS-Windows method for stopping processes.

Re: <Ctrl-C> in the Console Window

[Fernando Nasser]

Syd Polk wrote:
> 
> Ctrl+Break is the usual DOS-Windows method for stopping processes.

I guess that Syd is suggesting a system-dependent key binding, aimed
at matching the system where it runs.

The problem is that Cygwin uses <Cntl-C> (Cygwin == Unix) and NT Command Prompt
windows use <Ctrl-Break>.   We wouldn't know which one to follow, neither would
the user.

But <Ctrl-Break> is one alternative to be a interrupt sequence that makes sense.
Maybe more sense than the <Ctrl-.> that Nicholas mentioned.

Does all the keyboards have a "Break" key or is it only the PC keyboard?
I haven't used other keyboards in a while.  Is it in the Sun keyboards?   On Mac?


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

Re: <Ctrl-C> in the Console Window

[Syd Polk]

Fernando Nasser wrote:
> 
> Syd Polk wrote:
> >
> > Ctrl+Break is the usual DOS-Windows method for stopping processes.
> 
> I guess that Syd is suggesting a system-dependent key binding, aimed
> at matching the system where it runs.
> 
> The problem is that Cygwin uses <Cntl-C> (Cygwin == Unix) and NT Command Prompt
> windows use <Ctrl-Break>.   We wouldn't know which one to follow, neither would
> the user.
> 
> But <Ctrl-Break> is one alternative to be a interrupt sequence that makes sense.
> Maybe more sense than the <Ctrl-.> that Nicholas mentioned.
> 
> Does all the keyboards have a "Break" key or is it only the PC keyboard?
> I haven't used other keyboards in a while.  Is it in the Sun keyboards?   On Mac?
> 

Well, my Sun keyboard has a "Break" key, as well as my Mac keyboard.

<Ctrl-.> is a bastardization of the Macintosh <Command-.>. I don't advocate it
at all.

Native windows users will use <Ctrl-Break> anyway, and it works on Cygwin.

Re: <Ctrl-C> in the Console Window

[Michael Leibowitz]

On Fri, 10 Nov 2000, Syd Polk wrote:
> Native windows users will use <Ctrl-Break> anyway, and it works on Cygwin.

Can't this just be made architecture dependant?

Re: <Ctrl-C> in the Console Window

[Fernando Nasser]

Michael Leibowitz wrote:
> 
> On Fri, 10 Nov 2000, Syd Polk wrote:
> > Native windows users will use <Ctrl-Break> anyway, and it works on Cygwin.
> 
> Can't this just be made architecture dependant?

Yes, if I understood right, this is Syd's suggestion.

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