When the model button just has a text label and accel text,
the button fills and the accel label is implicitly aigned to end.
When there's also a icon, even though it's not shown (because
icons are only shown if there's no text), the button doesn't fill
and the accel ends up not aligned (assuming one of the other buttons
is longer). Ensure that the accel label is aligned to the end.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5504
gtk_widget_set_visible and gtk_window_present
are better alternatives, and calling gtk_widget_show
on newly created widgets is no longer necessary
anyway.
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
Let model buttons handle unpaired releases, these may happen indirectly
e.g. due to other child menus being opened at the time. Clicking would
dismiss the menu, but the menu item beneath the pointer would not get
activated.
We can handle that button release though via ::unpaired-release, so
there's no second click required.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3463
In commit 024d832d94, we introduced a
cascade-popdown property that makes closing a submenu
propagate up and close its parent menus. This is the
behavior we want when a menuitem in the submen is
activated.
What we overlooked is that we still need to be able to
close a submenu during navigation, before opening another
one. And in this case, propagating the closing is breaking
things. Fix this by adding a private close_submenu api
to GtkPopoverMenu that avoids the propagation.
Fixes: #3301
The expected behavior when activating check or radio
menuitems via keynav is that Space toggles the item
but keeps the menu open, while Return toggles the
item and closes the menu.
The hypothetical widget that needs to clone ATContext instances
because it needs to control the accessible role post-construction is
really GtkModelButton.
Fixes: #3342
Using GList is a bit lame, and makes the API more complicated to use
than necessary in the common case.
The only real use case for a GList is gtk_widget_add_mnemonic_label(),
and for that we can use the GValue-based API instead.
Fixes: #3343
When the button role changes, we want to update the
accessible role to match. Since accessible roles are
unchangeable post-creation of the AT context, we have
to cheat a bit and recreate the whole context.
Set the accessible role to GTK_ACCESSIBLE_ROLE_MENU_ITEM.
This is incomplete, we need to recreate the context when
the buttons role changes, and there are other things that
need to be set.
To build a better world sometimes means having to tear the old one down.
-- Alexander Pierce, "Captain America: The Winter Soldier"
ATK served us well for nearly 20 years, but the world has changed, and
GTK has changed with it. Now ATK is mostly a hindrance towards improving
the accessibility stack:
- it maps to a very specific implementation, AT-SPI, which is Linux and
Unix specific
- it requires implementing the same functionality in three different
layers of the stack: AT-SPI, ATK, and GTK
- only GTK uses it; every other Linux and Unix toolkit and application
talks to AT-SPI directly, including assistive technologies
Sadly, we cannot incrementally port GTK to a new accessibility stack;
since ATK insulates us entirely from the underlying implementation, we
cannot replace it piecemeal. Instead, we're going to remove everything
and then incrementally build on a clean slate:
- add an "accessible" interface, implemented by GTK objects directly,
which describe the accessible role and state changes for every UI
element
- add an "assistive technology context" to proxy a native accessibility
API, and assign it to every widget
- implement the AT context depending on the platform
For more information, see: https://gitlab.gnome.org/GNOME/gtk/-/issues/2833
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
This was only living in gtkcontainer.c for historic
reasons. Move it closer to where it belongs, and
rename it from 'idle' to 'layout', since it is
really about the layout phase of the frame clock,
nowadays.
We need to unset the propagation limit on the focus
controller, else we miss the focus-in when the focus
enters the popover upon initial popup, when it comes
from the parent button.
When a model button in a popover displays a shortcut,
it is probably from the global shortcut controllers,
and will not work inside the popover, since that is
a different native. Install a shortcut using the same
trigger that just activates the model button. This
shortcut will end up in the managed shortcut controller
of the popover.
