[9fans] acme design

[9fans] acme design

[cej]

> I think you lost the most important point of acme, that is acme has
> windows recursively,

sorry for ignorance, but can you hint me some more info on this?

> and all the menus we can see on a plane.

as it is in my proposal, but there is no redundance, and menuitems are all just text written into the scrollable "cmd frame"

> It helps us very much from the deeply nested menues which break
> the promise we don't need to read manual. ☺
just make the frame buig enough(for the moment) or scroll..

++pac.

Re: [9fans] acme design

[Kenji Okamoto]

>> I think you lost the most important point of acme, that is acme has
>> windows recursively,
> 
> sorry for ignorance, but can you hint me some more info on this?

The direction which we took for our marsv. ☺

By the way, I don't want to make debate here, however, I could
recommend you to forget the acme's way if you want to make
something new user interface for Plan 9.   Acme's way is good
for text things, I know.  If you are thinking of an extension of
acme for text thing, I think it's not so interesting to me.   Acme is
good enough to me.

Kenji

[9fans] acme design

[cej]

could anyone explain me why Edit command (plus the whole language)
was hardwired into acme (thus breaking its purpose as UI, not an editor,
and moving closer in spirit to those windozish bloat apps, IMHO)
instead of a separate prog, like mail was implemented?
Again, why would be an "acme sam" a bad solution??
sorry if i am too naive...

best,
++pac.

Re: [9fans] acme design

[Russ Cox]

> could anyone explain me why Edit command (plus the whole language)
> was hardwired into acme (thus breaking its purpose as UI, not an editor,
> and moving closer in spirit to those windozish bloat apps, IMHO)
> instead of a separate prog, like mail was implemented?
> Again, why would be an "acme sam" a bad solution??
> sorry if i am too naive...

You could try using the old edit interface
as described in the acme paper.  It was clunky.
Piping things through sed or just running sam 
to do what you wanted was much better.

In contrast, I use Edit almost every day, to do
things that you can't do with sed.

Russ

Re: [9fans] acme design

[boyd, rounin]

> could anyone explain me why Edit command (plus the whole language)
> was hardwired into acme (thus breaking its purpose as UI, not an editor,

i think you'll find it was designed to be an editor.

> and moving closer in spirit to those windozish bloat apps, IMHO)
> instead of a separate prog, like mail was implemented?

then i think all this other stuff  was added, turning it into a UI.

[9fans] acme design

[cej]

: you do have "ordinary" scrolling - just use the middle button,
: as it says in the manual.


sorry, but this doesn't work for me! middle button doesn't scroll at all-- just sweeps and executes.
I tried to find it man 1 acme, but there is nothing like
please, tell me *how* do you scroll the tagline w button2 ???



>as someone else said, if you want more text than will fit in a tag, 
>just click on "New" and use it as a scratch window.

try |wc in [new] frame (not in tag) and it will apply to itself, not to the dot in the last active frame! And what about |sed 's/blahblahblah.....long/BLAHBLAH/g' ? 
(As I mentioned some time ago, I dont like hardwiring the 'Edit' cmd into Acme: what about [better sed | stream sam] instead? maybe I am wrong all the time, but isnt it (Edit) against plan9 ideas?)

++pac.
---
Peter A. Cejchan
Lab of Paleobiology and Paleoecology
Prague, EU
http://www.gli.cas.cz/home/cejchan

[9fans] acme design

[cej]

>++pac wrote:
>>> The tags scroll if you drag button1 up or down in the tag.
>> 
>>  actually, they appear not to scroll but just jump to the end  what if 
>> i want to exe a cmd somewhere in the middle? just retype/paste into an 
>> ordinary frame?

>Apologies if this sounds flippant, but your comment above makes me want to ask: What do you keep in your tags?)
>Whole scripts or paragraphs of text?  I use middle click on New and type in the new pane for stuff like that.

... pipelines

++pac.

[9fans] acme design

[cej]

> - how will one know what is the filename (pathname) for each window?
> - in acme, just by looking into the tag line, i know i can run 'grep XXXXX
> *.c' on a particular window. how can i do it with this?

if Acme remembers, which "normal frame" has been touched the last, [and it does, doesn't it?]
then it applies to it

> - the (new) windows on the right are the ones used for tags and commands.
> now, how much space would they occupy? 
as much as you wish, of course, as normal ones...

> what happens when the pathnames and
> commands are longer than the ones in the sample image?

nothing, text wraps as in normal text frame...

> - you have safely assumed there will be only one column (of windows). what
> happens when you have to have 2 or even 3 columns? even in 1024x768, one
> could manage with 2 columns. with your idea, wont it waste space?

no. have as many cols as you wish [see Newcol] . New frame, like new column,
could appear just at the end, and zou could drag it anywhere.
Perhaps the quick drawing was too simple, sorry for that. And, once more, thanks for the
debate.

++pac.

Re: [9fans] acme design

[a]

// the list will always take you to the correct 
// place [current window?], won't it? 

i just don't see how. i mean at a functional level - like, what's the thing
*do*? highlight the file my cursor's over? what's the behavior?

// cursor position | highlighting in "listing/tag window" not sufficient?

nope. i want to know by looking at the window i'm typing in, or as close
to it as possible. not some (mentally) unrelated window in another Col.
it's not so much an issue while i'm typing, but when i'm switching from
one win to another, how do i know where to move my mouse?

// use last "ordinary window" [for execution] ... i think 

i don't think that'll work. if i'm editing a window at the top of a Col and
the "tag" window is at the botom of the Col, or two Cols over, how do i
get to it without mousing over another normal window? or do i have to
make some manual change before i can edit that window?

// isn't a tag "line" a special frame that [currently] behaves 
// differently from "normal" one?? 

yes, which is exactly why i said it was a reasonable thing to question. i'd
be interested in ways to structure things that don't have this modality in
them. but i certainly can't come up with one.

// my "tag frame" i think could behave just normal 

except for auto-highlighting or some other indication method, and
automatically updating itself for the list of open files (hopefully!). and how
would i refer to it? how would i Put it?

// as much as you wish, of course, as normal ones... 

this is space-ineffecient. i'd always be resizing it. the current window
tags are (intentionally or no) optimized for the small data they contain
(perhaps too much, hence the splinter-thread about scrolling).

[9fans] acme design

[cej]

> "normal" frames (which seems good - they break the "all text is
> equal" theme that's present elsewhere) but then introduces several
> (at least two, possibly more i can't see) new types of "special"
> frames. 

isn't a tag "line" a special frame that [currently] behaves differently from "normal" one??
my "tag frame" i think could behave just normal, bringing up the frame named bz text as it
does in usual frame, so does the "command frame" with ,maybe, one exception that it must not 
apply commands to itself, but to the last touched frame, which it must know ... however, it doesn't need to differ from
current behavior of a tagline, does it?

> this adds more modes to the operation of the interface,

i hope it does not...

> which is bad. 

would be.

++pac.

[9fans] acme design

[cej]

> The tags scroll if you drag button1 up or down in the tag.

	actually, they appear not to scroll but just jump to the end
	what if i want to exe a cmd somewhere in the middle? just retype/paste into an ordinary frame?

> But I agree, having automatic scrolling when typing would be nice.
	having ordinary scrolling would be nice ;-)

> I can easily live without it though.
	me not.... :-(  ... it renders me unaesthetic, sorry.
	And yes, my proposal was driven perhaps more by puristic
	view on what [subjectively, of course] is/isn't perceived aesthetic,
	than true ergonomic/other advantages.

	thanks for debate, regards,

++pac.

Re: [9fans] acme design

[plan9]

++pac wrote:
>> The tags scroll if you drag button1 up or down in the tag.
> 
> 	actually, they appear not to scroll but just jump to the end
> 	what if i want to exe a cmd somewhere in the middle? just retype/paste into an ordinary frame?

Apologies if this sounds flippant, but your comment above makes me
want to ask: What do you keep in your tags?  Whole scripts or
paragraphs of text?  I use middle click on New and type in the new
pane for stuff like that.

The only times I have difficulties with text length in tags is when
using acme under Unix, as I have less control over most of the
absolute filenames.  And files under Unix tend to live in very deep
directory hierarchies.  Which incidentally, led to the introduction of
the special way environment variables are used by wily.

Robby

Re: [9fans] acme design

[rog]

>	having ordinary scrolling would be nice ;-)

you do have "ordinary" scrolling - just use the middle button,
as it says in the manual.

Re: [9fans] acme design

[rog]

i said:
: you do have "ordinary" scrolling - just use the middle button,
: as it says in the manual.

oops. i didn't understand the context of this (tag scrolling) until too late.
sorry.

as someone else said, if you want more text than will fit in a tag,
just click on "New" and use it as a scratch window.

there's not enough space in a tag for scrollbars.

Re: [9fans] acme design

[YAMANASHI Takeshi]

> as someone else said, if you want more text than will fit in a tag,
> just click on "New" and use it as a scratch window.

As someone else said, Edit commands typed in the New'ly
created scratch window can't be applied to contents in
other windows, if I'm correct.  And when everytime I want
to execute one of them, snarf&paste it into the intended
tagline and execute it is painful.

Rather, I have something like this at the top of a Zerox'ed
window and use them.
	| |-----------------------------------------------
	[=]/usr/nashi/src/9skk.c Del Snarf | Look
	| |-----------------------------------------------
	| |/*
	| |	Edit 5,10x/hogefuga what ever long edit commands here
	| |	Edit x/yet another long commands here
	| |*/
	| |-----------------------------------------------
	[=]/usr/nashi/src/9skk.c Del Snarf | Look Edit =
	| |-----------------------------------------------
	| |void
	| |main(int argc, char **argv)
	| | ...

# Sorry to disturb you for merely showing my custom.

> there's not enough space in a tag for scrollbars.

Agreed. But autoscrolling horizontaly without any scrollbar
when typing past the right end of a tagline could be helpful.
-- 

Re: [9fans] acme design

[Charles Forsyth]

> As someone else said, Edit commands typed in the New'ly
> created scratch window can't be applied to contents in
> other windows, if I'm correct.  And when everytime I want
> to execute one of them, snarf&paste it into the intended
> tagline and execute it is painful.

select editing commands in New window.
click button 2-1 chord on Edit in target window.

Re: [9fans] acme design

[YAMANASHI Takeshi]

Thank you, forsyth.

> select editing commands in New window.
> click button 2-1 chord on Edit in target window.

Now I've learned how to use 2-1 chord.
But 2-1 seems not to work in `/mail/fs/mbox/'.
Can somebody double-check me?

# I tried 2-1 sometime before in /mail/fs/mbox/
# and it stayed in ever swelling my need-to-study
# list since then.
-- 

Re: [9fans] acme design

[Rob Pike]

> Now I've learned how to use 2-1 chord.
> But 2-1 seems not to work in `/mail/fs/mbox/'.
> Can somebody double-check me?

unfortunate but true.  i don't remember the details but there
is some nasty reason why i couldn't get the arguments to
a 2-1 chord delivered to external applications.

-rob

Re: [9fans] acme design

[YAMANASHI Takeshi]

> > But 2-1 seems not to work in `/mail/fs/mbox/'.
>  i don't remember the details but there
> is some nasty reason why i couldn't get the arguments to
> a 2-1 chord delivered to external applications.

Thank you, rob.  Anyway, 2-1 chord solved
the narrowness of taglines for most part of mine
(html and c source editting).

By the way, I changed the return key to execute the
selected commond in a tagline, i.e type a command
in a tagline, press ESC to highlight it then RET to
execute it.  I will see how I like this or not.
-- 

Re: [9fans] acme design

[Rob Pike]

> By the way, I changed the return key to execute the
> selected commond in a tagline, i.e type a command
> in a tagline, press ESC to highlight it then RET to
> execute it.  I will see how I like this or not.

others have asked for this feature or something like it,
but i've always resisted because it seems wrong to
change the meaning of newline depending where you
type it.

still, you're not alone.

-rob

Re: [9fans] acme design

[YAMANASHI Takeshi]

robpike>
> but i've always resisted because it seems wrong to
> change the meaning of newline depending where you
> type it.

You kindly warned me.  Imho, it wasn't much comfortable
than New window and 2-1 chord anyway.


vdharani>
> but doesnt it look vi-style?

I was once a vi lover before I met with acme.
It's hard to clear away the old habit, it seems.
-- 

Re: [9fans] acme design

[vdharani]

> By the way, I changed the return key to execute the
> selected commond in a tagline, i.e type a command
> in a tagline, press ESC to highlight it then RET to
> execute it.  I will see how I like this or not.

but doesnt it look vi-style?

thanks
dharani

[9fans] acme design

[cej]

Hi, maybe one picture is worth thousand words ;-)
my idea was sthg like this:

http://www.gli.cas.cz/home/cejchan/plan9/newacmedesign.jpg


++pac.

Peter A. Cejchan
Lab of Paleobiology and Paleoecology
Prague, EU
http://www.gli.cas.cz/home/cejchan

Re: [9fans] acme design

[a]

maybe, but i still don't get it. :-)

or maybe i do and i'm in denial. i see two "content" frames, a tag
frame, and a command frame. what determines which content frame
the commands operate on? how do i know which "content" frame is
which in the tag list?

this model seems to eliminate the tag bar as distinct from the

"normal" frames (which seems good - they break the "all text is
equal" theme that's present elsewhere) but then introduces several
(at least two, possibly more i can't see) new types of "special"
frames. this adds more modes to the operation of the interface,
which is bad. it also significantly increases the amount of mouse
motion needed to execute Tag items (even assuming some magic AI
for tracking which frame you're talking about).

what is it you think this model gains you?

(i'd like to see either multi-line or scrolling Tags, to avoid loosing
bits when the Tag gets too long, and the ability to create Rows at
the top-level like i can with Cols. these are certainly more
incremental (an thus possibly less exciting) than your suggestion,
but i'm pretty sure i can clearly show the benefits.)

Re: [9fans] acme design

[plan9]

a@9srv.net wrote:
> (i'd like to see either multi-line or scrolling Tags, to avoid loosing
> bits when the Tag gets too long, and the ability to create Rows at
> the top-level like i can with Cols. these are certainly more
> incremental (an thus possibly less exciting) than your suggestion,
> but i'm pretty sure i can clearly show the benefits.)

The tags scroll if you drag button1 up or down in the tag.
But I agree, having automatic scrolling when typing would be nice.
I can easily live without it though.

Robby

Re: [9fans] acme design

[rog]

i been thinking that one way to make the filenames less obtrusive in
acme would be to allow grouping of windows with a common path prefix.

i quite often find myself working in, say
/n/dump/2004/0529/usr/inferno/appl/cmd/scheduler/...  and that really
doesn't give much space for tag commands.

i could imagine some kind of directory-tagged super-window in acme
that contained other windows.  windows inside it whose names were
prefixed by their super-window's tag would show only a pathname
relative to that directory.  dragging a window outside would show the
whole pathname again.

looking at the acme window i'm writing this email in, this would save
much space, and provide a reasonable way of organising windows too (i
quite often find myself doing a Sort, or typing a full pathname and
right-clicking on it, just to find a particular window).

at least with something like this it would be possible to look at an
acme window and work out where all the files are, something that's not
possible with the env var hack, for instance.

Re: [9fans] acme design

[lucio]

> looking at the acme window i'm writing this email in, this would save
> much space, and provide a reasonable way of organising windows too (i
> quite often find myself doing a Sort, or typing a full pathname and
> right-clicking on it, just to find a particular window).

I wonder if it would help any to keep the name of the most recently
active window in the top tag bar and allow commands in that tag bar to
apply to the window it indexes.  Keeping focus is then harder, of
course, but that has always been controversial anyway.

++L

Re: [9fans] acme design

[rog]

> I wonder if it would help any to keep the name of the most recently
> active window in the top tag bar and allow commands in that tag bar to
> apply to the window it indexes.  Keeping focus is then harder, of
> course, but that has always been controversial anyway.

this would only rarely be useful to me.  (although it would be nice to
have some visual indiciation of the "current" window - i was quite
perplexed recently when clicking on Zerox in a window's tag Zeroxed
some *other* window...  at least Edit doesn't work like this)

it's the fact that i can't have narrow columns when i'm working with
deep filenames that gets to me.

Re: [9fans] acme design

[kiwane]

On 2004/06/03, at 23:34, rog@vitanuova.com wrote:
> it's the fact that i can't have narrow columns when i'm working with
> deep filenames that gets to me.

A tag is defined to be single-lined. How about changing it to be
multi-lined? (but no scroll bar, perhaps)

-- kazumi

Re: [9fans] acme design

[rog]

> A tag is defined to be single-lined. How about changing it to be
> multi-lined? (but no scroll bar, perhaps)

a slippery slope...

Re: [9fans] acme design

[Bengt Kleberg]

rog@vitanuova.com wrote:
> i been thinking that one way to make the filenames less obtrusive in
> acme would be to allow grouping of windows with a common path prefix.
> 
> i quite often find myself working in, say
> /n/dump/2004/0529/usr/inferno/appl/cmd/scheduler/...  and that really
> doesn't give much space for tag commands.
> 
> i could imagine some kind of directory-tagged super-window in acme
> that contained other windows.

does acme use existing environment variables, like wily does?

from the idioms webpage (http://www.cs.yorku.ca/~oz/wily/idioms.html):

Short-cut Environment Variables
Set environment variables to make window labels shorter and easier to 
type, e.g.

	h = $HOME
	wilysrc = $h/src/wily/wily
	wilybin = $h/obj/$cputype/wily/wily


bengt

Re: [9fans] acme design

[Axel Belinfante]

Bengt wrote:
> rog@vitanuova.com wrote:
> > i been thinking that one way to make the filenames less obtrusive in
> > acme would be to allow grouping of windows with a common path prefix.
> > 
> > i quite often find myself working in, say
> > /n/dump/2004/0529/usr/inferno/appl/cmd/scheduler/...  and that really
> > doesn't give much space for tag commands.
> > 
> > i could imagine some kind of directory-tagged super-window in acme
> > that contained other windows.

It would be great to have a `blessed' (non-hack) solution to make the
filenames less obtrusive. With unix acme the filename is regularly
longer than the width of the tag, meaning one would have to scroll
in the tag even to Put or Un/Redo - this takes away much of the joy
of using acme.
The env var hack makes acme usable for me on unix, and I'm happy to
use it until a better way of dealing with long filenames comes along.

> does acme use existing environment variables, like wily does?

No, but, for the unix acme you can find a patch in the
plan9 ports CVS repository (no idea how hard it would be to
back port it to plan 9).
I slightly patched that for even more comfort, see below.


Axel.


One thing I noticed: the sorting in mkruneenv pays
special attention to the env var names: case and length.
For me, even more important is that I get the env var
for the longest file name, so, if I have

	home=/home/me
	fo=/home/me/fo
	fofoo=/home/me/fo/foo

then when I'm in directory /home/me/fo/foo/bar
I would like to see $fofoo/bar and not
$fo/foo/bar, and certainly not $home/fo/foo/bar .

I cooked up the following patch, just tested to
see if it works, not used long enough to notice
I overlooked something, nor to know whether it
works as comfortable as in wily.

Index: wind.c
===================================================================
RCS file: /cvs/plan9/src/cmd/acme/wind.c,v
retrieving revision 1.4
diff -r1.4 wind.c

[unrelated differences omitted; line numbers may be off]

650,651c648,649
<       Rune *a, *b;
<       int na, nb;
---
>       Rune *a, *b, *af, *bf;
>       int na, nb, fcmp;
655,656c653,659
<       na = runestrchr(a, '=') - a;
<       nb = runestrchr(b, '=') -  b;
---
>       af = runestrchr(a, '=');
>       bf = runestrchr(b, '=');
>       na = af - a;
>       nb = bf -  b;
>       fcmp = runestrcmp(af, bf);
>       if (fcmp != 0)
>               return -fcmp;

Re: [9fans] acme design

[Kenji Okamoto]

> http://www.gli.cas.cz/home/cejchan/plan9/newacmedesign.jpg

I think you lost the most important point of acme, that is acme has
windows recursively, and all the menus we can see on a plane.
It helps us very much from the deeply nested menues which break
the promise we don't need to read manual. ☺

By the way, I think to separate the menu and the main window may
be a good idea which I wanted to test if I have time and power...

Kenji

Re: [9fans] acme design

[Kenji Okamoto]

> By the way, I think to separate the menu and the main window may
> be a good idea which I wanted to test if I have time and power...

I don't mean to do it on acme, but make it a different things from
acme.

Kenji

Re: [9fans] acme design

[WLad]

cej@gli.cas.cz wrote:
> Hi, maybe one picture is worth thousand words ;-)
> my idea was sthg like this:
> 
> http://www.gli.cas.cz/home/cejchan/plan9/newacmedesign.jpg

Oh! It looks like I have seen this somewhere long before... ;o)

http://www.oberon.ethz.ch/native/WebScreen.html

more detail examples:

http://www.oberon.ethz.ch/native/snaps/tile.jpg
http://www.oberon.ethz.ch/native/snaps/vnc.jpg

Do not see at date. These pics are just as examples. I assure you that 
same interface was in the mid of 80ths...

Regards

Re: [9fans] acme design

[vdharani]

> Hi, maybe one picture is worth thousand words ;-)
> my idea was sthg like this:
>
> http://www.gli.cas.cz/home/cejchan/plan9/newacmedesign.jpg
>

- how will one know what is the filename (pathname) for each window?
- in acme, just by looking into the tag line, i know i can run 'grep XXXXX
*.c' on a particular window. how can i do it with this?
- the (new) windows on the right are the ones used for tags and commands.
now, how much space would they occupy? what happens when the pathnames and
commands are longer than the ones in the sample image?
- you have safely assumed there will be only one column (of windows). what
happens when you have to have 2 or even 3 columns? even in 1024x768, one
could manage with 2 columns. with your idea, wont it waste space?

thanks
dharani