Thanks, both!
While I'm not using GtkSourceView but GtkTextView, given the former
depends on the latter, they're related. Anyway, turns out that
GtkTextView indeed lays its text out asynchronously without any event to
notify when it's done.
I did end up creating a GNOME Discourse topic, too, where I dug into
gtktextview.c and described it at
https://discourse.gnome.org/t/setting-the-scroll-position-of-a-gtktextview-in-gtkscrolledwindow-after-render/745.
Here's what I wrote for the sake of completeness:
Looking into
https://gitlab.gnome.org/GNOME/gtk/blob/3.24.7/gtk/gtktextview.c#L4508,
I can see that it does indeed lay 2000px out at once and does so with
the priority `GTK_TEXT_VIEW_PRIORITY_VALIDATE`
(https://gitlab.gnome.org/GNOME/gtk/blob/3.24.7/gtk/gtktextview.c#L4550).
I can also see `incremental_validate_callback` updates the adjustments
every idle tick until text is laid out. I wonder if through listening
to those updates I can retry setting the scroll position until it
finally sticks. From my initial test check it at least seems the upper
bound of the vertical adjustment is refined downwards. That permits
differentiating incomplete layouts (where my set position doesn't
stick) from an invalid scroll point (where my set position is really
beyond the upper bound). I'll have to play around with this. Feels
like the web where setting the scroll position is quite a challenge. :P
While setting the scroll in an idle callback is possible, it may be more
robust to do so immediately after the adjustments are updated. Then
again, both heavily depend on the implementation details of GtkTextView
and may break anytime GtkTextView's text layout routines are changed.
Andri
On 4/8/19 3:57 PM, Stefan Salewski wrote:
May that be still this old bug:
https://picheta.me/articles/2013/08/gtk-plus--a-method-to-guarantee-scrolling.html
I think in 2015 I was concerned with that bug, and I asked here, no
response. So I had to apply the old fix mentioned in above link for my
Nim editor. Development of GtkSourceView is not very active, so that
bug may still exist. And in case you have not noticed yet, the gtk-list
has basically moved to discourse forum.
On 4/8/19 4:56 PM, Reuben Rissler wrote:
On 04/08/2019 09:07 AM, Andri Möll via gtk-app-devel-list wrote:
Hey,
I can't figure out if it's me or something's amiss. I'm trying to set
the scroll position after rendering a GtkTextView in a
GtkScrolledWindow, but it's reset to a different value, if it works
at all. I've so far tried to set the vertical adjustment value both
after GtkScrolledWindow is mapped or its child (GtkTextView)
size-allocated. When using a GtkListBox instead of a GtkTextView and
setting the adjustment's value on "size-allocate", it works. No such
luck with a GtkTextView, however.
The peculiar thing with the GtkTextView is, while the adjustment
reports its upper bound to be, for example, 588 and its value 0,
immediately after setting it to 493, it reports its value as 11. I
figure "size-allocate" is still the wrong event to use here given the
adjustment is in flux. What would the right path be to consistently
set the scroll position after the first render, and later, after
resetting the GtkTextView's buffer?
You probably are affected by the same problem as
https://stackoverflow.com/questions/48934458/gtk-sourceview-scroll-to-mark-not-working.
Basically, you need to add a timeout (glib_idle_add or so) to allow
all render calculations to be done.
Reuben
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
