Switch code to use gdk_display_is_composited() instead.
The new code also doesn't use a vfunc to query the property but rather
requires the backend to call set_composited()/set_rgba() to change the
value.
Includes the ability to turn on updates in the inspector. Animations are
now run via a tick function which allows us to neatly overlay a
semi-transparent red rectangle and fade it out over time.
It also probably enables way more, but somebody with more UI neatness
than me needs to figure out what it eanbles first...
Before, we would immediately invalidate the GdkWindow of the widget, now
we call the parent's GtkWidgetClass.queue_draw_child() function.
This allows the parent to track redraw queueing of children.
By default GtkWidgetClass.queue_draw_child() will again chain up to its
parent while respecting the GdkWindow hierarchy for clipping.
GtkWindow is then the only widget actually invalidating the GdkWindow.
This essentially moves redraw queueing from GDK to GTK.
These complicate a lot of GdkWindow internals to implement features
that not a lot of apps use, and will be better achieved using gsk.
So, we just drop it all.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
The details of the modelview and projection matrices are only useful for
the GL renderer; there's really no point in having those details
available in the generic API — especially as the Cairo fallback renderer
cannot really set up a complex modelview or a projection matrix.
Since we use an FBO to render the contents of the render node tree, the
coordinate space is going to be flipped in GL. We can undo the flip by
using an appropriate projection matrix, instead of changing the sampling
coordinates in the shaders and updating all our coordinates at render
time.
Render nodes need access to rendering information like scaling factors.
If we keep render nodes separate from renderers until we submit a nodes
tree for rendering we're going to have to duplicate all that information
in a way that makes the API more complicated and fuzzier on its
semantics.
By having GskRenderer create GskRenderNode instances we can tie nodes
and renderers together; since higher layers will also have access to
the renderer instance, this does not add any burden to callers.
Additionally, if memory measurements indicate that we are spending too
much time in the allocation of new render nodes, we can now easily
implement a free-list or a renderer-specific allocator without breaking
the API.
We need a virtual function to retrieve the GskRenderNode for each
widget, which is supposed to attach its own children's GskRenderNodes.
Additionally, we want to maintain the existing GtkWidget::draw mechanism
for widgets that do not implement get_render_node() — as well as widgets
that have handlers connected to the ::draw signal.
And replaces its usages in GtkTextView/GtkStyleContext with a hard-coded
0.04 which was the default value for cursor-aspect-ratio. Also remove
the public gtk_draw_insertion_cursor which used draw_insertion_cursor
which in turn looked up cursor-aspect-ratio
And with it, gtk_widget_get_visual() and gtk_widget_set_visual() are
gone.
We now always use the RGBA visual (if available) and otherwise fall back
to the system visual.
The cursor was set using gdk_window_set_cursor() even in
gdk_window_new().
So instead of having yet another flag, just make the users of that flag
call gdk_window_set_cursor() directly after the window was created.
X11 was the only backend to support it and people can just override it
using XSetClassHint() directly.
The docs already advertised the function as "Do not use".
Keep the existing call to XSetClassHint() in place, so that we keep
setting the same values as in GTK3.
Setting the shadow width earlier as done with commit 4cb1b96 to address
bug 771561 proved to cause unexpected side effects on size_allocate
signal propagation.
As the window is sized correctly earlier, the size_allocate signal is
not emitted again in gtk_widget_size_allocate_with_baseline() which
prevents clutter-gtk from relocating its child widget correctly.
To avoid this issue, revert commit 4cb1b96 but make sure the values
passed as min and max size is never negative in Wayland as this is a
protocol error.
With this, the min/max size will be wrong for a short amount of time,
during the state transition, until the shadow width is updated from
gdk_window_set_shadow_width().
This approach is much safer and less intrusive than changing the
size_allocate logic in gtk.
This reverts commit 4cb1b9645e.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=771915
Otherwise, with CSD, we could have a discrepancy where gtk uses the
right values for the shadows whereas the gdk backend still uses the old
values, leading in some cases to invalid or negative min size being
computed (which, in Wayland, leads a protocol error).
https://bugzilla.gnome.org/show_bug.cgi?id=771561
The main corpus of the documentation for gtk_window_get_size() is still
full of X11-isms, so we should port it to something that is more
backend-agnostic. Additionally, having some examples would be nice for
application authors looking at a way to appropriately use this function.
Introduce a private API meant for abstracting how to get a handle
of a window that can be shared with other processes. The API is
async, since some implementations will require that. Currently,
only X11 is supported, which doesn't.
Based on a patch by Jonas Adahl.
This matches the behaviour of Mutter, Metacity and traditional X11
window managers on the window manager side, and is what we want
for at least gnome-terminal. I can't think of any reason why we'd
want incremental resize in any other tiled window.
Signed-off-by: Simon McVittie <smcv@debian.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=760944https://bugzilla.gnome.org/show_bug.cgi?id=755947
If we have an application that never goes idle (or takes a long time to
go idle), the close buttons in CSD decoration don't work properly.
While it's not clear why the usage of an idle was added in the first
place, keep on using it to avoid unexpected reentrancy problems, but
change the priority to G_PRIORITY_DEFAULT.
https://bugzilla.gnome.org/show_bug.cgi?id=768485
This partly reverts 9f5b9c0e07, which
removed the check for GtkWidget-window-dragging in the multipress
gesture. This check is still needed for widgets which have this style
property set (e.g. menubars and toolbars) can maximize the window on
double click -- but those widgets which have it set to FALSE shouldn't
maximize the window.
