• Remove the box-shadow at the top when the entry is in the foreground
• Bump precedence so that :disabled entries do not have .flat overridden
• Also add :backdrop to stop HCInverse getting a lighter BG in :backdrop
https://bugzilla.gnome.org/show_bug.cgi?id=789733
Move the default pos of the Paned handle to 400px from the left, i.e.
50% of the default width of the window. The previous position at 300px
from left meant the node treeview was too narrow & could easily result
in the (useful) State column not being visible in the case of many
apps. The properties pane doesn't need to be as big as it was anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=788898
The path bar would crash if we disposed it before all pending I/O
operations had finished. Now we remember all the outstanding
operations directly in the GtkPathBarPrivate, and deal with them
consistently.
If the compositor prefers server-side decorations and the client doesn't
customize the title bar, we disable client-side decorations and let the
compositor know. Otherwise, we continue to use client-side decorations.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781909
As documented, GtkAppChooser is "typically [used] for the purpose of
opening a file". However given that applications that support neither
opening files nor URLs are filtered out, the chooser is not actual
useful for any other (atypical) usage. Change that by only applying
the filtering if a content-type was set, and use the full unfiltered
list otherwise.
https://bugzilla.gnome.org/show_bug.cgi?id=789327
The code has been shuffled so GDK_TOUCH_BEGIN results in a
GDK_MOTION_NOTIFY to the new position and a GDK_BUTTON_PRESS on that same
place. This makes pointer emulation consistent with what X11 does. Even
though button presses have x/y arguments, there's code out there relying
on getting prior motion events.
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
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.
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
