What is missing is the "allocation" part of x/y coordinates. Since
gtk_entry_realize doesn't call gtk_widget_set_window(priv->text_area),
the coordinates returned by gdk_window_get_origin don't include it.
This patch fixes this.
https://bugzilla.gnome.org/show_bug.cgi?id=784509
Bug 737175 aimed to ensure that scrolling up on a horizontal range would
result in its value increasing, as that’s what users intuitively expect.
However, its commit 416c370da1 meant that,
if the event gives scroll deltas, we inverted our delta unconditionally.
So it broke horizontal scrolling: scrolling left moved the slider right…
We must only invert if using dy as delta. dx already has the right sign,
so inverting it was wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=788905
If the call to set_parent() failed, we were still adding the child to
the internal list of children, despite that it was not really added.
That meant we could later try to do invalid stuff with that non-child.
Fix that by asserting and giving up if the child that the user is
attempting to add is already parented.
https://bugzilla.gnome.org/show_bug.cgi?id=701296
The language is useful for parsing tools, such as that of gtkmm, which
otherwise assumes these are C snippets and elides them from its
generated documentation.
The old GtkBlah node names are just plain obsolete.
It does not hurt us to keep middle clicks doing the same
as shift-primary clicks. This makes the transition from gtk2
less painful in terms of muscle memory.
https://bugzilla.gnome.org/show_bug.cgi?id=787669
~Company ╡ so TL;DR: we put the static style in the cache, but then
⤷ ╡ compute a child style from the animated style in the cache
⤷ ╡ and we put the child style also in the cache (because
⤷ ╡ it's not animated)
⤷ ╡ then we run the animation, but reuse the cache every time
⤷ ╡ for both child and parent
⤷ ╡ so after the animation is done, we end up with a cache that
⤷ ╡ has the correct static style for the parent but an
⤷ ╡ incorrect static style for the child
⤷ ╡ because that static style was computed from the
⤷ ╡ initial animated style
This fixes https://bugzilla.gnome.org/show_bug.cgi?id=763517
Check UUID for printers obtained via DNSSD whether
they are already installed on local CUPS server.
Don't show such printers.
Not all printers published via DNSSD have UUID entry though.
https://bugzilla.gnome.org/show_bug.cgi?id=786794
We moved from the Ruby compiler to sassc in
commit 67953e9cfb, so this copies across
the updated info about building from GTK+ 4.
Also, explain the purpose of parse-sass.sh, since while that is not
mentioned in GTK+ 4 – and perhaps does not need to be, thanks to Meson –
we are still on Autotools here, and rebuilding the entirety of GTK+ 3 if
you only edited the CSS is a lot of waiting for no good reason.
GtkMenu’s own keynav code, which actually bothers to account for the
layout of items, only happens if columns > 1. So, adding items to 1
column using a reverse loop meant they were placed in the Menu’s list of
children in that order, and because we only have 1 column, Menu passes
keynav up to MenuShell, which doesn’t adjust for the items’ positions.
‘Fix’ that here by adding items in the same order they’ll have when laid
out in the Menu, so keynav does what you’d expect, not the opposite. For
that, it’s simpler just to use gtk_container_add().
Let’s presume users are using add(), attach() with a non-inverted loop,
or attach() with arguments that create 2+ columns and so GtkMenu keynav.
It was selecting paned separator, which means any separator at any level
of descent within a paned, including the toplevel container in GEdit.
We need to be more specific and only select the relevant separator that
is the direct child of the paned. This is what Adwaita does.
https://bugzilla.gnome.org/show_bug.cgi?id=788573
Nulling priv->button in _unset_tree_view() is asymmetrical: we create
it via init(), not _set_tree_view(), so we shouldn’t null in the latter.
Worse, doing so manifests in criticals + a SEGV easily with basic use of
testtreecolumns, removing the TVC from a TV then trying to add it to one
Finally, the wrong null-out meant dispose() failed to unref the button,
so it leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=728452https://bugzilla.gnome.org/show_bug.cgi?id=788614
It was in both [general] with a description and [other] with none.
Leave it in [other] with the other folder- icons, + the description.
bonus: this makes all of [general] fit in our default window size!
