[9fans] horizontal scroll for acme?

[9fans] horizontal scroll for acme?

[pac]

what about  | rs [lines cols] and back,
see man rs from BSD utils
never tried, though,
regarsd,
++pac

=================================
kenji wrote:

> and horizontal axis on a fly.    Is this an better idea?

I meant to flipt the following tupple's list
 |1111|2222|3333|4444|5555|6666|7777|   <--- tupple1
 |2222|3333|4444|5555|6666|7777|8888|   <--- tupple2
 |3333|4444|5555|6666|7777|8888|9999|   <--- tupple3
into
    t1        t2      t3
 |1111|2222|3333|
 |2222|3333|4444|
 |3333|4444|5555|
 |4444|5555|6666|
 |5555|6666|7777|
 |6666|7777|8888|
 |7777|8888|9999|
on a fly.

kenji


---
Odchoz� zpr�va neobsahuje viry.
Zkontrolov�no antivirov�m syst�mem AVG (http://www.grisoft.cz).
Verze: 6.0.489 / Virov� b�ze: 288 - datum vyd�n�: 10.6.2003

Re: [9fans] horizontal scroll for acme?

[boyd, rounin]

i think i'd do it as a 'pan', so you can scroll in x+y dimensions without
the addition of another scroll bar.  some gps's allow you to 'pan' if
it has a 'pointing stick' thing.

Re: [9fans] horizontal scroll for acme?

[matt]

boyd, rounin wrote:

>>when does plan 9 get Tabbed Dialog Boxes, they're great
>>
>>
>
>except when you want to enter a tab.
>

as is the way with all of MS dialogs

however [shift]ctrl-tab moves between tabs in a tabbed dialog

Re: [9fans] horizontal scroll for acme?

[boyd, rounin]

> when does plan 9 get Tabbed Dialog Boxes, they're great

except when you want to enter a tab.

Re: [9fans] horizontal scroll for acme?

[matt]

>
>
>Having to have the confusing OK, Cancel, and Apply buttons on a dialogue
>so changes can be applied without the dialogue disappearing is poor.
>

it is worse than poor because despite having Apply there is no undo and
cancel applies to the Dialog Box not the changes

when does plan 9 get Tabbed Dialog Boxes, they're great

Re: [9fans] horizontal scroll for acme?

[Ralph Corderoy]

Hi Charles,

> i'd try to find another scheme.  in my experience, and i'm fairly sure
> i'm not the only one, having two scrollbars hardly ever works sensibly
> in practice: you rarely want to move in just one dimension at once, so
> you end up having to flit between them, typically losing context
> whilst doing so.  it's particularly bad for program text and web
> pages.  indeed, i'd say it's a good example of an attempt to appear to
> solve a problem without actually doing so.

`RISC OS' developed by defunct UK company Acorn for their ARM computer,
they developed the ARM too, used the 3-button mouse thus

    Button 1 on scrollbar arrow scrolled in indicated direction, button
    3 scrolled in the opposite.

This saved having to move the mouse pointer from one end of the scroll
bar to the other.  This has been avoided in the past by having both
arrows at the one end of the scrollbar but that just looks wrong.

    Clicking button 1 above the scrollbar `thumb' paged in the direction
    of the pointer.  Holding the button down made the paging repeat.
    Using button 3 instead again went in the opposite direction.

    Dragging the scrollbar thumb with button 1 scrolled the window with
    continuous update, i.e. the window didn't scroll only on button
    release.  The mouse pointer's movement was locked to the bounds of
    the scrollbar, e.g. the pointer couldn't move sideways out of the
    scrollbar.  Dragging with button 3, when there was a horizontal and
    vertical scrollbar, dragged *both* scrollbars, i.e. a `panner'
    widget for free.

The use of button 3 to do a similiar but different thing to button 1 was
used throughout the GUI and was very useful.  Another example, pop-up
menus appeared on button 2 click.  Selecting an item with button 1 made
the menu disappear.  Using button 3 made the menu stay open, although it
may update to reflect the new state.

That these type of experiments were around over a decade ago, and have
disappeared thanks to everyone copying Microsoft is a real shame.
Having to have the confusing OK, Cancel, and Apply buttons on a dialogue
so changes can be applied without the dialogue disappearing is poor.
Using button 3 to `OK' the dialogue but have it remain on the screen is
much better in use.

Cheers,

--
Ralph Corderoy.      http://inputplus.co.uk/ralph/     http://troff.org/

Re: [9fans] horizontal scroll for acme?

[spam]

> If we consider an acme application which has horizontal long
> list, such as tupples in database, we now has problem.

It's also possible to edit many formats of bit-map graphics in
Acme, but I prefer to use a different tool. Perhaps a database
rather than a text editor is the best way to edit large tuples,
even if the representation is ASCII based?

On the other hand, I understand the problem, and
I wondered if an Acme tool is possible that handles columated
data, allowing navigation and selecting of rows? (Is
this a minimal spreadsheet program?)

I decided in the end that the data should be handled by other
tools and \include'd into the document I was writing.


ian

Re: [9fans] horizontal scroll for acme?

[okamoto]

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

Thanks, boyd.
Aaa, acme resembles really 'rolodex'.

Kenji

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

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] horizontal scroll for acme?
Date: Wed, 4 Jun 2003 10:04:44 +0200
Message-ID: <005201c32a6f$f614ca80$e3944251@insultant.net>

> What means 'rolodex'?

http://www.eldonoffice.com/rolodex

Re: [9fans] horizontal scroll for acme?

[boyd, rounin]

> What means 'rolodex'?

http://www.eldonoffice.com/rolodex

Re: [9fans] horizontal scroll for acme?

[okamoto]

> This may be good if we could have a possibillity to exchange the vertical
> and horizontal axis on a fly.    Is this an better idea?

I meant to flipt the following tupple's list
 |1111|2222|3333|4444|5555|6666|7777|   <--- tupple1
 |2222|3333|4444|5555|6666|7777|8888|   <--- tupple2
 |3333|4444|5555|6666|7777|8888|9999|   <--- tupple3
into
    t1        t2      t3
 |1111|2222|3333|
 |2222|3333|4444|
 |3333|4444|5555|
 |4444|5555|6666|
 |5555|6666|7777|
 |6666|7777|8888|
 |7777|8888|9999|
on a fly.

kenji

Re: [9fans] horizontal scroll for acme?

[okamoto]

> by acme's 'rolodex' approach to window access.  i like a lot of

What means 'rolodex'?
My dictinary has no this word...

Kenji

Re: [9fans] horizontal scroll for acme?

[okamoto]

Hi, Charles,

> you end up having to flit between them, typically losing context
> whilst doing so.

I agree with this point.   Yes, it's hard to image the whole sentence when
we scrolled up the part of the whole.

>it's particularly bad for program text and web
> pages.  indeed, i'd say it's a good example of an attempt to appear to
> solve a problem without actually doing so.

Yes, I thought once to display the querried result in a vertical dorection
where many attributes are aligned vertical, and instances are in horizontal.
This may be good if we could have a possibillity to exchange the vertical
and horizontal axis on a fly.    Is this an better idea?

kenji

Re: [9fans] horizontal scroll for acme?

[boyd, rounin]

> i'd try to find another scheme.

i'm pretty sure rob said at one point that he wasn't really convinced
by acme's 'rolodex' approach to window access.  i like a lot of
the ideas in acme, but i just can't use it.

the two scroll bar idea is just a disaster.

perhaps being able to 'pan and scan' [like many GPS receivers support]
would eliminate the need for such a hideous kludge.

Re: [9fans] horizontal scroll for acme?

[Charles Forsyth]

i'd try to find another scheme.  in my experience, and i'm fairly sure
i'm not the only one, having two scrollbars hardly ever works sensibly
in practice: you rarely want to move in just one dimension at once, so
you end up having to flit between them, typically losing context
whilst doing so.  it's particularly bad for program text and web
pages.  indeed, i'd say it's a good example of an attempt to appear to
solve a problem without actually doing so.

[9fans] horizontal scroll for acme?

[okamoto]

If we consider an acme application which has horizontal long list,
such as tupples in database, we now has problem.   Of course,
I know it can be done for another windowing application such
as marsv.   However, that kind of application is mainly for text
based, and I think it should be done on acme.

Did anyone work on this aspect?

Kenji