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
Add a utility project to get config.h and gdkconfig.h from their *.h.win32
(or win32_broadway, if applicable) counterparts, using custom build rules,
so that these "generated" files can also be removed on clean and
"regenerated" upon update. This also enables the removal of configs in
certain projects that isn't really needed as a result.
Also update and merge the projects and property sheets to include a single
property sheet that it needs, which will then in turn include the other
property sheets that is needed, so that things are cleaner.
Add a utility project to get config.h and gdkconfig.h from their *.h.win32
(or win32_broadway, if applicable) counterparts, using custom build rules,
so that these "generated" files can also be removed on clean and
"regenerated" upon update. This also enables the removal of configs in
certain projects that isn't really needed as a result.
Also update and merge the projects and property sheets to include a single
property sheet that it needs, which will then in turn include the other
property sheets that is needed, so that things are cleaner.
Updates to the Visual Studio 2010 projects will follow later.
This header, which is not universally available, is accidently made to be
included unconditionally during the refactoring of gtkapplication.c,
so restore the #ifdef check.
Applications need a way to fix or adapt the decoration layout,
for situations like split header bars. Setting the layout from
the theme with a style property did not offer a good way to do
this, and the ::show-close-button property does not provide
fine-grained control.
To improve the situation, move the layout string to a property of
GtkHeaderBar which is backed by a setting. This allows platforms to
set a default button layout independent of the theme, while applications
can override the default.
The style GtkWindow style property is now deprecated and ignored.
