These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
With the 3.0 transition, this code went from just querying the entry's
height request to doing a full size request.
Then it got code to revert the features that a full size request does.
And then it grew code that manually computed the baseline.
Avoid this and just do what happened back in the days: Do a regular
height request.
This changes the semantics of the get_frame_size() vfunc wrt its
behavior towards subclasses overwriting the get_height() vfuncs, but I'm
happy to live with that.
Failure to do so results in custom styling leaking through in
the inspector. This is pretty obvious, now that the inspector
is using a separate display connection and is generally isolated
from style changes.
With the recent save-is-child changes, using
gtk_style_context_get_padding (context, different_state)
will now open a subelement.
This is not what we want, so we check the state whenever we get the
button contexts.
Changing adjustment via the property setter would not emit
value-changed, however changing it via gtk_spin_button_configure would.
This inconsistency had the following side-effects:
- Setting an adjustment with a different value would not update the
value shown by the spin button.
- Creating a spin button like this (common in GtkBuilder XML) will
not show the initial value:
g_object_new (GTK_TYPE_SPIN_BUTTON, "adjustment", adj, NULL);
Let's use the same code path (ie. gtk_spin_button_configure) for all
public facing API for setting adjustment. The code that handled the
details of swapping out the old adjustment with the new has been split
into an unset_adjustment method and the rest has been folded into
gtk_spin_button_configure.
A spin button really needs an adjustment to work, so we don't need
most of the NULL checks. However we do need to check in
unset_adjustment because setting a new adjustment during object
creation might try to unset a non-existent one.
https://bugzilla.gnome.org/show_bug.cgi?id=734660
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.
Those get in the middle more than help on these widgets, the widget
is already packed with clickable areas and having handles (and their
invisible clickable area around) hovering above don't help, plus the
purpose in most likely numeric values is a bit doubtful.
All touch events are either consumed by the up/down panels, or
the swipe gesture, all GtkEntry handling of touch events on the text
window is avoided, so handles to not appear anymore.
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.
We've recently a number of classes wholly. For these cases,
move the headers and sources to gtk/deprecated/ and adjust
Makefiles and includes accordingly.
Affected classes:
GtkAction
GtkActionGroup
GtkActivatable
GtkIconFactory
GtkImageMenuItem
GtkRadioAction
GtkRecentAction
GtkStock
GtkToggleAction
GtkUIManager
Cache the style contexts for the up and down panels, instead of recreating
them each time they are drawn or size requested. GtkSpinButtons were
many times slower to draw than other widgets because of the constant
style matching.
https://bugzilla.gnome.org/show_bug.cgi?id=698682
This replaces the previously hardcoded calls to gdk_window_set_user_data,
and also lets us track which windows are a part of a widget. Old code
should continue working as is, but new features that require the
windows may not work perfectly.
We need this for the transparent widget support to work, as we need
to specially mark the windows of child widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=687842
We were adding one child too much to the style context path when
generating it for the internal buttons, which in turn caused sibling
selectors from the theme such as :first-child to apply to both buttons
under certain circumstances. Spotted by Lapo Calamandrei.
