[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
http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01300.html
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.
- Addition to emacsbug.el, Jan D., 2004/10/27
- Re: Addition to emacsbug.el, Stefan Monnier, 2004/10/27
- Re: Addition to emacsbug.el, Jan D., 2004/10/27
- Re: Addition to emacsbug.el, Stefan Monnier, 2004/10/27
- Re: Addition to emacsbug.el, Jan D., 2004/10/28
- Re: Addition to emacsbug.el, Stefan, 2004/10/28
- Re: Addition to emacsbug.el,
Jan D. <=
- Re: Addition to emacsbug.el, Jan D., 2004/10/29
- Re: Addition to emacsbug.el, Stefan, 2004/10/29
- Re: Addition to emacsbug.el, Jan D., 2004/10/30
- Re: Addition to emacsbug.el, Stefan, 2004/10/30
- Re: Addition to emacsbug.el, Jan D., 2004/10/30
Re: Addition to emacsbug.el, Richard Stallman, 2004/10/28