Re: gtk scroll bar deficiency

Re: gtk scroll bar deficiency

[grischka]

> > is this change intentional?
> > it looks like a bug to me...

> I'm pretty sure it's intentional. It's not perfect, but the perfect 
> behavior (which you get with the non-toolkit build) tends to be difficult 
> to get with current toolkits because toolkit writers are boneheaded: they 
> prevent applications from doing some very useful things in order to force 
> them into a predefined mould which of course doesn't fit all.

Cheap propaganda. The truth is that current emacs' idea of scrolling 
is just too simple minded than that it could drive a standard scrollbar 
correctly. 

> PS: Basically, they want to enforce limitations of the physical metaphor,
> rather than let people benefit from the fact that it's only a metaphor and
> thus doesn't need to suffer from the same limits. 

Only that the limitations which you complain are part of the means by 
which the metaphor is created in the first place. It's like with a game 
and its rules. The game doesn't "suffer" from the rules, the game is 
the rules. 

> Soon they'll ask for mouses with feedback so the user has to make 
> a physical effort proportional to the size of the text/window when 
> sliding the thumb. Next thing you know, the scrollbars will wear out 
> and will need regular maintenance so they don't get wedged.

Uh, do I live in future? Emacs' bars _were_ wedged last I tried :)

-- grischka

Re: gtk scroll bar deficiency

[Thien-Thi Nguyen]

() "grischka" <grishka@gmx.de>
() Thu, 14 Jun 2007 10:52:33 +0200

   Cheap propaganda. The truth is that current emacs' idea of
   scrolling is just too simple minded than that it could drive a
   standard scrollbar correctly.

perhaps if you change the first "." to a ":", you will have a point.

   Only that the limitations which you complain are part of the
   means by which the metaphor is created in the first place.

i think the point is that a different metaphor pleases other
people.  if the mechanisms that support your preferred metaphor
cannot support another, that is a deficiency in the generality of
those mechanisms.

"but they were not designed to be general."

art of design is finding balance between undesired (maintenance
burden) and desired (customizable) generality.  it is ok to be
artistically deficient (most of us are so by default!), but there
is no escaping the art critics -- they are everywhere.

thi

Re: gtk scroll bar deficiency

[grischka]

> i think the point is that a different metaphor pleases other
> people.  if the mechanisms that support your preferred metaphor
> cannot support another, that is a deficiency in the generality of
> those mechanisms.
> 
> "but they were not designed to be general."
> 
> art of design is finding balance between undesired (maintenance
> burden) and desired (customizable) generality.  it is ok to be
> artistically deficient (most of us are so by default!), but there
> is no escaping the art critics -- they are everywhere.
> 
> thi

Simple and clear does not mean artistically deficient. Often the
contrary is true. I personally think the GUI designers knew what 
they were doing. Nobody wants to see the same scrollbars behave 
differently in every other application.

Why not be realistic? Do you think scrollbar toolkits will change 
anytime near in the future? If not, what is the point to spend 
time in nagging at other peoples decisions.

In the meantime, whats with emacs scrolling through inlined 
images, varying fontheights, etc. Sooner or later you will need 
a better internal infrastructure, and once you have it driving 
the standard scrollbars will be no problem at all, either.

-- grischka

Re: gtk scroll bar deficiency

[grischka]

> > Cheap propaganda. The truth is that current emacs' idea of scrolling 
> > is just too simple minded than that it could drive a standard scrollbar 
> > correctly. 

> Cheap troll.  [Surely you can do better than that?]

> -miles

Yep, sorry, bad education. 

Anywho, for the records, this thread started with an user 
reporting that in recent emacs scrolling down on the last 
page ends up with an empty window which he summarized as:
    "it looks like a bug to me..."

This user then could learn that it's not emacs' fault but
    "...because toolkit writers are boneheaded"
and anyway it is his
    "...kind of wrong question that leads to the arbitrary 
     braindead limitations in current GUI toolkits."

Now I don't mind clear statements, I just was trying to point 
out that these are essentially incorrect. [was this good?]

Fact is that the toolkits don't enforce neither the one nor
the other behaviour, but also that no scrollbar toolkit ever 
will magically be able to adjust for the last line of the file 
to stay on bottom of the window if the editor machinery can't 
tell in advance (!) where in the file the last page starts. 

--- grischka

Re: gtk scroll bar deficiency

[David Reitter]

On 14 Jun 2007, at 18:21, grischka wrote:

>  Fact is that the toolkits don't enforce neither the one nor
> the other behaviour, but also that no scrollbar toolkit ever
> will magically be able to adjust for the last line of the file
> to stay on bottom of the window if the editor machinery can't
> tell in advance (!) where in the file the last page starts.

And similarly, keeping the editor at a constant size is pretty much  
impossible when the total number of lines in a buffer is unknown.  
That is, of course, very confusing to many users who consider  
switching to Emacs from another editor. To them, the vertical scroll- 
bar has to do with the vertical position in the buffer and the  
vertical dimensions of the window and the buffer. (The horizontal  
scroll-bar, if necessary, handles the horizontal dimensions.) The  
number of characters on each line and shown in the window isn't  
really perceptually salient.

That's something that has been discussed earlier, and it hasn't been  
solved, which was fine when 22.1 was overdue. But now it would be  
nice to have the number of lines available. For the scroll-bar, a  
reasonable estimate would do the job (count line lengths in various  
randomly sampled portions of the buffer if the buffer is big): the  
scroll-bar is a visual tool and not an exact science. The number of  
characters on the last page(s) may need to be precisely determined,  
though

Re: gtk scroll bar deficiency

[Jason Rumney]

David Reitter wrote:
> For the scroll-bar, a reasonable estimate would do the job (count line
> lengths in various randomly sampled portions of the buffer if the
> buffer is big): the scroll-bar is a visual tool and not an exact science.

An reasonable estimate is what we have now. If the estimate is wrong,
then the results are one of:
  * User can't scroll to the bottom of the buffer - looks like a bug.
  * Scrolling jumps near the bottom of the buffer because we tried to
fix the above bug.
  * Scrollbar thumb size changes as you scroll, because we tried to fix
the first bug a different way.
  * Scrolling overshoots because we let the bottom of the buffer scroll
to the top of the screen to avoid the above bugs (current behaviour).


The only way to improve on that reasonable estimate is to do an exact
calculation - which requires pre-rendering the entire buffer to figure
out where lines need to wrap, and how tall each line needs to be.

Re: gtk scroll bar deficiency

[grischka]

David Reitter wrote:
> And similarly, keeping the editor at a constant size is pretty much  
> impossible when the total number of lines in a buffer is unknown.  
> That is, of course, very confusing to many users who consider  
> switching to Emacs from another editor. To them, the vertical scroll- 
> bar has to do with the vertical position in the buffer and the  
> vertical dimensions of the window and the buffer. 

Yes. It's a matter of feedback between hand and eye that you want
mouse-movements to be consistent with the text-flow in the window. 
You can get over minor flaws, but it still feels incomfortable. 

> For the scroll-bar, a  
> reasonable estimate would do the job (count line lengths in various  
> randomly sampled portions of the buffer if the buffer is big): the  
> scroll-bar is a visual tool and not an exact science. The number of  
> characters on the last page(s) may need to be precisely determined,  
> though

Basically, an estimation over the file and an accurate calculation 
on the last page. I think it should work.

Jason Rumney wrote:
> An reasonable estimate is what we have now. If the estimate is 
> wrong, then the results are one of: 

...(several bugs)

Well, it should not result in bugs. I'm rather shure you have 
just overlooked something.

What you do and how you do it depends on what you want, 
in the first place:

(1) keep the character-based scrolling as is, that means put up 
    with the inconsistent behaviour with vertical dimension 
    movements as David pointed out above.

(2) switch to line-based scrolling, that means much better behaviour 
    except in areas with images or diverging font-heights, but
    even then better than with (1)

(3) switch to pixel-based scrolling, that means flawless behaviour, 
    but it could be expensive.

All of (1-3) should work buglessly but within the limitations of 
the approach of course.

Both (1) and (2) might need bits of (3), i.e. to calculate 
the start of the last page.

--- grischka

Re: gtk scroll bar deficiency

[Stefan Monnier]

> (1) keep the character-based scrolling as is, that means put up 
>     with the inconsistent behaviour with vertical dimension 
>     movements as David pointed out above.

The only cases where the "inconsistency" of the behavior is notable and
where line-based counting would fare better is when you have a page full of
empty lines mixed with other part full of long dense lines.  This is
extremely rare.

Instead, the "inconsistent" behavior is more commonly due to images
(scrolling images is currently poorly supported under Emacs) or to
invisible text.

But feel free to try and write a patch to count based on lines and let other
people try it.


        Stefan

Re: gtk scroll bar deficiency

[grischka]

> The only cases where the "inconsistency" of the behavior is notable and
> where line-based counting would fare better is when you have a page full of
> empty lines mixed with other part full of long dense lines.  This is
> extremely rare.

This would then be a rare case where it is extremely notable.  

> Instead, the "inconsistent" behavior is more commonly due to images
> (scrolling images is currently poorly supported under Emacs) or to
> invisible text.
> 
> But feel free to try and write a patch to count based on lines
> and let other people try it.
>
>         Stefan

Shure, but you might want to make people happy with your own 
metaphores, not with someone else's. 

--- grischka

Re: gtk scroll bar deficiency

[Stefan Monnier]

> Anywho, for the records, this thread started with an user
> reporting that in recent emacs scrolling down on the last
> page ends up with an empty window which he summarized as:
>     "it looks like a bug to me..."

Nice try.  Go read the actual original message.
It's got nothing to do with "ends up with an empty window", but rather with
the size and position of the thumb.

The "ends up with an empty window" is a debatable feature which we could
change without too much difficulty and is unrelated to scrollbars
and toolkits.

The size and position of the thumb is a bug.  But it's a bug which is only
present with some toolkits because those toolkits make it particularly
difficult for Emacs to do it right.  So difficult that nobody has been able
to do it yet.  For Xaw3d I tried to do it in Emacs, with lots of work I got
a very mixed result.  Then I turned to the Xaw3d code and I fixed the whole
thing by removing three lines (lines which are absent from Xaw, I should
mention).  Gtk/Motif and other toolkits enforce similar constraints for no
technical reasons: just ideological ones.  If these ideological reasons had
to do with freedom and ethics, I could respect them, but GUI-dogma is not
something for which I have any respect.  Sorry.


        Stefan

Re: gtk scroll bar deficiency

[grischka]

> The size and position of the thumb is a bug.  But it's a bug which is only
> present with some toolkits because those toolkits make it particularly
> difficult for Emacs to do it right.  So difficult that nobody has been able
> to do it yet.  

Cool, like in 'Sleeping Beauty'. Who is going to kiss the lady?

> For Xaw3d I tried to do it in Emacs, with lots of work I got
> a very mixed result.  Then I turned to the Xaw3d code and I fixed 
> the whole thing by removing three lines (lines which are absent 
> from Xaw, I should mention). Gtk/Motif and other toolkits enforce 
> similar constraints for no technical reasons: just ideological ones. 

Maybe your overestimating. It wasn't likely done to make your life 
harder or anyone's.

> If these ideological 
> reasons had to do with freedom and ethics, I could respect them, 
> but GUI-dogma is not something for which I have any respect.  Sorry.
> 
>         Stefan

Come on, it's not GUI-dogma. It's just that they want their 
work of art to look exactly the same on everyone's computer.

--- grischka

Re: gtk scroll bar deficiency

[Stefan Monnier]

> Maybe you'r overestimating.  It wasn't likely done to make your life 
> harder or anyone's.

I originally thought it was lack of imagination, but given that they reject
requests to lift the restriction by arguing that "this is not supported by
our metaphor", it's pretty clear that it's ideological.

> Come on, it's not GUI-dogma.  It's just that they want their 
> work of art to look exactly the same on everyone's computer.

Huh?  We're not talking about different computers.  We're not talking about
visual appearance.  And they don't seem bothered by themes.  So, no, you're
100% deluded.


        Stefan

Re: gtk scroll bar deficiency

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Monnier wrote:
> 
> I originally thought it was lack of imagination, but given that they reject
> requests to lift the restriction by arguing that "this is not supported by
> our metaphor", it's pretty clear that it's ideological.

this is confusing.
Emacs is their major customer (arguably the most important one,
definitely one of the 10 most important ones).
VIM suffers from the same deficiency, so I guess its maintainers are
with us on this matter.
What happened to "customer is king"?
Does gtk use bugzilla?  How about you file a bug report (+ the 3 line
patch you mention) and we all vote for it?

BTW, does Qt has the same bug?

Thanks.
Sam.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGcrbHPp1Qsf2qnMcRAnSlAJ9xvbkmwa/Chg7RUQ1xFkdI8Jab5QCdHXuq
SMPqKepUADyi0e62WhrlIX8=
=naf6
-----END PGP SIGNATURE-----

Re: gtk scroll bar deficiency

[Stefan Monnier]

>> I originally thought it was lack of imagination, but given that they reject
>> requests to lift the restriction by arguing that "this is not supported by
>> our metaphor", it's pretty clear that it's ideological.

> Emacs is their major customer (arguably the most important one,
> definitely one of the 10 most important ones).

You clearly don't live in the same world as they do.


        Stefan

Re: gtk scroll bar deficiency

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Monnier wrote:
>>> I originally thought it was lack of imagination, but given that they reject
>>> requests to lift the restriction by arguing that "this is not supported by
>>> our metaphor", it's pretty clear that it's ideological.
> 
>> Emacs is their major customer (arguably the most important one,
>> definitely one of the 10 most important ones).
> 
> You clearly don't live in the same world as they do.

Then they live in a dream world and we should wake them up.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGcuFIPp1Qsf2qnMcRAltYAJ9S495Uu5fBH0AIjt6D4W3pw5HTfwCfRzTl
UzPj6q8OqsnXPwTzXaHKEpE=
=yfYY
-----END PGP SIGNATURE-----

Re: gtk scroll bar deficiency

[Miles Bader]

"grischka" <grishka@gmx.de> writes:
> Cheap propaganda. The truth is that current emacs' idea of scrolling 
> is just too simple minded than that it could drive a standard scrollbar 
> correctly. 

Cheap troll.  [Surely you can do better than that?]

-miles

-- 
I'd rather be consing.

gtk scroll bar deficiency

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just built emacs with gtk for the first time and I was struck by the
change in the scroll bar behavior (specifically, the location of the
sliding "scroll thing" - what is its official name anyway?).

before: when the whole buffer is visible, the scroll thing in the bar
occupies the whole scroll bar (clearly indicating that everything is
visible); when the bottom of the buffer is visible, the scroll thing is
at the bottom of the scroll bar. this is also the behavior of gedit,
firefox, openoffice, gnumeric et al, and I like it.

now: when the whole buffer is visible (more generally, when the bottom
is visible), the scroll thing does not reach the bottom of the scroll
bar - you can scroll down and, as the bottom of the buffer scrolls up,
the scroll thing reaches the bottom of scroll bar (while decreasing in
its size). this is the behavior of vim, and I hate it.

is this change intentional?
it looks like a bug to me...

Sam.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbY8GPp1Qsf2qnMcRAlWxAKCtH/Daxbc4oT15xrYNDzk4dP0HnACgiAID
BX5uId3+MKsVg4fInP3Yvas=
=pujF
-----END PGP SIGNATURE-----

Re: gtk scroll bar deficiency

[Stefan Monnier]

> I just built emacs with gtk for the first time and I was struck by the
> change in the scroll bar behavior (specifically, the location of the
> sliding "scroll thing" - what is its official name anyway?).

Some toolkits call it the "thumb".

> before: when the whole buffer is visible, the scroll thing in the bar
> occupies the whole scroll bar (clearly indicating that everything is
> visible); when the bottom of the buffer is visible, the scroll thing is
> at the bottom of the scroll bar. this is also the behavior of gedit,
> firefox, openoffice, gnumeric et al, and I like it.

> now: when the whole buffer is visible (more generally, when the bottom
> is visible), the scroll thing does not reach the bottom of the scroll
> bar - you can scroll down and, as the bottom of the buffer scrolls up,
> the scroll thing reaches the bottom of scroll bar (while decreasing in
> its size). this is the behavior of vim, and I hate it.

> is this change intentional?
> it looks like a bug to me...

I'm pretty sure it's intentional.  It's not perfect, but the perfect
behavior (which you get with the non-toolkit build) tends to be difficult to
get with current toolkits because toolkit writers are boneheaded: they
prevent applications from doing some very useful things in order to force
them into a predefined mould which of course doesn't fit all.


        Stefan


PS: Basically, they want to enforce limitations of the physical metaphor,
rather than let people benefit from the fact that it's only a metaphor and
thus doesn't need to suffer from the same limits.  Soon they'll ask for
mouses with feedback so the user has to make a physical effort proportional
to the size of the text/window when sliding the thumb.  Next thing you know,
the scrollbars will wear out and will need regular maintenance so they don't
get wedged.

Re: gtk scroll bar deficiency

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Monnier wrote:
>> I just built emacs with gtk for the first time and I was struck by the
>> change in the scroll bar behavior (specifically, the location of the
>> sliding "scroll thing" - what is its official name anyway?).
> 
> Some toolkits call it the "thumb".

thanks.  what is a "slider" (is there such a word?)

>> before: when the whole buffer is visible, the scroll thing in the bar
>> occupies the whole scroll bar (clearly indicating that everything is
>> visible); when the bottom of the buffer is visible, the scroll thing is
>> at the bottom of the scroll bar. this is also the behavior of gedit,
>> firefox, openoffice, gnumeric et al, and I like it.
> 
>> now: when the whole buffer is visible (more generally, when the bottom
>> is visible), the scroll thing does not reach the bottom of the scroll
>> bar - you can scroll down and, as the bottom of the buffer scrolls up,
>> the scroll thing reaches the bottom of scroll bar (while decreasing in
>> its size). this is the behavior of vim, and I hate it.
> 
>> is this change intentional?
>> it looks like a bug to me...
> 
> I'm pretty sure it's intentional.  It's not perfect, but the perfect
> behavior (which you get with the non-toolkit build)

does this mean that you agree that the first behavior is better?

> tends to be difficult to
> get with current toolkits because toolkit writers are boneheaded

somehow gedit got it right - and it appears to be pretty minimalist by
design ("notepad" for gnome).


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbahmPp1Qsf2qnMcRAuGJAKCJy/QMdohVREXeLlVPu4JAkZgT7ACgh9Nt
xwmVaNCGQ3rqGTc5igJo4cA=
=sJFX
-----END PGP SIGNATURE-----

Re: gtk scroll bar deficiency

[Stefan Monnier]

>> Some toolkits call it the "thumb".
> thanks.  what is a "slider" (is there such a word?)

I believe "slider" is an alternative term for the same thing.

>> I'm pretty sure it's intentional.  It's not perfect, but the perfect
>> behavior (which you get with the non-toolkit build)
> does this mean that you agree that the first behavior is better?

Yes, of course.

>> tends to be difficult to get with current toolkits because toolkit
>> writers are boneheaded
> somehow gedit got it right - and it appears to be pretty minimalist by
> design ("notepad" for gnome).

That's the problem: the toolkit only cater to the simple case.  To "do it
right" in Emacs we'd be forced to *render* the whole buffer in order to
compute its total pixel size so as to precisely set the thumb size.
And then we'd still be stuck with the design constraint that you cannot
bring point-max higher than the bottom of the window (a very common
limitation in most other applications, often construed as a feature by
GUI-zealots).

Given that we cannot "do it right" without major performance problems (and
usually this is only due to an over-eager test in the toolkit: fixing the
toolkit in the case of Xaw3d amounts to removing 2-3 lines), we end up
having to choose between various hacks and problems.

Since the problem mostly affects operation when dragging the slider and this
only when the slider gets near the bottom, another solution (which I tend to
prefer) is to set the thumb size to something artificially small (e.g. 0)
during dragging.  This way the thumb size can still be correct at all
other times.


        Stefan

Re: gtk scroll bar deficiency

[Jan Djärv]

Sam Steingold skrev:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stefan Monnier wrote:

>>> before: when the whole buffer is visible, the scroll thing in the bar
>>> occupies the whole scroll bar (clearly indicating that everything is
>>> visible); when the bottom of the buffer is visible, the scroll thing is
>>> at the bottom of the scroll bar. this is also the behavior of gedit,
>>> firefox, openoffice, gnumeric et al, and I like it.
>>> now: when the whole buffer is visible (more generally, when the bottom
>>> is visible), the scroll thing does not reach the bottom of the scroll
>>> bar - you can scroll down and, as the bottom of the buffer scrolls up,
>>> the scroll thing reaches the bottom of scroll bar (while decreasing in
>>> its size). this is the behavior of vim, and I hate it.
>>> is this change intentional?
>>> it looks like a bug to me...
>> I'm pretty sure it's intentional.  It's not perfect, but the perfect
>> behavior (which you get with the non-toolkit build)
> 
> does this mean that you agree that the first behavior is better?
> 
>> tends to be difficult to
>> get with current toolkits because toolkit writers are boneheaded
> 
> somehow gedit got it right - and it appears to be pretty minimalist by
> design ("notepad" for gnome).
> 

Depends on your definition of right.  The purpose is to be able to use the 
scrollbar to get the last line to the top of the window.  Gedit can't do that. 
  This is an Emacs convention, but as said, hard to implement right with 
current toolkits.

But AFAIK, only Emacs does this so most users are surprised.  Maybe we should 
make this customizable.

	Jan D.

Re: gtk scroll bar deficiency

[Ralf Angeli]

* Jan Djärv (2007-06-12) writes:

> Depends on your definition of right.  The purpose is to be able to use the 
> scrollbar to get the last line to the top of the window.  Gedit can't do that. 
>   This is an Emacs convention, but as said, hard to implement right with 
> current toolkits.
>
> But AFAIK, only Emacs does this so most users are surprised.  Maybe we should 
> make this customizable.

Word does it as well, in Normal mode.

-- 
Ralf

Re: gtk scroll bar deficiency

[Jan Djärv]

Ralf Angeli skrev:
> * Jan Djärv (2007-06-12) writes:
> 
>> Depends on your definition of right.  The purpose is to be able to use the 
>> scrollbar to get the last line to the top of the window.  Gedit can't do that. 
>>   This is an Emacs convention, but as said, hard to implement right with 
>> current toolkits.
>>
>> But AFAIK, only Emacs does this so most users are surprised.  Maybe we should 
>> make this customizable.
> 
> Word does it as well, in Normal mode.

Are you talking about MS Word?  The one I have access to (Word 2003) does not. 
  But other versions may, I don't use MS Word alot.

	Jan D.

Re: gtk scroll bar deficiency

[Ralf Angeli]

* Jan Djärv (2007-06-12) writes:

[Overscrolling]

>> Word does it as well, in Normal mode.
>
> Are you talking about MS Word?  The one I have access to (Word 2003) does not. 

I cannot check right now, but I think in my case it is also MS Word
2003.  Are you sure you activated Normal mode?

-- 
Ralf

Re: gtk scroll bar deficiency

[Jan Djärv]

Ralf Angeli skrev:
> * Jan Djärv (2007-06-12) writes:
> 
> [Overscrolling]
> 
>>> Word does it as well, in Normal mode.
>> Are you talking about MS Word?  The one I have access to (Word 2003) does not. 
> 
> I cannot check right now, but I think in my case it is also MS Word
> 2003.  Are you sure you activated Normal mode?
> 

Yes.  What it does is that it scrolls the last page top to the top of the 
window.  If that page is partial, the bottom may end up higher than the bottom 
of the window, but only if the page is just one line can I get the last line 
to the top of the window.  But this is very off topic anyway. :-)

	Jan D.

Re: gtk scroll bar deficiency

[Ralf Angeli]

* Jan Djärv (2007-06-12) writes:

> Ralf Angeli skrev:
>> * Jan Djärv (2007-06-12) writes:
>> 
>> [Overscrolling]
>> 
>>>> Word does it as well, in Normal mode.
>>> Are you talking about MS Word?  The one I have access to (Word 2003) does not. 
>> 
>> I cannot check right now, but I think in my case it is also MS Word
>> 2003.  Are you sure you activated Normal mode?
>
> Yes.  What it does is that it scrolls the last page top to the top of the 
> window.  If that page is partial, the bottom may end up higher than the bottom 
> of the window, but only if the page is just one line can I get the last line 
> to the top of the window.

In my case the last line of the buffer ends up at the top of the window
when dragging the thumb to the bottom or when keeping the down-arrow on
the scroll bar pressed.  So this is exactly the same behavior as with
Emacs.

> But this is very off topic anyway. :-)

I don't think so, because it disproves arguments about that behavior
being too peculiar and uncommon.

-- 
Ralf

Re: gtk scroll bar deficiency

[David Reitter]

Jan Djärv (2007-06-12) writes:

> But AFAIK, only Emacs does this so most users are surprised.  Maybe  
> we should
> make this customizable.

Yes, please. This is strange not just in GTK environments, but also  
on the Mac. It's just not what I would expect as a user.

Re: gtk scroll bar deficiency

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> But AFAIK, only Emacs does this so most users are surprised.

And vi (gvim).

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: gtk scroll bar deficiency

[Jan Djärv]

Andreas Schwab skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> But AFAIK, only Emacs does this so most users are surprised.
> 
> And vi (gvim).
> 

Cool.

	Jan D.

Re: gtk scroll bar deficiency

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Djärv wrote:
> 
> 
> Sam Steingold skrev:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stefan Monnier wrote:
> 
>>>> before: when the whole buffer is visible, the scroll thing in the bar
>>>> occupies the whole scroll bar (clearly indicating that everything is
>>>> visible); when the bottom of the buffer is visible, the scroll thing is
>>>> at the bottom of the scroll bar. this is also the behavior of gedit,
>>>> firefox, openoffice, gnumeric et al, and I like it.
>>>> now: when the whole buffer is visible (more generally, when the bottom
>>>> is visible), the scroll thing does not reach the bottom of the scroll
>>>> bar - you can scroll down and, as the bottom of the buffer scrolls up,
>>>> the scroll thing reaches the bottom of scroll bar (while decreasing in
>>>> its size). this is the behavior of vim, and I hate it.
>>>> is this change intentional?
>>>> it looks like a bug to me...
>>> I'm pretty sure it's intentional.  It's not perfect, but the perfect
>>> behavior (which you get with the non-toolkit build)
>>
>> does this mean that you agree that the first behavior is better?
>>
>>> tends to be difficult to
>>> get with current toolkits because toolkit writers are boneheaded
>>
>> somehow gedit got it right - and it appears to be pretty minimalist by
>> design ("notepad" for gnome).
>>
> 
> Depends on your definition of right.  The purpose is to be able to use
> the scrollbar to get the last line to the top of the window.

why would I want that?!
to have an empty screen?





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbpnIPp1Qsf2qnMcRAsECAJ43SrBDerarsmh7ACQ2VuI9L8+m5QCgnCOd
Ji05dFpAzWwfTqWoYerH7dc=
=zXZM
-----END PGP SIGNATURE-----

Re: gtk scroll bar deficiency

[David Kastrup]

Sam Steingold <sds@podval.org> writes:

>> Depends on your definition of right.  The purpose is to be able to use
>> the scrollbar to get the last line to the top of the window.
>
> why would I want that?!
> to have an empty screen?

Comparing Windows side-by-side requires this, for example.

-- 
David Kastrup

Re: gtk scroll bar deficiency

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Kastrup wrote:
> Sam Steingold <sds@podval.org> writes:
> 
>>> Depends on your definition of right.  The purpose is to be able to use
>>> the scrollbar to get the last line to the top of the window.
>> why would I want that?!
>> to have an empty screen?
> 
> Comparing Windows side-by-side requires this, for example.

ediff is your friend.
(but I see your point...)

nevertheless this result (getting the last line to the top of the
window) should be achievable by clicking on the down arrow at the bottom
of the scrollbar.
the thumb (slider) should indicate the part of the buffer that is
visible in the window.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbp1TPp1Qsf2qnMcRAuBXAJ4uGxX20jjy/VsPQzIl4yB7p74IFgCfRIhU
lBiNc+dbkOjWcftbTXIbfeE=
=nP1e
-----END PGP SIGNATURE-----

Re: gtk scroll bar deficiency

[Stefan Monnier]

> why would I want that?!
> to have an empty screen?

This is the kind of wrong question that leads to the arbitrary braindead
limitations in current GUI toolkits.  The right question would be:

    why would I want to prevent someone from doing that?

after all, nobody forces you to do it.


        Stefan

Re: gtk scroll bar deficiency

[Davis Herring]

>> Some toolkits call it the "thumb".
>
> thanks.  what is a "slider" (is there such a word?)

In my experience, a slider is an almost-ubiquitous control that looks like
this:

  Amount of sliding:
      _
  ---| |-----------------
      V
   |    |    |    |    |
Rubber                Ice

The pentagon can be dragged along the line with the mouse or moved with
keyboard arrows when it has the focus.  It's very similar to a scroll bar
except that the dragger (the thumb) does not have width (it is mounted as
if by a pin to the track) and so is used when a value and not a range (as
of visibility) is being specified.  Sometimes it appears rotated CCW by a
quarter-turn.

Sorry if that's redundant or excessively verbose, but I'm hoping to be
understood regardless of anyone's prior experience.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.