In gtk_tree_view_build_tree with recurse=TRUE, the TEST_EXPAND_ROW
signal might invalidate the child iterator. Getting the iterator after
the signal (instead of before) fixes the issue.
Fixes https://gitlab.com/inkscape/inkscape/-/issues/1879
We want expander arrows to be vertically centered in their row, so we
pass the cell area's height to the renderer.
However, if the cell area's height is an odd number while the
"expander-size" style property is an even number, or vice versa, the
arrow will be centered in a half pixel, and fuzzily rendered.
So, round the render height to the same parity as the expander-size.
(This is not necessary for the arrow width because it's assumed equal
to the "expander-size" style-property.)
An expander arrows's render width is supposed to be derived from the
"expander-size" style property.
However, we are actually rendering it for a width equal to
expander-size + 1. This results in ugly blurry rendering.
There is a comment justifying this "+ 1", which has been there for
almost 2 decades. But the justification doesn't seem to apply to
the current code, so the original motivation is likely obsolete.
Let's remove this "+ 1" to render the arrow to a width exactly equal
to the "expander-size" style property.
This reverts commit d6a29e1b8c.
It fixed blurry rendering of expander arrows.
However, it also introduced a regression in that the arrows are no
longer vertically centered if rows are taller than twice the
expander-size style property.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1464
We need to take the device scale into account, like it is done in
gdkwindow.c.
This fixes wrongly placed DnD surfaces in scaled contexts on X11
as well as Wayland.
We don't need to cover every case with a va_marshaller, but there are a
number of them that are useful because they will often only be connected
to by a single signal handler.
Generally speaking, if I opened into a file to add a va_marshaller, I just
set all of them.
This has caused numerous issues for users, especially in the
filechooser, which have not been fixed in all the years since the pixel
cache has been introduced.
If anyone seriously has complaints about the treeview performance (and
those did not exist with the pixel cache), feel free to revert this
commit *and* fix the pixel cache issues.
Closes#503Closes#1691Closes#466
If the cursor coordinates are outside of the content (the GtkRBTree),
gtk_tree_view_bin_draw() will return and not draw the rubber band
rectangle.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1859
They're either wrong (when using FALSE because the widgets don't account
for changes to the CSS) or unnecessary (when using TRUE because it's the
default).
Fixes!1777
In case the theme doesn't set a height/min-height for the treeview
separator the treeview drawing gets confused and draws rows on top of each
other depending on the redraw area.
This is due to gtk_tree_view_get_row_height() assuming that a node with a
height <= 0 is not set and not a separator and it will default to the
expander size.
Ideally gtk_tree_view_get_row_height() would know if it operates on a separator,
but there are too many calls/levels, so just make sure the separator height
is at least 1 (Adwaita already sets "min-height: 2px", so no change there)
If the column used for the GtkTreeView:tooltip-column contains NULL
we're already skipping a tooltip; let's ignore empty strings as well,
as an empty tooltip is pretty much pointless.
Close#1681
Without enforcement to the expander-size, we can end up rendering icons
rather fuzzy. This uses the expander-size style property to determine
the square for the icon, centered on what was the calculated space for
the expander.
The annotation (allow-none) is wrong. Since
gtk_tree_view_is_blank_at_pos() also calls
gtk_tree_view_get_path_at_pos(), the same fields should have the same
annotations.
The fix for bug 767468 had some unintended side-effects. This is
an attempt at doing the same fix (don't grab focus when we are
grab-shadowed), while avoiding the breakage, by using GTK+'s
internal tracking for grab-shadowed-ness.
https://bugzilla.gnome.org/show_bug.cgi?id=770508
The cellrenderer signals might be taking the grab somewhere else, at which
point it's dubious we should attempt to take the keyboard focus into the
treeview.
This concretely breaks popovers triggered from cellrenderer signals on
button press, because the treeview will attempt to grab focus
inconditionally then.
https://bugzilla.gnome.org/show_bug.cgi?id=767468
gtk_tree_view_get_path_at_pos() mistakenly identifies the first
pixel of all but the first column in a tree view as belonging to
the previous column.
https://bugzilla.gnome.org/show_bug.cgi?id=708148
When starting a rubberband selection from an empty area, we could run
into crashes if the selection moves over the rows and then back out
to unpopulated area. Handle this case without crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=766336
If there was a piece of text in the cell, then when the edit
entry is shown for that cell, it should have a piece of text
in it roughly at the same location.
Therefore, when child widget is enlarged (child preferred
size exceeds cell size), extra width should be added by
extending either left or right edge depending on text direction.
If after that the child sticks outside of the treeivew visible region,
try to push it back inside (breaking its alignment with the
cell), again, giving preference (i.e. adjusting it last)
to either left or right edge depending on text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=765471
It might have changed (eg. after a row being expanded, and the child
rows revalidated), so just update it here based on the last pointer
position.
Based on a patch by Maxim Reznik <reznikmm@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=760891
The pointer position is queried to properly trigger the prelight
updates on the new row below it. We store the last coordinates
though, and track crossing events to unset these, so it's safe
to just update_prelight() here on these.
The search window of a tree view was implemented by showing without
making it visible by by positioning it outside the screen edge. This is
not possible on Wayland, so implement another method for being able to
enter text into a non-visible entry.
The new method is implemented by, before showing the window, pass the
key event directly to the IM context backing the entry. If the key
event triggered the context to commit new text or change the preedit
content, the search window is shown, and from that point the key events
are forwarded directly to the entry widget.
https://bugzilla.gnome.org/show_bug.cgi?id=756780
