GitLab

... instead of of using impl->window_scale directly.

If a window spans both a low- and high-DPI monitor, we need to take the
scaling factor into consideration, or the HiDPI monitor will appear to
have a larger part of the window (because it spans more physical
pixels) even though it actually intersects a smaller (scaled) area.

... and use it to not connect anything to the frameclock if it isn't
set.

This gets around the problem that the frame clock is disconnected before
GtkWidgetClass.unrealize() is called but the widget is still marked as
realized and the frame clock is available during the vfunc, which makes
calls like gtk_widget_queue_resize() reconnect to the frame clock.

Closes #168

People playing with those examples tend to mess up things, so it's
really really unhelpful if we don't do error checking.

wayland: Fix setting geometry hints

See merge request GNOME/gtk!98

Since we're referring to GLib's functionality, might as well save some
time to the reader, and link to the GResource API reference page.

The links to the repository's web UI still refer to the old
git.gnome.org cgit UI, and to the master branch; we should be using
GitLab and the gtk-3-22 branch instead.

gtk_item_factory_new() is not a thing that exists.

Also, maybe the lack of space after the colon was what stopped the link
from rendering.

When asked for a nonexistent (positive) monitor number,
gdk_x11_display_get_monitor would (at best) return an uninitialized pointer,
instead of returning NULL.

GNOME/gtk!107

Test more stuff.

This reverts commit ba307aa3.

This is not needed; see the previous commit for the explanation.

GNOME/gtk#163 (comment 94842)

I was setting a GtkButton:label, which resulted in the ModelButton's own
custom children getting lost. That doesn't make for a useful test...

GNOME/gtk#163 (comment 94842)

Do the same thing we do everywhere else for invalid properties.

and load at an earlier, more sensible place, before creating any widgets

Redrawing is insufficient: when :role changes to/from NORMAL, the
indicator gadget reallocates, but we didn't reflect that in the widget.

GNOME/gtk#163

the same way we do normally.

and test whether :action-name, :role, and CSS nodes work as expected

GNOME/gtk#163

gtktextviewaccessible: update cursor position after text suppression

See merge request GNOME/gtk!101

gtkentryaccessible: Fix text-changed::delete length

See merge request GNOME/gtk!99

delete_range_cb is set to be called before the text suppression done by
the gtktextlayout (otherwise it does not work properly). But at that
point the cursor position is not yet up to date.  We thus need to move
the accessibility cursor notification to after the actual text
suppression, by using another callback.

This fixes cursor position in brltty screen reading.

The second parameter of the text-changed::delete event is to be the length,
not the end position.  This fixes spurious text removals in brltty
screen reading.

The stable xdg_shell port (5c8bb51a) introduced an error in
gdk_wayland_window_set_geometry_hints which would set the minimum size
to the maximum size, if provided.

This resulted in various wxWidgets apps (FileZilla, Audacity, Veracrypt)
crashing because they attempted to allocate a ginormous surface.

Fixes #157.

Like other widgets, this returns a floating reference, so
(transfer full) is wrong. Just omit the annotation as others do,
thus implying (transfer none).

Close GNOME/gtk#156

We were emitting a preedit-changed even if the preedit text did
not actually change, causing text views to scroll.

GNOME/gtk#132
GNOME/gtk!83 (comment 93411)

Fix imwayland crashes

See merge request GNOME/gtk!89

This was missed from the commit that dropped other mentions to the
previous ability to superimpose text.

https://bugzilla.gnome.org/show_bug.cgi?id=748784

so we match on diacritics (eg. accented letters) and also
search on text tokens. As a plus we also reduce code size.

https://bugzilla.gnome.org/show_bug.cgi?id=745128

If GtkExpander:sensitive was FALSE, the arrow still got the normal fg
colour, which made it look clickable, in contrast to the adjacent label.
Fix this by adding selectors to catch the applicable :disabled states.

Note: Needing these may indicate an oops in generic styles elsewhere,
but I couldn’t see any, so let’s just get it looking right for now.

GNOME/gtk#146

https://bugzilla.gnome.org/show_bug.cgi?id=792632

https://bugzilla.gnome.org/show_bug.cgi?id=793089