Add gtk_tree_path_new_from_indicesv which takes an array of
integers with a length. Use "Rename to" annotation to rename the
method as gtk_tree_path_new_from_indices. This is needed because
the original method takes variadic arguments which is not supported
by introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=706119
GtkMenuItemAccessible was assuming that an accel label is
always the immediate child of a menu item. It also did not
deal with manually set accels. Fix both of these.
https://bugzilla.gnome.org/show_bug.cgi?id=721086
Improve the color swatch accessible to set a proper role
depending on whether the swatch is selectable or not, and
set the checked atk state when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=721048
The initial state of GtkModelMenuItem is that of a normal menu
item, but the accessible we are using, GtkCheckMenuItemAccessible,
starts out with a role of 'check menu item'. Fix that up by
explicitly setting the initial accessible role.
GtkModelMenuItem does not emit the ::toggled signal when a radio
item is activated, so listen for property notification for that
property. We still keep the ::toggled signal handler, in order
to not break other uses of check and radio menu items.
https://bugzilla.gnome.org/show_bug.cgi?id=720983
GtkModelMenuItem emits no property notification, since none of its
properties are readable. But the toggled property is just a proxy
for GtkCheckMenuItem::active, so we should ensure that property
notification is emitted for the ::active property.
Ensure the hscrollbar & vscrollbar at gtk_scrolled_window_add() time,
this allows one to subclass GtkScrolledWindow with templates and add
children, as this will happen at instance initialization time before
the construct adjustment properties take effect.
And update the colorchooser a11y test to a) use GtkColorChooser
instead of the deprecated GtkColorSelection and b) match this
change. Pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=721045
fvwm seems to have problems keeping _NET_WORKAREA in sync with
the number of desktops. Instead of reading garbage, silently use
the full screen as workarea for desktops that are not covered
by the _NET_WORKAREA property.
https://bugzilla.gnome.org/show_bug.cgi?id=698248
This commit makes the label accessible implement AtkHypertext,
which returns a AtkHyperlink object for each link in the text.
At the same time, add AtkHyperlinkImpl objects as children
to the label accessible.
Also some private API to indicate that links have changed, and
call that from GtkLabel when needed.
Adjust expected output of the affected a11y tests.
https://bugzilla.gnome.org/show_bug.cgi?id=721410https://bugzilla.gnome.org/show_bug.cgi?id=721421
The get_end_index implementation was casting the accessible
to AtkText even though GtkLinkButtonAccessible does not
implement this interface. This did not show up in the a11y
tests because the they were not dumping the affected AtkHyperlinkImpl
properties. Oops.
Ignacio Casal Quinteiro reported a problem whereby an empty section at
the start of a menu has a separator placed after it. This was caused by
the implementation of the logic that separators should be inserted at
the top of all non-empty sections that are not the first section. This
logic is obviously incorrect in the case that the first section is empty
(in which case we would not expect to see a separator at the top of the
second section).
Change the logic so that we only insert separators when we see a
non-zero number of actual items in the menu before us.
https://bugzilla.gnome.org/show_bug.cgi?id=721119
When not doing cross-builds, use the values of CFLAGS, CPPFLAGS and
LDFLAGS as the default value for CFLAGS_FOR_BUILD, CPPFLAGS_FOR_BUILD
and LDFLAGS_FOR_BUILD, respectively.
This avoids having to manually specify these variables in order to get
extract-strings to build properly.
This should really be handled by ax_prog_cc_for_build.m4. That has been
reported upstream. This is a workaround for now.
https://bugzilla.gnome.org/show_bug.cgi?id=721346
If the platform data passed with actions and activations includes
a startup notify ID, we should read it and pass it down to GDK.
This ensures that the right startup notify is completed after the
signal emission, and that the user time of the GdkDisplay is properly
updated (which in turn makes sure the windows are not subjected
to focus-stealing-prevention)
https://bugzilla.gnome.org/show_bug.cgi?id=721304
