The builder syntax for tags was invalid here (why did this not
get flagged as error ?!). While we're at it, give the warning
underline a nice, orange color.
If the buffer of a cursor is NULL, for example if its an empty cursor,
just set the cursor surface to NULL as well. Not doing this we'll use
uninitialized hotspot coordinates, dimensions and scales.
https://bugzilla.gnome.org/show_bug.cgi?id=758025
We can't use up_panel and down_panel as differentiators for the buttons,
because these window system resources don't exist before realize().
Just use a one-off enum for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=758094
This GdkDragContext should be created even if we don't have pointer
capabilities. Make it created on add_seat(), and only set the device
on wl_seat.capabilities, so it can be set to either master pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=741066
This is wrong by all accounts there, as we can do no tricks there to show
a "drag failed" animation, which is performed by the compositor itself
on wayland.
We use the high-level gdk_device_get_window_at_position() to figure
out the window, although this one actually tries to find out the
current window under the device coordinates, which might well fall
outside the window, so NULL is returned in those cases.
Fix this by using the lower level _gdk_device_window_at_position()
that will return the toplevel without further lookups, so is more
desirable here.
https://bugzilla.gnome.org/show_bug.cgi?id=758250
Now that we have multiple master pointers, this call may pick the wrong one.
Instead, pick the GdkWaylandDeviceData from the first device, and pick the
master pointer from there.
The common GDK code accounts for "pointer emulating" touch sequences to be
synchronized with the pointer position by the windowing system.
However on Wayland pointer and touch are completely independent, the backend
attempts to implement pointer emulation, but doesn't account for the
possible crossing events happening when the user switches from pointer to
touch or the opposite.
In order to fix this, and to ensure we don't have to interact with the
master pointer (which backs the wl_pointer), separate the touch interface
to have its own master pointer, and ensure crossing events are emitted on
it, so the picture of an "emulated pointer" is complete above the backend.
Inspired in a former patch by Jonny Lamb <jonnylamb@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=750845
The window button setup depends on properties of the toplevel window.
Instead of updating the setup on realize, do it when the toplevel
changes.
This makes sure that when a GtkHeaderBar is added to a window
all the widgets are present and get_preferred_height() will return
the height the widget will have when finally shown. This allows
the logic in gtkwindow to select the right window size so that
the content size will match the requested default size.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
Before the resulting window size would differ if the default size was set
before adding a headerbar vs after. Now the saved state is again the actual
requested size and it is adjusted at the time we request a window size.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
GtkHeaderBar will not show the maximize button if the window in not of
type normal or not resizeable.
Use the same restriction for double-click actions as well.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757530
Currently GtkStack has some G_PARAM_CONSTRUCT properties. That means,
the properties are set with its default value after the initializacion
of the object.
When using GtkBuilder to build objects, GtkBuilder creates them and
after that sets the properties found on the xml definition.
However, this is not true for templates because the template is initialized
in the init() function of the actual object, and after that, the construct
properties will be set.
This is a problem when someone wants to use templates with GtkStack and
set those properties, since they will be set on the tempalt initialization
and set again to its default values afterwards.
To fix this, make those properties not G_PARAM_CONSTRUCT.
https://bugzilla.gnome.org/show_bug.cgi?id=758086
