| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2741.1 | | GUESS::DERAMO | Dan D'Eramo | Thu May 10 1990 00:02 | 17 |
| The window that had the input focus before you paused
the session still had the input focus after you unpaused
the session. However, its title bar was not highlighted
and its text entry cursor may have been dimmed.
I was just entering a reply saying the above in a
DECwindows Notes Notes:Edit window that still had the
"invisible input focus" after unpausing. But it behaved
strangely--hitting TAB moved the focus to the "Author:"
or "Date:" field and highlighted the title bar.
Then the node DECwindows Notes was running on crashed,
and I lost all of my windows to that cluster (even from a
node that didn't crash), but surely that was a
coincidence unrelated to the input focus problem. :-)
Dan
|
| 2741.2 | more... | CSC32::FORSMAN | Ginny Forsman 522-4731 CSC/CS | Thu May 10 1990 16:26 | 2 |
| I also find that this window with 'invisible input focus' only has
this input focus while the pointer is positioned within that window.
|
| 2741.3 | The true behavior... | CSC32::M_MURRAY | | Fri May 11 1990 18:26 | 19 |
|
.1 is incorrect. The last window to have focus before the pause does
not have focus on return from a pause.
Upon return from a pause, no title bar is highlighted to indicate
that a window has focus, but input focus will be found in the window
which has the mouse "cursor" (arrow) positioned over it.
Focus can be moved from window to window without a title bar being
highlighted, by moving the mouse.
If mb1 is clicked while the cursor is over a window, the title bar is
highlighted, focus is assigned to that window and "normal" behavior is
restored.
A QAR #719 in the v54-FT database, on this issue, has a response
as to future behavior.
-Mike
|
| 2741.4 | | GUESS::DERAMO | Dan D'Eramo | Sat May 12 1990 17:38 | 13 |
| re .1, .2, .3
Aha! A model that explains all of the observations! :-)
I almost always place the mouse in the window in which
I am working, as if the input focus were pointer driven.
So I only noticed what I posted in .1. The more complete
explanation in .3 makes me curious ... is our window
manager actively making focus follow the pointer then,
or does the server do that as a kind of default when the
window manager "abstains" or is stopped?
Dan
|
| 2741.5 | X default ? | ISIDRO::JOSE | | Mon May 14 1990 08:47 | 7 |
|
if you use uwm (window manager provided with X11), the
input focus is in the window that contains the cursor, unless you
specify a window to have it.
maybe that's related with what appened here...
|
| 2741.6 | No real estate driven focus | STAR::CYPRYCH | | Thu May 17 1990 13:05 | 7 |
| RE: .4
In answer to your question, no, the window manager in
DECwindows V2 does not support "real estate" or "pointer"
focus.
Nancy
|
| 2741.7 | | GUESS::DERAMO | Dan D'Eramo | Thu May 17 1990 23:01 | 9 |
| re .6,
Okay, it must be the server causing that behavior, as
sort of a default when the window manager isn't working.
I'll try to remember to test that next time I am about
to quit a session, by killing the window manager first
and seeing if the input focus then follows the mouse.
Dan
|
| 2741.8 | | CSCOA3::HOOD_DO | | Tue May 22 1990 18:42 | 10 |
|
Coincidentally, I have observed a similar problem in Ultrix DECwindows.
When an application exits from inside of a callback procedure ( exit(1)
inside of a caution box 'yes' callback procedure), the program exits,
and the window to get input focus is (you guessed it) the window in
which the cursor is located. None of the windows are highlighted.
Sounds like the server/window manager dropped the ball.
Doug
|