We were not checking the passed-in type in the right
way. An interface type can still pass the
g_type_is_a (..., G_TYPE_OBJECT) check, if G_TYPE_OBJECT
is one of its prerequisites. What we need to check is
whether the fundamental type is G_TYPE_OBJECT.
When using GtkBuilder to create constraints and guides,
the layout manager is already rooted when the guides get
created, and we were forgetting to create the guides
constraints in this case. Fix it by adding a call to
gtk_constraint_guide_update().
This was showing up in the new builder-based constraints
demo as the guide not having the expected effect.
This isn't strictly required for correctness, but
it makes the GtkBuilder codepath do the same that
the vfl codepath does: call gtk_layout_manager_layout_changed
only once, after all the constraints have been added.
Make the default factory add a checkmark to the
currently selected item (not the hovered item)
in the popup. This will unfortunately have to be
done in non-default factories too.
Related: #3291
Add a way to add children at certain places in
the generated menu for both GtkPopoverMenu and
GtkPopoverMenuBar.
New apis:
gtk_popover_menu_add_child
gtk_popover_menu_remove_child
gtk_popover_menu_bar_add_child
gtk_popover_menu_bar_remove_child
Fixes: #3260
This makes it so that you have to explicitly specify
"true" and "false" for the checked state, but it
matches how this enumeration is meant to be used.
This ensures that keybindings for small-step changes
work despite draw-value being FALSE now. This was
fallout from 8ca612c966 that showed up
as arrow keys not working anymore for the color scales
in the color chooser.
Instead of monitoring the list of toplevels, rely
on GtkWindow updating the HIDDEN state before windows
get removed. This is better, since we still have the
object available when it happens, so we can pass it
to the ATs.
We want to use the HIDDEN state to control when
things get added and removed from the accessible
tree, so ensure that we a) set HIDDEN to true
initially for windows, and b) we update HIDDEN
when a window is shown or hidden.
The second part is handled by gtk_widget_hide
for other widgets, but hiding a window does not
always go through that code path.
When a toplevel window gets hidden (and not destroyed),
the frontend code set the HIDDEN state, and we need to
emit child notification when that happens.
We need to use gtk_accessible_should_present() whenever we
calculate accessible tree positions, to avoid inconsistencies.
While we are at it, make these helpers usable for finding
the position of accesibles that are now ignored, by not
looking at should_present for the object itself. This will
be relevant when we calculate the position of objects whose
HIDDEN state changes.
We need to translate the list model position into
an accessible tree position, since hidden toplevels
will be skipped.
While we are at it, add an api for this notification
that will be used in the next commit.
Hidden elements are not presented in the accessible
tree, so when then HIDDEN state changes, we should
emit child-added or -removed signals.
This commit does not yet handle all cases (HIDDEN
toplevels or hidden stack pages are not handled),
but it should cover the common case.
The ARIA spec is clear on this: when an element has the
HIDDEN state, it should not be presented in the accessible
tree.
This change is incomplete, we also need to emit child-added/
removed signals when the state changes, but that needs to
wait for the child added infrastructure to land.
gtk_widget_reposition_after is called both to add new children,
and to reposition existing children. We only want to emit
accessible changes in the former case (since AT-SPI doesn't
have events for reordering).
Unparenting the stack finalizes the entry and label,
but at least the label is available via the
gtk_editable_get_delegate API, and the a11y
implementation uses that at dispose time. So, clear
the pointers to prevent them from being dangling.
This was showing up as a segfault of the doc-shooter.
When the compositor unmaximized the window, we get a
state-changed signal, and we update the maximized field.
But then we go and recompute our layout based on the
maximize_initially field, and that is still TRUE, when
we were maximized initially. So we need to update both
fields.
This fixes a problem where using the window menu to
unmaximize an initially maximized window would not
work.
Fixes: #3226
We are not using a box layout here since we want
to ignore the icons for measuring. But we still
want the layout to respect border spacing that
comes from the theme.
