_SVID_SOURCE has been deprecated in newer versions of glibc breaking
-WError; the recommended replacement of _DEFAULT_SOURCE is fairly
new, so switch to _XOPEN_SOURCE instead.
_SVID_SOURCE has been deprecated in newer versions of glibc breaking
-WError; the recommended replacement of _DEFAULT_SOURCE is fairly
new, so switch to _XOPEN_SOURCE instead.
The "original coordinates" passed into meta_window_place() were the
coordinates of the client rectangle not the frame rectangle. When
meta_window_place() didn't place because the window was manually
positioned (e.g., 'xterm -geometry +x+y') that resulted in a window
being offset by the frame dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=724049
Since the introduction of frame sync in GTK+, updates to titlebar font and
colors haven't been working because GTK+ counts on the frame clock to
do style updates, and the frame clock doesn't run for an unmapped
GdkWindow. (It's possible that GtkStyleContext changes subsequent to
the introduction of the frame clock were also needed to fully break
things.)
We actually need to map the MetaFrames GdkWindow and let the
compositor code send out the frame sync messages in order to pick up
style changes.
Hopefully no bad side effects will occur from this - we make the window
override-redirect, 1x1, and outside the bounds of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=725751
The "original coordinates" passed into meta_window_place() were the
coordinates of the client rectangle not the frame rectangle. When
meta_window_place() didn't place because the window was manually
positioned (e.g., 'xterm -geometry +x+y') that resulted in a window
being offset by the frame dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=724049
Since the introduction of frame sync in GTK+, updates to titlebar font and
colors haven't been working because GTK+ counts on the frame clock to
do style updates, and the frame clock doesn't run for an unmapped
GdkWindow. (It's possible that GtkStyleContext changes subsequent to
the introduction of the frame clock were also needed to fully break
things.)
We actually need to map the MetaFrames GdkWindow and let the
compositor code send out the frame sync messages in order to pick up
style changes.
Hopefully no bad side effects will occur from this - we make the window
override-redirect, 1x1, and outside the bounds of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=725751
Split up the property sheets, so that they are easier to maintain, and
clean up the projects and property sheets, especially on items that are
being repeated, and therefore silence many build warnings. Update the
project files correspondingly, and make all project files use Unix line
endings, for easier application of patches (the .sln and README.txt files
still has to have Windows line endings in order to work properly).
Also make the copying of config.h.win32 and clutter-config.h.win32(_GDK)
custom build rules, so that they may also be cleaned during the cleaning
of the build, which makes it easier for one to do a rebuild.
Similar updates to the Visual Studio 2010 project files will follow.
We need to resolve the keycode from the keysym again since the keycode
might have changed if there was a keymap switch between the grab and
the ungrab.
Before starting to use display_get_keybinding() we could compare
MetaKeyBinding.modifiers with MetaKeyCombo.modifiers directly. Now, we
need to resolve the virtual modifiers to match with the mask.
We need to resolve the keycode from the keysym again since the keycode
might have changed if there was a keymap switch between the grab and
the ungrab.
Before starting to use display_get_keybinding() we could compare
MetaKeyBinding.modifiers with MetaKeyCombo.modifiers directly. Now, we
need to resolve the virtual modifiers to match with the mask.
This allows us to look for a match with an O(1) search instead of O(n)
which is nice, particularly when running as a wayland compositor in
which case we have to do this search for every key press event (as
opposed to only when our passive grab triggers in the X compositor
case).
We actually need two hash tables. On one we keep all the keybindings
themselves which allows us to add external grabs without constantly
re-allocating the array we were using previously.
The other hash table is an index of the keybindings in the first table
by their keycodes and mask which is how we actually match the key
press events. This second table thus needs to be rebuilt when the
keymap changes since keycodes have to be resolved then but since we're
only keeping pointers to the first table it's a fast operation.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
Instead of looping over an array of keybindings to find the correct
binding, just use display_get_keybinding().
In the next commit, we'll change the array to be a hash map, so this
helps the patch be cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
This allows us to look for a match with an O(1) search instead of O(n)
which is nice, particularly when running as a wayland compositor in
which case we have to do this search for every key press event (as
opposed to only when our passive grab triggers in the X compositor
case).
We actually need two hash tables. On one we keep all the keybindings
themselves which allows us to add external grabs without constantly
re-allocating the array we were using previously.
The other hash table is an index of the keybindings in the first table
by their keycodes and mask which is how we actually match the key
press events. This second table thus needs to be rebuilt when the
keymap changes since keycodes have to be resolved then but since we're
only keeping pointers to the first table it's a fast operation.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
Instead of looping over an array of keybindings to find the correct
binding, just use display_get_keybinding().
In the next commit, we'll change the array to be a hash map, so this
helps the patch be cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=725588
We should use the Xkb API to query the direction of the key map,
depending on the group. To get a valid result we need to go over
the Unicode equivalents of the key symbols for each group, so we
should cache the result.
The code used to query and cache the key map direction is taken
from GDK.
https://bugzilla.gnome.org/show_bug.cgi?id=705779
We should set the direction on the PangoContext when creating a
PangoLayout based on a best effort between the contents of the text
itself and the text direction of the widget, in case that fails.
https://bugzilla.gnome.org/show_bug.cgi?id=705779
Currently clutter_device_manager_xi2_get_core_device always
does a round trip to query the client.
So avoid that by caching the client pointer and only update it when the
xi devices change.
https://bugzilla.gnome.org/show_bug.cgi?id=725561
This updates the Visual Studio 2010 Projects in the following ways,
similar to the recent changes to the Visual Studio 2008 projects:
-Make all the copying of the pre-configured header files custom build
rules, so that it is cleaner when people clean their builds, and the files
can be re-copied when updated.
-Split up the property sheets, so to ease future maintenance
-Make the cogl-path library built as a DLL
-Build and link against SDL-2.x for SDL builds
-Make everything except the .sln file and the README.txt file use UNIX line
endings, for easier maintenance.
-Merge cogl_sdl.sln and install-sdl.vcxproj into cogl.sln and
install.vcxproj respectively.
-Update build of the conformance test to not use COGL_COMPILATION, and make
it link to cogl-path.
Split up the property sheets, so that it is easier to maintain, and update
the project files accordingly. Also clean up the project files by
finishing up the merge of the *_sdl.vcproj items into their regular
counterparts, and dropping all the *_sdl.* files.
Make use of UNIX line endings for all the MSVC 2008 build files, except the
.sln file and the README.txt files, for easier maintenance.
We need to link the conformance test executable to cogl-path, so make that
project depend on the cogl-path project, so that it will link to it as
well.
