| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1648.1 | Window manager hints? | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Thu Nov 02 1989 22:06 | 6 |
| I isn't there a way to tell the window manager that you are not
interested in kb focus so that it will not give it to you? (I've never
done it...just a random memory)
Burns
|
| 1648.2 | clock does it. | RIPPLE::FARLEE_KE | Insufficient Virtual...um...er... | Fri Nov 03 1989 11:54 | 10 |
|
> I isn't there a way to tell the window manager that you are not
> interested in kb focus so that it will not give it to you? (I've never
> done it...just a random memory)
I don't knoe the technique, but CLOCK does it.
You cannot give CLOCK the KB focus, but it will respond to a double-click.
Kevin
|
| 1648.3 | | LEOVAX::TREGGIARI | | Mon Nov 06 1989 07:54 | 20 |
| > How can App1 "give up" keyboard input, (and where would it go..)
> assuming App2 doesn't want it? I've gone over things like having App2
> take keyboard focus and just not do anything with keyboard input..
> I've suggested also that could create a child of App1 that he does not map
> that takes the keyboard if it loses pointer focus, but this is not very
> elegant.. I don't think they have developed App2 anyway.. just App1.
>
> Any ideas?
Keyboard input focus is always assigned somewhere, so there is no way
to give it up without having someone else take it. If you want it
to look to the user as if "no-one" has the input focus, you'll need
to have App2 (or something else) take it and ignore all keyboard input.
I'm not sure why you want to do this though. In the DECwindows
style it's quite natural for an application to keep input focus
while you "mouse" in another application.
Leo
|
| 1648.4 | | KONING::KONING | NI1D @FN42eq | Wed Nov 08 1989 10:54 | 8 |
| I frequently get into situations where no window appears to have focus --
certainly no window has its banner lit up to indicate focus. This is
with V1. It has an annoying habit of misplacing the focus as windows
come and go, particularly if I iconify/deiconify quickly.
So I don't understand the statement that focus is always assigned somewhere.
paul
|
| 1648.5 | My mistake | LEOVAX::TREGGIARI | | Wed Nov 08 1989 14:02 | 9 |
| > So I don't understand the statement that focus is always assigned somewhere.
Oops. I was wrong. I just re-read the protocol and you can call
XSetInputFocus and give it a focus window of None. It says:
"If None is specified as the focus, all keyboard events are discarded until
a new focus window is set."
Leo
|
| 1648.6 | | VMSNET::BONNE | | Fri Nov 10 1989 13:59 | 10 |
| Re: .5
Does this mean that pointer and keyboard focus will be none?
He wants the second application to take pointer and no one to have
keyboard until application 1 takes back both..
Sounds like he will still have to modify application 2 though.. (which
he doesn't have control over..)
Jim
|
| 1648.7 | | LEOVAX::TREGGIARI | | Fri Nov 10 1989 14:24 | 12 |
| > Does this mean that pointer and keyboard focus will be none?
> He wants the second application to take pointer and no one to have
> keyboard until application 1 takes back both..
Keyboard (input) focus will be none. This does not affect pointer events.
> Sounds like he will still have to modify application 2 though.. (which
> he doesn't have control over..)
I can't think of any other way...
Leo
|