Setting the scroll position of a GtkTextView in GtkScrolledWindow after render

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Setting the scroll position of a GtkTextView in GtkScrolledWindow after render

Gtk+ - Apps Dev mailing list
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?

This is on Arch Linux with gtk3 v3.24.7+25+g17665f06e3-1.

Thanks in advance!

Andri

_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Stefan Salewski-2
On Mon, 2019-04-08 at 13:07 +0000, Andri Möll via gtk-app-devel-list
wrote:
> 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

May that be still this old bug:

https://picheta.me/articles/2013/08/gtk-plus--a-method-to-guarantee-scr
olling.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.

_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Reuben Rissler
In reply to this post by Gtk+ - Apps Dev mailing list


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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

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

Gtk+ - Apps Dev mailing list
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list