glenn@heaven.woodside.ca.us (Glenn Reid) (12/03/90)
Just when we thought the discussion about click-to-type versus mouse focus had died down, now this, hot off the wire. The new Terminal application in 2.0 has a very mysterious entry in its Shell menu called "Steal Keys". Unfortunately Terminal has no Help in its menus, so I had to go digging to figure out what this did, but I found it, thanks to Digital Librarian. The "Steal Keys" option in Terminal makes it possible to focus the Terminal application simply by moving the mouse into its window (no click is required). It is purportedly for debugging, as in this passage from the documentation, but it is interesting in light of our discussion about this topic. I'm not sure how it's done, but it appears that Terminal simply does not become the key window, but does "steal" keydown events from the event queue somehow. The previously-active application is still highlighted and looks active. Here's the passage from the docs: The Steal Keys command is useful when you're running the GNU debugger. The purpose of this command is to allow you to effectively debug an application from a shell window in which the debugger is running. The debugging process inevitably involves alternately activating Terminal (to type debugger commands) and the other application (to test the application being debugged). However, clicking to alternatively activate and deactivate the application being debugged causes the application to change its state in unpredictable ways. To let you get around this problem, the Steal Keys command puts Terminal in a special debugging mode. In this mode, Terminal can be activated or deactivated simply by moving the cursor into or out of the Terminal shell window. Therefore, you can easily activate Terminal whenever you want to type a debugger command, without clicking and thus affecting the state of the application you're debugging. When you're ready to exit debugging mode, click in the Terminal window to make the Terminal main menu reappear, and then choose this command again (its name will have changed to Yield Keys). I'd be curious to know just how this is done, and whether or not it is considered a hack that you and I should not do in our applicatons :-) Hey, Scott, have anything to toss in about this feature? Glenn
scott@mcs-server.gac.edu (Scott Hess) (12/03/90)
In article <339@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes:
The "Steal Keys" option in Terminal makes it possible to focus the Terminal
application simply by moving the mouse into its window (no click is required).
It is purportedly for debugging, as in this passage from the documentation,
but it is interesting in light of our discussion about this topic. I'm
not sure how it's done, but it appears that Terminal simply does not become
the key window, but does "steal" keydown events from the event queue somehow.
The previously-active application is still highlighted and looks active.
Ah. Like Old Shell's debug mode. Well, I don't support that in Stuart,
because I think it's _really_ disgusting, and I'm sure I don't want to
see the code to do it. What I do when window activation and the like
will cause problems while debugging is to fill the event queue with
appropriate events (since the windowserver handles that, it can
be done even while the app has halted). Of course, that won't work in
some very _strange_ cases, but it's not been a problem for me.
Hey, Scott, have anything to toss in about this feature?
Well, I am close to releasing two Window subclasses I've created in the
course of Stuart2.0. One is labeled DocWindow, and allows the user to
specify an alternate miniwindow icon for use when the docEdited flag
is set for the window (like Edit and Stuart2.0 does). The other is
called FocusWindow. FocusWindow tracks the mouse, and when it moves into
(and stops in) a FocusWindow instance, that window becomes key and
makes its app active (if needed). While this is exceptionaly silly
to be doing at a user level, it works on a per-app basis. It also
works fine under 2.0 . . .
Well, I amend the "and I'm sure I don't want to see the code to do it"
I have above. I'd love to see the code NeXT uses, because maybe it will
help me on the way to global move-to-focus. I've asked NeXT some
questions, but they don't support my goal . . .
OK. While I'm here, I'll ask the net. I can handle all the
windowpackage code to track the mouse, find the window it's over,
and find the app who owns the window. There are two things I've been
unable to accomplish. One thing that is needed for something like this
is some sort of DPS-level timed entry, because I cannot focus until
the mouse has stayed in place for a certain length of time. Alternately,
a method of blowing away a certain number of fractional seconds (heck
microseconds are good enough), and then I could poll (which I don't
really want to do either).
The other question relates to window activation. I've tried spoofing
the app by sending a mouse click with a position in the middle of the
title bar (mouse focusing only occurs in windows with title bars).
This almost works. If the window just happens to be the key window
for the app, it seems to work. If not, I've managed to get everything
all confused . . . running gdb and watching a Window subclasses'
sendEvent: (and the App's, also) doesn't help, as it appears that
the events coming through for both are the same, yet it still doesn't
work.
So, could anyone explain how exactly to activate a specified window/
application, where the window may be any title-barred window on the
screen, and the app is the owning context of that window? thanks.
--
scott hess
scott@gac.edu
Independent NeXT Developer (Stuart)
GAC Undergrad (Horrid. Simply Horrid. I mean the work!)
<I still speak for nobody>wiml@milton.u.washington.edu (William Lewis) (12/05/90)
This is also in the 1.0 version of "Shell", and is called "Debugging"
(or something like that). I've always assumed that what it does is
make the shell window become the key window without actually
sending a deactivateApp event to the other application, but I haven't
checked. It is in fact quite useful for running gdb ...
--
wiml@milton.acs.washington.edu Seattle, Washington
(William Lewis) | 47 41' 15" N 122 42' 58" W
"These 2 cents will cost the net thousands upon thousands of
dollars to send everywhere. Are you sure you want to do this?"