Add back a property that determines whether an individual
widget will accept focus or not. :can-focus prevents the
focus from ever entering the entire widget hierarchy
below a widget, and :focusable just determines if grabbing
the focus to the widget itself will succeed.
See #2686
We want to remove GtkBin and GtkContainer as they don't
provide much useful functionality anymore. This requires
us to move get_request_mode and compute_expand down.
We have to implement GtkBuildable, in order to keep
the <child> element in ui files working for aspect
frames.
See #2681
After the :can-focus change in the previous commit, widgets
need to set suitable focus and grab_focus implementations
to implement the desired focus behavior.
This commit does that for all widgets.
Restructure the getters for event fields to
be more targeted at particular event types.
Update all callers, and replace all direct
event struct access with getters.
As a side-effect, this drops some unused getters.
The reason for this is simply that I want to get hash functions that
have their values close together, so they can fit in a smaller range
(the goal here is 12 bits). By using GQuark, we get consecutive numbers
starting with 1 (and applications have <1000 quarks usually), whereas
interned strings can be all over the place.
As a side effect we also save 64 bytes per declaration.
The junction doesn't make sense when we use indicators, since the
scrollbars overlap anyway. Not snappshotting it anymore has no visual
effect since it's being drawn below the scrollbars anyway.
This adds specific marshallers for all of the locations where a generic
marshaller is being used. It also provides va_marshallers to reduce the
chances that we get stack traces from perf going through ffi_call_unix64.
This is forward ported from gtk-3-24.
# Conflicts:
# gtk/gtkeventcontrollerkey.c
# gtk/gtkeventcontrollermotion.c
# gtk/gtkgesture.c
# gtk/gtkgesturemultipress.c
The code interprets NULL to mean 'create a new Adjustment and use that,
deposing the old one', but we neither documented nor annotated that
ability, so users could be unsure how to "unlink" a specific Adjustment.
While users could pass their own Adjustment in if this wasn't nullable,
we already support NULL in the code, and it doesn't hurt to document
that this is available as a convenience while retaining the behaviour.
