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
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
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.
The button now claims its menu as a child for a11y purposes,
which makes it possible for ATs to see it when the navigate
the tree top-down.
Update the a11y test to match.
We go to extra length to set the desktop_uri to NULL when
desktop == home, but then we were adding the (non-functional)
place item anyway. Don't do that.
Fixes a tiny typo in commit f51c9d4154
which manifested itself in GtkSpinButton's panels being drawn with an
incorrect, not updated state.
This patch took me more hours than you might think! :P
https://bugzilla.gnome.org/show_bug.cgi?id=709491
The reason why some of the strings in gtkprintunixdialog.ui
were missing is that we did not extract translatable string
from <item> elements. Fix that.
gtkapplication.c has turned into a bit of an #ifdef mess over time, and
many of the current checks are incorrect. As an example, if you build
Gtk for wayland, and exclude the X11 backend, much of the functionality
required by wayland (such as exporting menu models) will be disabled.
Solve that by introducing a backend mechanism to GtkApplication (named
GtkApplicationImpl) similar to the one in GApplication. Add backends
for Wayland, X11 and Quartz, with X11 and Wayland sharing a common
'DBus' superclass.
GtkApplicationImpl
|
/--------------+-------------------\
| |
GtkApplicationImplDBus GtkApplicationImplQuartz
|
/-----------+-----------------\
| |
GtkApplicationImplX11 GtkApplicationImplWayland
GtkApplicationImpl itself is essentially a bunch of vfuncs that serve as
hooks for various things that the platform-specific backends may be
interested in doing (startup, shutdown, managing windows, inhibit, etc.)
With this change, all platform specific code has been removed from
gtkapplication.c and gtkapplicationwindow.c (both of which are now free
of #ifdefs, except for a UNIX-specific use of GDesktopAppInfo in
gtkapplicationwindow.c).
Additionally, because of the movement of the property-setting code out
of GtkApplicationWindow, the _GTK_APPLICATION_ID properties (and
friends) will be set on non-GtkApplicationWindows, such as dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=720550
We don't want the maximum size to be smaller than the minimum size. Not
just because it's wrong but also because when this happens the rest of
GTK gets mighty confused and infloops resizing to min-size and
max-size in turns causing a flickering window. Well, at least if you
run X without a window manager. Or your window manager hasn't finished
starting up.
Private RHEL bug finding this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1035409
This could happen if data was requested from a separate screen now that
multi-screen is no longer supported.
Ideally, we'd want to support copying to other screens, but that
requires solving in GDK as that's X-specific so cannot be well
abstracted by GDK (without the reintroduction of multiple screens).
https://bugzilla.gnome.org/show_bug.cgi?id=719314
