[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Addition to emacsbug.el

From: Jan D.
Subject: Re: Addition to emacsbug.el
Date: Fri, 29 Oct 2004 11:37:26 +0200

For GTK at least some compromise is needed. Some themes have a minimum
size for the thumb.  So if the thumb is at its minimum size
the overscrolling with the thumb shrinking can't happen.

Huh?  Are you sure?  I'd expect that the display-size of the thumb is
"unrelated" to the size as specified by the C code. What if your document is made of 10 pages and your scrollbar is 40 pixels and your minimum thumb
size is 20 pixels, is GTK going to prevent you from seeing more than
2 pages?

No, but the 9 pages will be scrolled in 20 pixels. So no precision scrolling is possible if you have many pages and a small window. It is the same for any scroll bar, the minimum size is at least 1 pixel. And if you have a window that is 40 pixels and the buffer is 1000 pages, you have to scroll through 999 pages in 39 pixels. Basically the scroll bar is useless in this situation.

If the shown portion of the buffer is small compared to the total size of the buffer, I think the virtual page behaviour is OK. After all, can you see the difference between a thumb who has a height that is 1/30 of the
window height, or 1/31?

Agreed: the exact size of the thumb doesn't matter that much.

But I can usually still see whether the thumb is "at the bottom" or whether there's still one or 2 pixels left, so as long as 1 pixels represents about
20 lines the difference is "relevant" (i.e. 20 lines =~ 500 chars =>
a buffer of about 500B * 1000 pixels = 500KB for my typical frames).

By "relevant" I don't mean important, but just that it's not 100%
negligeable. I could probably happily live with the "virtual extra page"
for buffers as small as 50KB.

I haven't really tested to see where the threshold is for me, but I think
that sounds reasonable.

Otherwise we should do something else, be it your solution or the thumb
shrinking one.

I don't know what is the "thumb shrinking" solution.

I described previously in

To change the thumb size means fiddling with the page size and the maximum values for the scroll bar. Relating values back to a buffer position then becomes so much harder. Not impossible, but certainly a lot of testing
needs to be done.

Hmm... I'll trust you on that one because I obviously don't understand
the difficulty: the way the xterm.c code uses SB_MAX or equivalent as the "maximum value" it would work exactly the same whether SB_MAX is a constant
or not.

If I change the maximum value, the thumb size changes. I then also have to
adjust the value otherwise the thumb changes position.  Also, page_size
page_increment and step_increment has to be changed.  Obviously this
is no more than to find a suitable algorithm, but the bad thing is that
the thumb almost always jump a bit when these values are changed.

There is another thing I noticed about your patch. If the buffer contains three lines and the window is 34 lines, the thumb covers the whole window. Now, if I start to scroll down putting the pointer somewhere at the top of the thumb, I'll have to move down to half the window before one line is actually scrolled. Then down to 3/4 before the second line is scrolled
and finally to the bottom to get the third line to scroll.

Now, if I start with the pointer near the bottom of the thumb, the two
first lines are scrolled just by moving the pointer one pixel.

I think the amount you move the pointer should determine how many lines
are scrolled, not where you happen to put the pointer when you start.
Also, the amount to move for scrolling one line should be the same
regardless of the size of the buffer or the amount show.

Well, obviously this actually depends on the toolkit in use (in Xaw3d, the thumb is always moved to the mouse pointer during grab, so the position of the mouse pointer is what matters, rather than the distance you move it).
What toolkit were you using in the above described case?
My patch is only really tested with Xaw3d.

I used Xaw3d. The point that bothered me is if I have to pages in a buffer,
scrolling three lines involves a small mouse movement.  If I have three
lines in the buffer, scrolling three lines involves a very big mouse
movement, even if I start with the mouse pointer in the same place in
both cases.

The code shared is smaller than the code that differs, so I really don't
see the point.  But if the shared code could go into a function of its
own that would make sense.  For GTK it was convinient to have all code
that modifies the scroll bars in one file when changes had to be done.

Well, I was hoping the code that differs could be reduced further (I didn't have GTK installed when I did the merge, so I didn't get to check whether it compiled, and I haven't tried to change the code to adapt to the "squash
thumb to 0-size during drag" to GTK: this change has reduced the
code-difference between Xaw3d and Motif (and non-toolkit) to one or two
lines only, so I'm hoping something similar can happen with GTK).

Actually it didn't compile, but there where minor tweaks (I think
it was that you called a static function in gtkutil.c from xterm.c).

Anyway, the GTK code section in your part is basically the functional equivalent what motif calls XmScrollBarSetValues. Unfortunately, GTK has nothing similar. So we could still keep that part in gtkutils.c and call it xg_scroll_bar_set_values or something.

        Jan D.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]