I recently turned gtk_widget_activate_action()
into a varargs function. That is more convenient
from C, but we need a non-varargs variant for
bindings. So add the old API back, under the
name gtk_widget_activate_action_variant(),
with a rename-to annotation.
We need to create a muxer eagerly for every
widget that has class actions, since those
are otherwise missed in the action lookup
on the muxer side. But otherwise, there is
no reason to create parent muxers aggressively,
as long as we update the parent muxers on
root/unroot.
This reduces the number of muxers we create
in widget-factory from 210 to around 50.
Previously, we would not look any further for
an action once we found a match for the prefix,
defining inheritance by groups. Change this to
inheritance for individual actions, since we
are moving towards individual actions as the
main ingredient in GTKs action support.
The only cases of stateful actions we've seen
so far have been boolean properties, and we
don't really want to add much state handling
API, so lets just go with property actions
for now.
Adapt the only user in GtkText.
along with a new 'type-format' setting that allows
to choose the output format for the "Type" column.
The options implemented for this setting are:
'mime' : Output from g_content_type_get_mime_type().
'description' : Output from g_content_type_get_description().
'category' : It uses the corresponding generic icon
of the mime type to group by categories (aka basic types).
This produces a more compact output than previous options,
and allows for type families to be grouped together, so eg.
after sorting by "Type" column, jpeg and png images will
be placed together, or the various types of archiver files
will also be grouped together.
This format was copied from and currently used by Nautilus
list view, so we also improve consistency with Nautilus.
Bugzilla entry for Nautilus implementation is:
https://bugzilla.gnome.org/show_bug.cgi?id=683722
The list of type families or categories can be checked on:
https://developer.gnome.org/icon-naming-spec/#mimetypes
This 'category' format is set as default.
Issue #362
Some users expect that the Overlay will automatically request enough
size for its overlay children as well as its main child. It doesn't,
because it's just a GtkBin. Add a short paragraph pointing that out.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1939
The only glancing mention of this we had was that GtkButton mentioned it
in passing when discussing how `button` could get contextual classes,
and even that's not relevant in master anymore... so drop it from there.
Port GtkColorChooserWidget to use widget class actions.
Note that this also changes the names of
the GtkColorChooserWidget actions away from a generic
"context" prefix.
Port GtkLinkButton to use widget class actions.
Note that this also changes the names of
the GtkLinkButton actions away from a generic
"context" prefix.
Add a facility to register and install actions
at class init time. The intended use for these
actions is for
a) context and other model-based menus
b) key bindings
Most of these actions are going to be stateless,
so add separate apis for the simple and stateful
cases.
We avoid creating an action group for these by
teaching the action muxer about these actions.
The action muxer also maintains the enabled
state for these actions.
Instead of iterating action groups manually,
just show what the action muxer provides. This
gives an accurate view of what actions are
available in a widgets context, and saves us
the trouble of juggling prefixes manually.
Instead of duplicating this code in multiple places,
add an api to look up an action group for a prefixed
name, and return the unprefixed name at the same time.
Page ranges entry can now be focused directly, and will automatically
select the page ranges button when doing so.
This avoids the sometimes counter-intuitive previous behavior where the
entry was automatically focused when toggling the radio button, but the
user may still find themselves clicking uselessly in the text entry
because they scheduled it in their mental model.
Instead, use a new title style class to let
themes influence title formatting. Note that
the theme style will be overridden if the
application uses markup for presentation,
such as <b> or <i>.
Drop the ::populate-popup signal and implement
the new context menu api. Things are a bit more
complicated here, since we have different menus
on links and selectable text.
Menus traditionally don't have separate
hover and focus locations. Make the same
change here that we already did for
popover menubars: Track the active item
and set its selected state. Both keynav
and mouse change the active item.
This solves issues with parent widgets, like combobox
or entry, installing their own bindings for these
keys, overriding the activation behavior that
is implemented in gtkwindow.
This solves issues with parent widgets, like textview
or scrolled window or combobox installing their own
bindings for these keys, overriding the focus behavior
that is implemented in gtkwindow.
Add a convenience api to skip children
that should not be included in the layout,
and call gtk_native_check_resize on all
native children outside of the vfunc.
We can't call gtk_widget_destroy on something
that wasn't added as a child to a container -
it ends up calling gtk_container_remove, which
asserts if it doesn't find the child.
Make gtk_widget_real_focus do the right
thing for focusable widgets with children.
A case where this is (now) relevant is
an entry with a context popover.
The new rule for focus events from the windowing
system is: We only want them for toplevels. If you
put focus on popups, we don't want to know about
it, and you still need to deliver key events to
the toplevel.
This is expected menu keynav behavior: If the
focused item has a submenu, open it on right
arrow press. And if we are in a submenu title,
make left arrow press close it.
Widgets are supposed to call gtk_widget_child_focus.
Calling internal focus_move function directly makes
us skip the childs ::focus() implementation, which
is where the magic happens.
Make left/right cycle the active item
among the bars children. Separate the styling
for the active item from :hover, since it is
a separate state, and only mixed up in menus
for historical reasons.
Make gtk_popover_new_from_model() return a GtkPopoverMenu,
rename it to gtk_popover_menu_new_from_model() and add
a relative_to argument to gtk_popover_menu_new().
Update all callers.
We can't improve popover menus as long as we
have to be able to work with any old popover
we're given. Remove this, so we can make
gtk_popover_new_from_model return a subclass.
These need to be skipped in measuring,
and we need to call gtk_native_check_resize
on them during allocation.
This was showing up as the new-style
context menu in widget-factory forcing
its relative-to box to grow when its
shown.
We only want to reserve indicator size if
there are any checks or radios in the popover.
Unfortunately, GtkIcon has a hardcoded min-size
of 16, defeating this use. Work around by
wrapping each indicator in a box, and showing/
hiding the actual indicator.
When we are not given an explicit accel (as is
the case when the popover is constructed from
a model), then look it up from the GtkApplication
at map time.
Move checks to the left, and introduce a size group
to align things. The size group is provided by the
parent, using the new ::indicator-size-group property.
This gets us out of using direct presentational
markup like 'inverted' and 'centered' and will
make it easier to play with different layout.
Use the new role when creating popover
menus from models.
We don't need to cover every case with a va_marshaller, but there are a
number of them that are useful because they will often only be connected
to by a single signal handler.
Generally speaking, if I opened into a file to add a va_marshaller, I just
set all of them.
