Fixes Bug 645993 - XIM has wierd behaviors. Some XIM modules
filter every key event, possibly replacing it with their own
one. These events usually have serial=0, so make
GdkDeviceManagerXI2 also listen on these.
For client-side windows, we need to queue a repaint when the background
changes. For native windows, the windowing system does take care of it,
but client-side windows are our own, so we gotta do it manually.
https://bugzilla.gnome.org/show_bug.cgi?id=652102
This is already done in gdk_event_source_get_filter_window(), and
could lead to wrong event assignment if an event translator happens
to return a window for an event it doesn't handle.
This method can be implemented by event translators so they
return the right window from XGenericEventCookie events, as
ev->xany.window isn't meaningful for these.
GdkEventSource now also uses this to find out the right window
filters to apply.
XKB and GDK both add "internal" bits to GdkModifierType. In C,
this typically doesn't cause problems as bitfields are just integers,
and there's no validation. However for bindings, it's normal to
convert enumerations to "native" enumeration types, which don't
support unknown bits. See bug 597292.
https://bugzilla.gnome.org/show_bug.cgi?id=634994
It could be the case that gdk_window_set_cursor() is called on
pointers not yet known to the device tracking code in GdkDisplay,
so update the cursor on all master pointers.
The code actually updating the cursor for the given window has
been refactored out to gdk_window_set_cursor_internal(), used
in gdk_window_set_device_cursor() as well, which makes it handle
root/foreign windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=649313
-Update to distribute the VS2010 files.
-Added rules in Makefile.am's of GDK and GTK to fill in the
project/filter files templates with up-to-date source file
listings to simplify maintenace.
Any comments on the usage of the VS2010 files are welcome!
The zlib compressed xmlhttprequest thing was a nice hack, but it doesn't
really work in production. Its not portable, doesn't have enought API
(missing notification for closed sockets) and having to synchronize
between two different connections in a reliable way is a pain.
So, we're going everything over the websocket. This is a pure switch,
but after this we want to modify the protocol to work better over
the uncompressed utf8 transport of websockets.
Some special key keycode values as seen in keydown actually match
normal keys (like "." has a keyCode 46 on keyPress, which is the same
as Delete, but 190 for KeyDown). So we must match the special keys on
keypress. However, some things must be checked on keydown as they are not
generating keypress events.
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
