From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Keith Seitz Cc: insight@sources.redhat.com Subject: Re: in the Console Window Date: Fri, 10 Nov 2000 08:37:00 -0000 Message-id: <3A0C2450.8AB6D9CE@cygnus.com> References: <3A0B402E.2A5183C@cygnus.com> <01ee01c04aaf$eb7a7fe0$ad0aa8c0@hq.tensilica.com> <3A0B4A19.EC9FC4CC@cygnus.com> <3A0C1C3F.C906B805@firetalk.com> X-SW-Source: 2000-q4/msg00184.html 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 > > 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 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 . 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