Re: Setting the scroll position of a GtkTextView in GtkScrolledWindow after render

[Andri Möll <andri dot ee>]

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