* Jean-Sébastien Guay -- Thursday 31 July 2008:
> But how does that work with Alt-Tab for example? When the focus leaves
> the app, the alt key is still pressed (physically)...
We release first Tab then Alt on leaving (and whatever else is pressed
in the eyes of osgViewer). On entering we just sync OSG with X11 again,
and report keypresses for everything that X11 says is pressed. So we get
the Alt and then the Tab again.[1]
> I also considered whether it was right to release keys when focus leaves
> the app or when it comes back. If I'm driving a vehicle forward,
> pressing the up-arrow key, and some other app steals focus (as apps like
> to do on Windows... :-( ), do I want the vehicle to continue moving
> forward or to stop?
This may be a matter of taste for the case where a window steals focus.
But it's not one for the case where the desktop is switched. I don't
think we ever want an auto-repeating key firing for minutes or hours
while we are on the other virtual desktop. I think that releasing on
leaving is the less surprising way for both cases. People just have
to realize that a window without focus just doesn't take any input
(except joystick input, perhaps). That's the definition of "focus",
after all. You lose focus, you lose the key input. Bad luck! :-)
> Well, yes I can and I do, but since my handler is called when focus
> comes back to the window, it doesn't necessarily come back to the same
> window if the app has multiple windows.
No, but only one window can ever have focus. If I release all keys
in one window on leaving, and (virtually) press all actually pressed
ones for the newly focused window, then the effect should just be as
if it was the same window all along.
> I found out that when focus comes back to the app, I don't need to send
> keyPress events for keys that are pressed in reality but which the app
> doesn't think are (presumably because of keyboard repeat or something
> like that). So what I could do is that when focus leaves the app, I
> could just release all keys. When focus comes back, the keys that are
> pressed in reality would send events and all would be well, no keys
> would be stuck.
This wouldn't work for "me" (X11), as I don't get regular key press
events reported for keys that are held down when entering. I *have*
to check that myself and generate these (osg) events. But that's not
a problem. Seems to work well so far.
m.
[1] To be fair: someone reported a problem with Alt-Tab desktop switching.
I just can't reproduce it and it doesn't make much sense to me, so
I'll have to leave fixing that (if there's really something to fix)
to the concerned people. I use Super-Tab for desktop switching, and
it works perfectly. And there's no distinction made between Super and
Alt anywhere in the code, so it should work just the same.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
