[9fans] acme scrollbar

[9fans] acme scrollbar

[hiro]

Hi,
The scrollbar handle will always change it's length when moving
through the files.
Why isn't the length based on the total lines of the file?

--
hiro

Re: [9fans] acme scrollbar

[erik quanstrom]

> Hi,
> The scrollbar handle will always change it's length when moving
> through the files.
> Why isn't the length based on the total lines of the file?

because that would require reading the whole file.

- erik

Re: [9fans] acme scrollbar

[Tom Lieber]

On Wed, Jul 2, 2008 at 3:09 PM, hiro <23hiro@googlemail.com> wrote:
> The scrollbar handle will always change it's length when moving
> through the files.
> Why isn't the length based on the total lines of the file?

Its size is proportional to the amount of text currently visible.

--
Tom Lieber
http://AllTom.com/

Re: [9fans] acme scrollbar

[roger peppe]

On Wed, Jul 2, 2008 at 8:13 PM, erik quanstrom <quanstro@coraid.com> wrote:
>> Hi,
>> The scrollbar handle will always change it's length when moving
>> through the files.
>> Why isn't the length based on the total lines of the file?
>
> because that would require reading the whole file.

actually, acme does read the whole file.

but if the scrollbar represents, as it does (up to a point) in other
systems, the vertical proportion of the total view occupied by the
currently visible view, acme would have to recalculate the
total vertical size every time the window changes width.

since one excellent attribute of acme is that it deals with very large
files well (and it keeps most of the file cached in a temporary file),
forcing it to re-read all of the data in all file when a column is resized
could be really quite slow. thinking about it, perhaps that's what
you meant by "reading the file" above?

luckily the fact that the scrollbar changes size doesn't matter
at all, as you almost never have to aim the mouse at it.
i'm generally not keen on the ergonomics of 8½/rio, but i think the
scrollbar design
is a brilliant exception. where were they first seen in this form?

Re: [9fans] acme scrollbar

[hiro]

That makes perfect sense, thanks.

I love the way how the text at the clicked point will just move to the top.
Perhaps I am being stupid, but why doesn't left-clicking cause that
point to move down to the bottom?
I never know where in the text I will end up when I'm scrolling upwards...

--
hiro

Re: [9fans] acme scrollbar

[Martin Neubauer]

The left click is basically doing the opposite of the right click - it moves
the top line to the position of the click. That way a left click after a
right click restores the previous view of the file. (There may be some small
distortion due to lines longer than the width of the window but that doesn't
really matter much.)

* hiro (23hiro@googlemail.com) wrote:
> That makes perfect sense, thanks.
>
> I love the way how the text at the clicked point will just move to the top.
> Perhaps I am being stupid, but why doesn't left-clicking cause that
> point to move down to the bottom?
> I never know where in the text I will end up when I'm scrolling upwards...
>
> --
> hiro

Re: [9fans] acme scrollbar

[hiro]

On 7/3/08, Martin Neubauer <m.ne@gmx.net> wrote:
> The left click is basically doing the opposite of the right click - it moves
>  the top line to the position of the click. That way a left click after a
>  right click restores the previous view of the file. (There may be some small
>  distortion due to lines longer than the width of the window but that doesn't
>  really matter much.)

Oh, i ruled this possibility out, because I didn't see any opposite behaviour.
The long lines *do* matter much.
This feature is useless when it's unreliable.
What do you think about my idea of moving the line to the bottom instead?

Re: [9fans] acme scrollbar

[a]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

I dislike this idea. I think for most people, most of the time,
the lines acme's working with will fit well within the width of
a window. Yeah, I bet most of us have run into longer lines at
times, but the interface is optimized for the common case. I
wouldn't like to see that go.

Having the "undo" (paralleling the "undo" of a 1-2, 1-3 chord)
is very nice. The feature is certainly *not* "useless" for not
being 100% reliable; what's it' off by, a line? Even that's a
"good enough" job for your eye to find the line quick enough.
Anthony

[-- Attachment #2: Type: message/rfc822, Size: 2843 bytes --]

From: hiro <23hiro@googlemail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Subject: Re: [9fans] acme scrollbar
Date: Thu, 3 Jul 2008 00:34:06 +0200
Message-ID: <f4d8fa40807021534q52ddcab0n51a51140bbb2d9e9@mail.gmail.com>

On 7/3/08, Martin Neubauer <m.ne@gmx.net> wrote:
> The left click is basically doing the opposite of the right click - it moves
>  the top line to the position of the click. That way a left click after a
>  right click restores the previous view of the file. (There may be some small
>  distortion due to lines longer than the width of the window but that doesn't
>  really matter much.)

Oh, i ruled this possibility out, because I didn't see any opposite behaviour.
The long lines *do* matter much.
This feature is useless when it's unreliable.
What do you think about my idea of moving the line to the bottom instead?

Re: [9fans] acme scrollbar

[roger peppe]

> What do you think about my idea of moving the line to the bottom instead?

bad idea. to be honest i don't think the precise semantics of the scroll
distance are very important, but it is important that left and right
buttons are near inverses of each other, which means that when
scrolling down, you can easily get back to the last view you saw
without moving the mouse at all.

the only change i think i'd make is that perhaps a right click
should move the text just *below* the mouse position to the
top. that way there wouldn't be a line's worth of "zero-movement"
vertical space at the top of the window - which is particularly
noticeable when the window is only a couple of lines long - in which case
half the scrollbar doesn't react at all to left or right buttons currently.

i'd implement this, but UI changes are controversial.

Re: [9fans] acme scrollbar

[hiro]

On 7/3/08, a@9srv.net <a@9srv.net> wrote:
> I dislike this idea. I think for most people, most of the time,
>  the lines acme's working with will fit well within the width of
>  a window. Yeah, I bet most of us have run into longer lines at
>  times, but the interface is optimized for the common case. I
>  wouldn't like to see that go.
>
>  Having the "undo" (paralleling the "undo" of a 1-2, 1-3 chord)
>  is very nice. The feature is certainly *not* "useless" for not
>  being 100% reliable; what's it' off by, a line? Even that's a
>  "good enough" job for your eye to find the line quick enough.
>  Anthony

Then probably my eyes are just too slow:(
It really doesn't work with me. But probably I'm getting old?!

Re: [9fans] acme scrollbar

[hiro]

> bad idea. to be honest i don't think the precise semantics of the scroll
>  distance are very important, but it is important that left and right
>  buttons are near inverses of each other, which means that when
>  scrolling down, you can easily get back to the last view you saw
>  without moving the mouse at all.

Ok, a matter of taste.
I always had the feeling that knowing exactly how far the window will
move even before clicking is a really awesome feature.

Re: [9fans] acme scrollbar

[matt]

a@9srv.net wrote:
> I dislike this idea. I think for most people, most of the time,
> the lines acme's working with will fit well within the width of
> a window. Yeah, I bet most of us have run into longer lines at
> times, but the interface is optimized for the common case. I
> wouldn't like to see that go.
>
I'm frequently editing text that line wraps, I think your sample size is
too small.