Also make them more scary so people really really don't use it as a
random knob when trying to make things go fast.
//bugzilla.gnome.org/show_bug.cgi?id=750505
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
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.
... and pass it to the API that computes new styles.
A special timestamp of 0 means "please don't animate" and is used when
no frame clock is available for a node.
We don't want to add the current classes to the widget path - which
might potentially be different after a gtk_style_context_save() - but
the root node's ones. So what better thing to do than actually using the
root node?
This ensures the widget data stays live long enough to perform invariants
check after emission if the widget happens to be destroyed on a callback.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
They are a bit terse, and they should point to the preferred way of
overriding the theme, i.e. using a GtkStyleProvider for your
application, and custom style classes.
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.
There are two scenarios. A widget sub-class owns a GtkEventController
and passes itself to it, or a controller owned by something else is
passed a widget.
In the second case, if the widget is destroyed before the controller,
we will have a crash when destructing the controller because we will
be accessing invalid memory. Adding a weak reference on the widget
addresses that problem.
This leads to a crash in the first case. When the widget is getting
destroyed, it will drop the reference to its own controller. The
controller will skip touching the widget because the weak reference
would have turned it to NULL. However, when the widget sub-class chains
up to GtkWidget it will try to free all the controllers in its list.
Unfortunately, all these controllers have already been destroyed. So
we need to guard against this too.
https://bugzilla.gnome.org/show_bug.cgi?id=745225
Also try and clarify a few things about event propagation. Move
input-handling.xml into gtk-doc’s expand_content_files variable so it
automatically links to widget documentation. Add links from
gtk_widget_add_events() and friends to the new documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=744054
This property is necessary to ensure widgets automatically update after
the text scale factor is changed desktop-wide.
And if I'm already doing a property like this, I can make it
overridable. So now you can override the dpi per-widget with CSS like
GtkSwitch {
-gtk-dpi: 48;
}
if you want to debug things.
Long-term, we want to get rid of this property and insist on dpi being
96 everywhere and people can change the font size to get larger fonts.
Previously, we would not include any child widget on the first
allocation, which happens right after realize(), but before map(). No
widget is drawable at that point.
If this is done on dispose(), the widget may be destroyed (and its
controllers list NULLified) within _gtk_widget_run_controllers(),
causing warnings/crashes when it just tried to hop on the next
controllers.
Freeing the controllers here should be a safety net for implementations,
so it also makes sense to do this late. The widgets that choose to
free their controllers on dispose can still do so, and get
_gtk_widget_remove_controller() called for these as an indirect result.
There is no good reason to assign the value directly.
Also, this fixes d23f3254b7
where widgets that chained up instead of calling
gtk_widget_set_allocation() would not draw becaues of empty clip.
(1) Get rid of supports_clip flag. All widgets (implicitly) support
clip.
(2) Don't reset the clip to { 0, 0, 0, 0 } before the "size-allocate"
signal.
(3) Make gtk_widget_set_allocation() set the clip (to the allocation).
This ensures that eveyr widget has a clip set.
Note: It overrides previous calls to gtk_widget_set_clip(), while in
3.14 this didn't happen.
(4) As the clip is set by gtk_widget_set_allocation() now, don't set
it after the "size-allocate" signal anymore.
This fixes calls to gtk_widget_queue_draw() from inside the
size_allocate vfunc.
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
I checked Cairo source code (actually pixman, as Cairo just passes
through) to make sure that the behavior stays identical: negative values
cause an error message from pixman, zero is allowed. Both return an
empty region which gtk_widget_queue_draw_region() would then proceed to
ignore.
