We can't really know the client side keymaps, so we use the keysym
as the hardware keycode (essentially claiming to have a keyboard with
one key for all possible keysyms). This is not ideal, but its hard to
do better with no knowledge of the client side keyboard mappings.
(And html keyboard events suck badly...)
We're using the noVNC keyboard even handling model (and some of the
code with permissions). This means we combine data from keydown and
keypress to figure out the translated keysyms according to the keyboard
layout at the users machine.
This symbol needs to be exported for GDK (Win32) so that the
runtime checks for Win32 backend usage can be done on
MSVC-compiled versions of GTK+ too.
I did not add the corresponding symbols for the other backend
though-they are probably exported automatically by GCC AFAIK.
This is done to make commit
9db4accf9c
work on MSVC
The XI2 device manager was mistakenly setting the window user_time on
both ButtonPress and ButtonRelease, which meant that processes that
tried to launch another process based on the time of a ButtonPress
event would end up always focus-stealing-preventing the new app.
https://bugzilla.gnome.org/show_bug.cgi?id=647275
As soon as something changes, even if it was a request from the user
we send a configure event. If not we might race with a app-side
generated configure event.
For instance, a create + resize might create only a configure event for
the create in the browser, but that may get to the app after the app-side
configure event for the resize, overriding the new size.
* Always calculate the context, don't store in surface.
* Store the toplevel element (frame or canvas) for easy access.
* Always use visibility hidden rathern than display none to hide windows,
as this means we can always rely on dom positioning info.
When syncing windows, make sure we set transient-for before showing
the window to avoid it being visible with the wrong transient-for
(i.e. possibly on the wrong browser window).
