This will allow further cleanups and optimizations in capture/target/bubble
event delivery. For simplicity, ATM every widget will receive its own
GtkEventControllerLegacy, it could be desirable to add finer control over
this in the future, so widgets that fully use event controllers for input
management can do away without this legacy piece.
gtk_widget_draw_internal is now only used inside gtkwidget.c, so remove
the prototype from gtkwidgetprivate.h. And since all incovacations call
it with clip_to_size=TRUE, remove that parameter.
Since gtk+ draws more than the widget and allocates more size to it than
it knows about, this flag doesn't work anymore. Removing it (or setting
it to TRUE for widgets that used to set it to FALSE) fixes drawing
invalidation when these widgets get allocated a new size.
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
This function will be useful in other places, such as determining the
widgets that must receive crossing events after pointer picking points
to another widget.
We now try to emulate cairo_t:
We keep a stack of nodes via push/pop and a transform matrix.
So whenever a new node is added to the snapshot, we transform it
by the current transform matrix and append it to the current node.
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.
GtkWidget.create_render_node() sets up a GskRenderNode appropriate for
rendering the contents of a widget, including its bounds,
transformation, and anchor point.
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.
GTK used to not emit GtkWidget::style-updated on widgets that weren't
realized. This sped up construction of complex widgetry in the early
days of GTK3 where we instantly invalidated on every change.
We don't do that anymore, so in theory (and in my limited testing with
widget-factory) this shouldn't be a prolem anymore.
What is a problem though is that postponing style-updated leads to 2
problems:
(1) Unrealized widgets will not emit style-updated which may cause them
to not properly update their state and return wrong values from
get_preferred_width/height() etc
(2) Emitting style-updated during realize can happen too late.
When a widget is not made child-visible by its parent (common
examples: notebook, paned) it will also not be realized when the
parent is initially shown. However, when they get realized later
(after a resize of the parent), they will emit style-updated (and
potentially queue a resize) during size-allocate.
https://bugzilla.gnome.org/show_bug.cgi?id=765700
Previously, we had a special cae to draw subwindows of widgets.
This is not necessary as conformant widgets should be able to properly
render themselves when all windows need to be painted.
From now on assume that is the case.
We therefore paint nonnative GDK windows "inline" by just returning TRUE
for gtk_cairo_should_draw_window() for those windows.
This speeds up hilighting different rows in the listbox gtk-demo example
tremendously (by a factor of 10 or more) as the previous code was
O(<number of non-window subwidgets> *
<number of subwindows>) which in the listbox example were ~15,000 and
~2,000 respectively.
There are currently three widget that implement such a property, and
there are other widgets for which the behavior can make sense. It
seems like a good time to add the property to GtkWidget itself so
subclasses can choose to respect it without adding their own property.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
This commit toggles the big switch. We now don't run size_allocate()
from the toplevel up anymore in cases where we don't need to.
Things might be broken in subtle ways as a result of this commit. We'll
have to find them and fix them.
... and API to set and unset it.
It is set when gtk_widget_queue_resize() is called.
It is unset when gtk_widget_get_preferred_width/height() is called.
So far it is not used.
Merge it into GtkWidgetPrivate. In my measurements, about half
of all widgets have a non-default auxinfo struct, and we use this
information in size allocation, so it is nice to avoid the gdata
overhead.
We only use widget paths for a few widgets nowadays (notebook,
treeview, pathbar, combobox), so we can save some space by
not having this field in GtkWidgetPrivate.
The hash table is only accessed at creation and destruction time,
and many widgets don't use templates at all, so no need to have
this permanently occupying space.
When recomputing CSS, we need a correct widget path in the fallback mode
where we're still using widget paths.
So we need to invalidate it everytime it actually changes, and not just
when emitting the style-updated signal.
Fixes css-match-regions reftest.
Postpone until the last moment whether the target widget still
potentially uses updates from this sequence, or window dragging
actually applies because all gestures on the target went to denied
state.
This fixes window dragging on empty space in a headerbar that is
contained in a paned (as in e.g. gedit).
https://bugzilla.gnome.org/show_bug.cgi?id=745562
The gesture is hooked to the capture phase, so it works for buttons in
header bars and whatnot. In order to be friendly to the widget it is
capturing events from, an ugly hack is in place to avoid capturing
events when the target widget has a gesture that would consume motion
events.
These functions, while added for use by the GTK inspector, are generally
useful to applications that need to resolve what action groups are
available to a particular GtkWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=741386
Currently we only take into account the window GActionGroup for
activating the accels.
However, the application could have some custom GActionGroup in the
chain of focused widgets that could want to activate some action if
some accel is activated while that widget is focused.
To allow applications to set accels on widgets that use custom
GActionGroups, simply use the muxer of the focused widget, which
already contains the actions of the parents.
https://bugzilla.gnome.org/show_bug.cgi?id=740682
Event controllers now auto-attach, and the GtkCapturePhase only determines
when are events dispatched, but all controllers are managed by the widget wrt
grabs.
All callers have been updated.
And handle the fact that drawing bounds are now handled by this API and
the corresponding gtk_widget_get_clip().
Also add _gtk_widget_supports_clip() function to check if a widget has
been ported to the new world.
The propagation phase property/methods in GtkEventController are gone,
This is now set directly on the GtkWidget add/remove controller API,
which has been made private.
The only public bit now are the new functions gtk_gesture_attach() and
gtk_gesture_detach() that will use the private API underneath.
All callers have been updated.
Rename our internal GActionMuxer, GActionObserver and GActionObservable
classes and interfaces to have names in our own namespace.
These classes were originally intended for GIO but turned out to be too
special-purpose to be useful there, so we never made them public API but
have just been copying them around (without bothering to properly rename
them). Now that other people will be copying them out of Gtk, it's even
more important to prevent this namespace abuse from spreading further.
gtk_widget_preferred_size() is only useful if you want to quickly port a
widget from GTK2 sizing code to GTK3 but does not properly work with
height-for-width as used in GTK. So we don't want to encourage people to
use it. In particular we want people to convert to height-for-width
before adding baseline support to their widgets.
We now consider non-native windows non-opaque, which means any invalid
area in a subwindow will also be invalid all the way up to the nearest
native windows. We take advantage of this by ignoring all expose events
on non-native windows (which typically means just the toplevel) and instead
propagating down the draw() calls to children directly via
gtk_container_propagate_draw.
This is nice as it means we always draw widgets the same way, and it
will let us do some interesting ways in the future.
We also clean up the GtkWidget opacity handling as we can now always
rely on the draing happening via cairo.
We can't really just draw by walking down the widget hierarchy, as
this doesn't get the clipping right (so e.g. widgets doing cairo_paint
may draw outside the expected gdkwindow subarea) nor does it let
us paint window backgrounds.
So, we now do multiple draws for each widget, once for each GdkWindow,
although we still do it on the same base cairo_t that we get for the
toplevel native window. The difference is only the clipping, the rendering
order, and which other widgets we propagate into.
We also collect all the windows of a widget so we can expose them inside
the same opacity group if needed.
NOTE: This change neuters gtk_widget_set_double_buffered for
widgets without native windows. Its impossible to disable
the double buffering in this model.
