Since XIQueryVersion, the bad API that it is, enforces the version from
the first client that requests it, for clients to be able to use the new
features in XI2.3, we need to ensure that we pass XIQueryVersion 2.3 as
the version that we support. We know that GTK+ won't be confused by the
new features.
The X server should fill in the minor version that it supports in the
case where it only supports the older version, so we can safely always
pass a higher version number than is potentially supported by the
server.
libXi was designed to be stable in the case where it doesn't recognize
requests or events/replies, so this should still work in a case where
we have new versions of the X server, and GTK+, but an old version of
libXi, at least for however well that setup should work.
Olivier Fourdan [Mon, 21 Jan 2013 10:49:45 +0000 (11:49 +0100)]
gdk: add gdk_window_set_fullscreen_mode()
and gdk_window_get_fullscreen_mode() API to allow
applications to specify if a fullscreen window should
span across all monitors in a multi-monitor setup or
remain on the current monitor where the window is
placed.
Fullscreen mode can be either GDK_FULLSCREEN_ON_ALL_MONITORS
or GDK_FULLSCREEN_ON_CURRENT_MONITOR.
GtkFileChooser: Remove the last remains of the last_folder_uri logic
This is akin to commit cfb09e565460fd463a0822c8c8dbb0521d9fcab9 in the gtk-2-24 branch;
the last_folder_uri is no longer being used for anything meaningful, so we
remove it altogether.
Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Benjamin Otte [Thu, 24 Jan 2013 13:25:27 +0000 (14:25 +0100)]
widget: Allow invisible toplevels to do sizing operations
This is a quickfix to keep things working.
It turns out GtkWindow assumes it can do sizing operations while not
being visible, or while in the process of show()ing/hide()ing itself.
And commit b495ce54 broke these operations.
Figuring this properly requires some more thinking and restructuring on
my part, so for now we relax the requirement of visiblility enough for
these things to start working again.
Allows to access Wayland specific window information like wl_surface and
wl_shell_surface.
Add gdk_wayland_window_get_wl_surface for getting the Wayland wl_surface
and gdk_wayland_window_get_wl_shell_surface for getting the Wayland
wl_shell_surface.
Chun-wei Fan [Wed, 23 Jan 2013 06:03:30 +0000 (14:03 +0800)]
Prepare Visual Studio 2010 projects for Visual Studio 2012
This adds a PlatformToolset tag in the project configs so that we can
provide support for Visual Studio 2012 with relative ease as the format
of the VS 2012 projects are only slightly different from their VS 2010
counterparts.
We can then use a script like the one used in GLib[1] to copy the VS2010
projects and replace the necessary tags to create the VS2012 projects.
This also cleans up the projects and property sheets, as there were some
unwanted/unneeded entries in them.
Chun-wei Fan [Wed, 23 Jan 2013 05:56:11 +0000 (13:56 +0800)]
Visual C++: Update gtka11y projects completion
-Rename the "libgail" projects to gtka11y, for consistency with the
autotools builds
-Update the projects completion in gtk/a11y/Makefile.am, as the sources are
now listed under $(libgtka11y_la_SOURCES) instead of $(libgail_la_SOURCES)
Rob Bradford [Tue, 22 Jan 2013 19:08:56 +0000 (19:08 +0000)]
wayland: Handle the keymap being needed before we know about seats
In the Wayland backend implementation for gdk_display_get_keymap we enumerate
the known devices and look for an core keyboard device. These device objects
are created when we receive the capabilities for the seat. The seat
capabilities may be received after a request for the keymap so we handle this
by creating a temporary keymap which we then free later when we have the real
one.
Matthias Clasen [Mon, 21 Jan 2013 03:16:47 +0000 (22:16 -0500)]
Use g_signal_connect_object for adjustments in GtkSpinButtonAccessible
An instance of GtkAdjustment may be used by another instance after
the spin button widget is destroyed. In that case, the function
gtk_spin_button_accessible_value_changed() will be called with an
invalid argument. This situation is often caused when one use
GtkCellRendererSpin widget. To avoid invalid call of the function,
the signal handler for the "value-changed" signal should be disconnected
when the spin-button widget is destroyed.
Using g_signal_connect_object achieves just that.
https://bugzilla.gnome.org/show_bug.cgi?id=691592
Rob Bradford [Thu, 17 Jan 2013 16:05:25 +0000 (16:05 +0000)]
wayland: Drop build configuration support for cairo-gl
The underlying code uses API that is no longer available with 1.0. This
optional, off by default build mode hasn't worked since the release of
Wayland 1.0.
Carlos Garnacho [Mon, 3 Dec 2012 17:28:57 +0000 (18:28 +0100)]
gdk: strengthen touch crossing event synthesizing on programmatical crossings
There are cases where crossing events aren't generated by input devices themselves
but rather through programmatical means (windows being moved/hidden/destroyed while
the pointer is on top).
Those events come from X as sourceid=deviceid, and GDK does its deal at lessening
this by setting a meaningful source device on such events, although this caused
some confusion on the mechanism to block/synthesize touch crossing events that
could possibly cause bogus enter events on the new window below the pointer.
John Lindgren [Thu, 20 Dec 2012 07:08:12 +0000 (02:08 -0500)]
Better resize of expandable columns
Since 16195ad the “expand” property is always set to FALSE when a
column is resized. This commit takes a different approach and enables
“expand” whenever the column is wide enough. An appropriate
“fixed-width” (so that the desired width is achieved after expanding) is
calculated using equations that are explained in the code.
John Lindgren [Tue, 18 Dec 2012 07:06:12 +0000 (02:06 -0500)]
Use minimum/natural size semantics
Rewrites gtk_tree_view_column_request_width() and
gtk_tree_view_size_allocate_columns() to respect the minimum and natural
sizes that are already being returned by
gtk_cell_area_context_get_preferred_width().
The convoluted logic explained (not!) by this comment has been removed:
“Only update the expand value if the width of the widget has changed, or
the number of expand columns has changed, or if there are no expand
columns, or if we didn't have an size-allocation yet after the last
validated node.” This logic seems to have been a workaround for the
“jumping” behavior fixed in 16195ad and is no longer necessary.
John Lindgren [Tue, 18 Dec 2012 06:26:37 +0000 (01:26 -0500)]
Use fixed width for resizing
Removes the hidden “resized-width” and “use-resized-width” properties
from GtkTreeViewColumn and instead uses the “fixed-width” property to
serve the same purpose. “fixed-width”, if set, will now override the
auto-sized width (-1 is now a legal value meaning “not set”).
Additional “cleanups” in this commit:
1. When the user resizes the column the “expand” property is now also
set to FALSE, in order to prevent the column from suddenly jumping to a
different width when the window is resized.
2. The code that translated mouse movement to column sizes has been
simplified:
the change in column width is now calculated directly from the distance
the mouse cursor has traveled. Weird behavior that might have happened
previously if the position of the column changed during resizing, is now
prevented.
3. There was some lengthy logic handling the keyboard shortcuts used to
resize treeview columns, which would call gtk_widget_error_bell() once
the minimum or maximum width was reached. Instead of rewriting these
checks I simply set the “fixed-width” property to what was requested,
relying on the fact that it is already clamped between the minimum and
maximum width during size allocation.
I will greatly surprised if anyone notices the missing error bell.
John Lindgren [Tue, 18 Dec 2012 05:47:07 +0000 (00:47 -0500)]
Kill gtk_tree_view_size_request
Splits up size_request() so that the height calculations are only done
when get_preferred_height() is called and the width calculations are
only done when get_preferred_width() is called. Since
get_preferred_width() does not change the treeview->priv->width value,
treeview->priv->prev_width will always be equal to it and can therefore
be removed. The only place where prev_width was used is a block in
gtk_tree_view_size_allocate(). This block seems to be adjusting the
horizontal scrollbar to account for treeview->priv->width having been
changed in size_request() and should no longer be necessary. A similar
block immediately above it seems to already account for the width change
in size_allocate().
John Lindgren [Tue, 18 Dec 2012 05:23:27 +0000 (00:23 -0500)]
Remove extraneous size request
After “validation” (i.e., background size calculations) of some cells,
size_request() was called here to update the internally cached size of
the treeview. Apparently not updating the sizes leads to some kind of
“inconsistency” that messes with top_row_to_dy(). In the GTK3 model for
size allocation, things are more complicated. The treeview can’t just
go ahead and calculate its own size any more; instead it reports both a
“minimum” and a “natural” size, and it doesn’t know what size it will
actually get until size_allocate(). It may be necessary to update
top_row_to_dy() to deal with not knowing the exact size.