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!
The border and icon highlight are useful feedback that was defeated by
CSS precedence. It worked for .titlebuttons due to their implementation,
but the same was not true for custom .flat buttons. This makes it so.
https://bugzilla.gnome.org/show_bug.cgi?id=788580
When the window was backdropped, they suddenly regained their border.
This was clearly not intentional or of any practical use to anyone.
Shuffle around some selectors so that the backdrop ones do not override
the flat ones and make the borders magically reappear when backdropped.
Note that, whereas standard titlebuttons get the border on :hover, other
.flat buttons in the headerbar do not. That should probably be fixed too
https://bugzilla.gnome.org/show_bug.cgi?id=788580
…from priv->button. My refactor to g_signal_disconnect_by_data()
included this widget, when I shouldn’t have as both modes use it.
This e.g. broke opening a CB by keyboard that was currently in menu
mode, if it had been in list mode initially (e.g. due to the theme).
Fix by moving to disconnect_by_func() and only removing in each mode’s
destroy() method the signals that it set on the button in its setup().
https://bugzilla.gnome.org/show_bug.cgi?id=788577
