Scrollbars on GTK.

Scrollbars on GTK.

[Óscar Fuentes]

My emacs is

GNU Emacs 23.0.60.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.9) of
2008-10-23 on qcore

The vertical scrollbar is a poor indication of the view position on the
buffer. For instance, I'm looking at a buffer that shows all the text
except for the last two lines; the thumb's height covers less than half
the space occupied by the scroll bar and it is on the highest
position. If I move the point to the end of the buffer, the thumb moves
a bit down but still it's lower end is mid way to the bottom of the
scrollbar.

In MS Windows, the thumb size and position on a scrollbar gives a much
more accurate idea of the text length and the point's position within
the buffer.

-- 
Oscar

Re: Scrollbars on GTK.

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> The vertical scrollbar is a poor indication of the view position on the
> buffer. For instance, I'm looking at a buffer that shows all the text
> except for the last two lines; the thumb's height covers less than half
> the space occupied by the scroll bar and it is on the highest
> position. If I move the point to the end of the buffer, the thumb moves
> a bit down but still it's lower end is mid way to the bottom of the
> scrollbar.

It's because the gtk scrollbar isn't flexible enough to cope with all
the possibilities allowed by emacs' text display.

The main issue, AIUI, is that the gtk scrollbar mechansim _assumes_ that
"end of buffer" is always at the bottom of the window (except when
that's impossible, such as a document smaller than the window), but
emacs allows the end-of-buffer point to be positioned anywhere in the
window.  So to allow users full flexibility in positioning, emacs
defines a sort of "overshoot" area past the end of the document.

-Miles

-- 
Egotist, n. A person of low taste, more interested in himself than in me.

Re: Scrollbars on GTK.

[Óscar Fuentes]

Miles Bader <miles@gnu.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>> The vertical scrollbar is a poor indication of the view position on the
>> buffer. For instance, I'm looking at a buffer that shows all the text
>> except for the last two lines; the thumb's height covers less than half
>> the space occupied by the scroll bar and it is on the highest
>> position. If I move the point to the end of the buffer, the thumb moves
>> a bit down but still it's lower end is mid way to the bottom of the
>> scrollbar.
>
> It's because the gtk scrollbar isn't flexible enough to cope with all
> the possibilities allowed by emacs' text display.

[snipped detailed explanation]

Thanks. Almost none of the apps I use are based on GTK and I was
wondering if this behaviour shows a limitation in Emacs or in GTK.

Is this problem present in all the other X toolkits supported by Emacs?

-- 
Oscar

Re: Scrollbars on GTK.

[Stefan Monnier]

> The main issue, AIUI, is that the gtk scrollbar mechansim _assumes_ that
> "end of buffer" is always at the bottom of the window (except when
> that's impossible, such as a document smaller than the window), but
> emacs allows the end-of-buffer point to be positioned anywhere in the
> window.

If it was just that it'd be OK.  But the problem is that Emacs doesn't
know the "document size" other than in units that can change as you
scroll (e.g. in number of chars), so the thumb size needs to be able to
change as you drag it, otherwise it might hit the bottom of the
scrollbar before you really hit the bottom of the buffer.

I've tried many different ways to cope with the problem, but I still
haven't found one that I really like (other than the ones that remove
the stupid dogmatic "we know better" limitation in the toolkits, of
course.  I say "stupid" and "dogmatic" because in most cases these
limitations require extra code in the toolkit, whose sole benefit is to
try to confine the toolkit users into the narrow mindset of the toolkit
maintainers).

One of the least bad solutions IMO is to set the thumbsize to 0 just
before drag-scrolling and reset it to the right size once the scroll
is over.  This way, it seems to work perfectly except for the fact that
the thumb size acts weird during the scroll itself (but people
sometimes already find it odd for the thumb to change size during
scroll, so even the perfect solution has a similar surprise factor).
I'd be happy to use this hack rather than the current one, but last time
I suggested it, it wasn't well received.


        Stefan

Re: Scrollbars on GTK.

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

[snip]

> One of the least bad solutions IMO is to set the thumbsize to 0 just
> before drag-scrolling and reset it to the right size once the scroll
> is over.  This way, it seems to work perfectly except for the fact that
> the thumb size acts weird during the scroll itself (but people
> sometimes already find it odd for the thumb to change size during
> scroll, so even the perfect solution has a similar surprise factor).
> I'd be happy to use this hack rather than the current one, but last time
> I suggested it, it wasn't well received.

I'm seeing the thumb size change effect you describe while reading your
message with Gnus on Windows. Yes, it is odd, but much better than GTK,
because it gives a more accurate idea of where the point is relative to
the buffer length (thumb position) and of the buffer number of lines
(thumb size). It is far from exact, but at least it indicates that the
last line is visible.

-- 
Oscar

Re: Scrollbars on GTK.

[Miles Bader]

Óscar Fuentes <ofv@wanadoo.es> writes:
> Thanks. Almost none of the apps I use are based on GTK and I was
> wondering if this behaviour shows a limitation in Emacs or in GTK.
>
> Is this problem present in all the other X toolkits supported by Emacs?

No.

-Miles

-- 
You can hack anything you want, with TECO and DDT.

Re: Scrollbars on GTK.

[Jan D.]

Óscar Fuentes skrev:
> Miles Bader <miles@gnu.org> writes:
> 
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>> The vertical scrollbar is a poor indication of the view position on the
>>> buffer. For instance, I'm looking at a buffer that shows all the text
>>> except for the last two lines; the thumb's height covers less than half
>>> the space occupied by the scroll bar and it is on the highest
>>> position. If I move the point to the end of the buffer, the thumb moves
>>> a bit down but still it's lower end is mid way to the bottom of the
>>> scrollbar.
>> It's because the gtk scrollbar isn't flexible enough to cope with all
>> the possibilities allowed by emacs' text display.
> 
> [snipped detailed explanation]
> 
> Thanks. Almost none of the apps I use are based on GTK and I was
> wondering if this behaviour shows a limitation in Emacs or in GTK.

It is not a limitation per se, but it has been descided that Emacs shall 
have the ability to scroll end of buffer to the top of the window with 
the scroll bar.  That means tha Emacs differs from practically all apps, 
GTK or not.

> 
> Is this problem present in all the other X toolkits supported by Emacs?
> 

More or less.  I think the native scroll bar handles this best.  Hardly 
surprising as the native scroll bar does not have any tool kit 
limitations.  AFAIK, most apps don't see this as a limitation, rather a 
normal behaviour.  I have not seen any app apart from Emacs where thumb 
at the bottom does not mean end of buffer at end of window and no more 
downwards scrolling possible.

	Jan D.

Re: Scrollbars on GTK.

[Andreas Schwab]

"Jan D." <jan.h.d@swipnet.se> writes:

> I have not seen any app apart from Emacs where thumb at the bottom
> does not mean end of buffer at end of window and no more downwards
> scrolling possible.

gvim shows exactly the same behaviour.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Scrollbars on GTK.

[Stefan Monnier]

> It is not a limitation per se, but it has been descided that Emacs shall
> have the ability to scroll end of buffer to the top of the window with the
> scroll bar.  That means tha Emacs differs from practically all apps, GTK
> or not.

Actually, this is only indirectly related to the problem at hand.
We could "easily" prevent scrolling past the "EOB=EOW", but that
wouldn't help fixing the problem at hand.

>> Is this problem present in all the other X toolkits supported by Emacs?
> More or less.  I think the native scroll bar handles this best.

The Xaw toolkit works just fine with it.  The Xaw3d is somewhat
incompatible, but recent versions can be made to work well as well.


        Stefan

Re: Scrollbars on GTK.

[Jan D.]

Andreas Schwab skrev:
> "Jan D." <jan.h.d@swipnet.se> writes:
> 
>> I have not seen any app apart from Emacs where thumb at the bottom
>> does not mean end of buffer at end of window and no more downwards
>> scrolling possible.
> 
> gvim shows exactly the same behaviour.
> 

Indeed it does.  It seems at is uses the same technique as Emacs, i.e. 
adds a virtual page to the end of the scrolling range.  It has one 
advantage, it counts lines.

	Jan D.

Re: Scrollbars on GTK.

[Jan D.]

Stefan Monnier skrev:
>> It is not a limitation per se, but it has been descided that Emacs shall
>> have the ability to scroll end of buffer to the top of the window with the
>> scroll bar.  That means tha Emacs differs from practically all apps, GTK
>> or not.
> 
> Actually, this is only indirectly related to the problem at hand.
> We could "easily" prevent scrolling past the "EOB=EOW", but that
> wouldn't help fixing the problem at hand.

Not fully, no.  Until Emacs starts counting pixels, the thumb will 
always be off a bit from the expected position.  But turning off 
"overscroll" helps a bit.  The W32 scroll bar doesn't seem to do 
overscroll in Emacs (22.3 from ftp.gnu.org).


	Jan D.

Re: Scrollbars on GTK.

[Óscar Fuentes]

"Jan D." <jan.h.d@swipnet.se> writes:

> Not fully, no.  Until Emacs starts counting pixels, the thumb will
> always be off a bit from the expected position.  But turning off
> "overscroll" helps a bit.  The W32 scroll bar doesn't seem to do
> overscroll in Emacs (22.3 from ftp.gnu.org).

On Windows, CVS Emacs overscrolls if you keep pressing the down arrow on
the vertical scrollbar when the thumb is at the bottom. The thumb turns
smaller as the overscroll happens.

-- 
Oscar

Re: Scrollbars on GTK.

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> On Windows, CVS Emacs overscrolls if you keep pressing the down arrow on
> the vertical scrollbar when the thumb is at the bottom. The thumb turns
> smaller as the overscroll happens.

That's how the Xaw3d scrollbar works as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Scrollbars on GTK.

[Ralf Angeli]

* Jan D. (2008-11-03) writes:

> I have not seen any app apart from Emacs where thumb 
> at the bottom does not mean end of buffer at end of window and no more 
> downwards scrolling possible.

I've seen overscrolling in Word as well, but only in the "normal" view
mode, not in the "page layout" view mode (or whatever it is called).

-- 
Ralf

Re: Scrollbars on GTK.

[Richard M. Stallman]

    The main issue, AIUI, is that the gtk scrollbar mechansim _assumes_ that
    "end of buffer" is always at the bottom of the window (except when
    that's impossible, such as a document smaller than the window), but
    emacs allows the end-of-buffer point to be positioned anywhere in the
    window.  So to allow users full flexibility in positioning, emacs
    defines a sort of "overshoot" area past the end of the document.

This issue comes up over and over.  I wonder if there is a place
we can put an explanation so that people will see it instead of
asking about the issue again.

Re: Scrollbars on GTK.

[Eli Zaretskii]

> From: "Richard M. Stallman" <rms@gnu.org>
> Date: Mon, 03 Nov 2008 14:41:16 -0500
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> I wonder if there is a place we can put an explanation so that
> people will see it

On the scrollbar?

Re: Scrollbars on GTK.

[Richard M. Stallman]

    > I wonder if there is a place we can put an explanation so that
    > people will see it

    On the scrollbar?

There is no room for an explanation in the scroll bar.
(Besides which, you can see by experiment what it does.)

I mean an explanation in the code.

Re: Scrollbars on GTK.

[bqa01573]

How in this?

--- ./src/gtkutil.c.orig        2008-01-10 21:16:15.000000000 +0900
+++ ./src/gtkutil.c     2009-02-11 22:44:06.000000000 +0900
@@ -3261,14 +3261,6 @@

       adj = gtk_range_get_adjustment (GTK_RANGE (wscroll));

-      /* We do the same as for MOTIF in xterm.c, assume 30 chars per line
-         rather than the real portion value.  This makes the thumb less
likely
-         to resize and that looks better.  */
-      portion = WINDOW_TOTAL_LINES (XWINDOW (bar->window)) * 30;
-      /* When the thumb is at the bottom, position == whole.
-         So we need to increase `whole' to make space for the thumb.  */
-      whole += portion;
-
       if (whole <= 0)
         top = 0, shown = 1;
       else

-- 
View this message in context: http://www.nabble.com/Scrollbars-on-GTK.-tp20294444p21956186.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Scrollbars on GTK.

[Jan Djärv]

It removes overscrolling, so it is not an option.

	Jan D.


bqa01573 skrev:
> How in this?
> 
> --- ./src/gtkutil.c.orig        2008-01-10 21:16:15.000000000 +0900
> +++ ./src/gtkutil.c     2009-02-11 22:44:06.000000000 +0900
> @@ -3261,14 +3261,6 @@
> 
>        adj = gtk_range_get_adjustment (GTK_RANGE (wscroll));
> 
> -      /* We do the same as for MOTIF in xterm.c, assume 30 chars per line
> -         rather than the real portion value.  This makes the thumb less
> likely
> -         to resize and that looks better.  */
> -      portion = WINDOW_TOTAL_LINES (XWINDOW (bar->window)) * 30;
> -      /* When the thumb is at the bottom, position == whole.
> -         So we need to increase `whole' to make space for the thumb.  */
> -      whole += portion;
> -
>        if (whole <= 0)
>          top = 0, shown = 1;
>        else
>