Re: GTK v1.3.2: New text widgets

["J. Ali Harlow" <gtk-list avrc city ac uk>]

On Mon, 08 Jan 2001, Havoc Pennington wrote:
> Hrm, I'm not sure I understand the problem fully or see exactly what
> is going on, but once I do I want to fix it. ;-)

Sounds good to me. How can I help?

> If you call scroll_to_mark() then the adjustment should immediately
> (synchronously) be moved to scroll as requested. It shouldn't go
> through the main loop at all. 
> 
> There may be one problem here involving the main loop. Let me explain
> a bit how the view works; when you modify a line of text, the view
> "invalidates" that line, which means it sets the height of the line to
> zero and schedules an eventual recomputation of the line's height. It
> does this recomputation in an idle handler, which means in gtk_main().

I'm not sure what you class as "modify" here. The problem occurs before
the text buffer exceeds Slash'EM's nominal memory limit and so before any
deletions are triggered. Thus the only modifications to the buffer are
insertions of complete lines at the end of the buffer. Could the problem be
that since the new lines are zero height, the mark (which is just below the new
lines) is considered on-screen?

> During recomputation, if your buffer is big enough you can actually
> see the scroll thumb shrinking as the scrollable area expands.
> However during this process the visible text should stay constant
> (i.e. the top line of the view should remain the same).
> 
> It's possible that scroll_to_mark() while the whole buffer or lots of
> the buffer is invalid doesn't work, because if you have a bunch of
> invalid lines with 0 height, then you can really only scroll before
> all of them or after all of them, and you don't have enough "space" in
> the adjustment. e.g. the range of the adjustment might be from 0 to 1,
> which doesn't give you any precision.
> 
> It doesn't make sense to me that one scroll_to_mark() would work but
> not the following ones; that's kind of weird. I'm having trouble
> coming up with a reason why that happens.

Well it's quite possible that I've misdiagnosed the problem. As I remember,
I initially thought that the problem might be that the mark was considered as
being an infinitely thin line of the full height of the text and so while
the top of the mark was on-screen, the line it was on was not visible. To solve
this imagined problem, I added an extra blank line at the end of the buffer.
Given this extra line, what I might have been seeing was scroll_to_mark()
scrolling to the position of the mark before the insertions, which just
happened to be one line down from where it should have been and so "worked" as
long as only one line was inserted. I can have a play this evening and see if I
can find out more.

> How to fix it... 
> 
> One issue with a "view updated" signal is that the view is updated
> incrementally in a bunch of chunks, not all at once. So I'm not sure
> when to emit this.
> 
> You also want to avoid flashing, i.e. you want the view to come up
> scrolled to the mark the first time, you don't want it to start
> someplace else and then scroll after it updates fully, or something
> like that.

Yup, this would certainly be much better. I'm not sure whether my current
solution is flashing or not, although logically one would expect it to.

> Another option is to make scroll_to_mark() a bit smarter. Instead of
> scrolling immediately, it could store the mark to be scrolled to, and
> only scroll just before drawing to the screen. This is potentially
> unintuitive because you might scroll_to_mark() then delete or move the
> mark; so the widget could add its own internal mark at the same
> position and save that, instead of relying on the passed-in mark.
> 
> This would also allow you to call scroll_to_mark() before the text
> widget is realized/mapped, which might be convenient.
> 
> 
> I'm not sure yet - thanks for doing beta testing though, please
> report any other issues like this.

Only other odd thing I noticed was with the coloured tags that I use. If the
last-but-one line is coloured and I play around with the selection using the
mouse, I can sometimes get the last line to be coloured too (scrolling the line
off-screen and then back on-screen solves the problem). I didn't mention it
because I feared it would cloud the issue and I haven't really had time to
investigate it fully.

Many thanks for your help,

-- 
Ali Harlow                              Email: ali avrc city ac uk
Research programmer                     Tel:   (020) 7477 8000 X 4348
Applied Vision Research Centre          Intl: +44 20 7477 8000 X 4348
City University                         Fax:   (020) 7505 5515
London                                  Intl: +44 20 7505 5515