[9fans] acme

[<cej@gli.cas.cz>]

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

Hi all 9friends,

I won't like to start a flame-war (possibly), however,  I decided to make some comments on my favourite, and *BELOVED* UI, The Acme:

Cut+Paste (or, mouse-2-3) on a tagline leaves the frame in a 'dirty' state: this bug has not been present in earlier (abou 2 years ago, or so) versions of Acme.


Mouse-3 on highlighted path in a tagline doesn't move cursor to that frame in case it is visible, unlike when done in regular frame; strangely, it works when that frame is NOT visible, for both tagline, and regular frame. And, it also works from tagline when the path is mouse-3-dragged, so definitely a bug.

Mouse-3 on filename opens the frame 'around a corner' if the current layout is so that frames are tightly stacked at the bottom (frame is quasi-maximized). Popping up the frame may need clicking several times.

Scrolling the tagline using downarrow/uparrow does not work; scroling with dragging mouse-1 is too fast even on my 'primeval' S3 card.

'Del' has no special position on the tagline, thus closing multiple frames sucks. Could we have 'Del'  on far left, preceding filepath??? Or , perhaps, e.g., mouse1+3, or Alt+mouse-1, or ...., over the frame 'handle' would do? Are you strictly against combinations of keyboard with mouse?? I personally perceive it O.K., however, i'm not disabled. Oberon UI, which, I think, initially inspired Acme, is much more exhaustive considering possible keyboard-mouse interactions (well, I mean classic Native Oberon UI, not the Gadgets/Bluebottle, which, IMHO, downgraded the UI to 'standard windozish' one)

A command that will switch fullpath/basename from the tagline might be useful for orientation (well, I can do 'Sort' often).

When many frames are open in a column, moving cursor to the frames 'behind the horizon' requires multiple mouse-3 clicks, until it eventually comes up.

There is some 'dead space' at the bottom of the Acme's window, where nothing is drawn, and nothing happens. Bug??

No way to kill a busy (non-responding) frame??

No way to hide columns except the current one (==maximize frame | column horizontally). We could easily use columns 'handle square' (violet one at the upper left corner) exactly in the way the frame's handle is used: mouse-3 == maximize, mouse-2 == show condensed columns, mouse-1 == increment column width.

Maybe, double-click mouse-2 on 'Del' could close a dirty frame immediatelly, without asking (and w/o saving).

GRRRRRRR..... : the dot is not persistent: if I have selected areas of text in different frames, returning to the frame and Snarf'ing does *NOT* pick up the relevant 'dot' (just the one last selected)..... this is *VERY* annoying, indeed.

And, the frames should behave the same way, shouldn't they?? I spot different behavior of frames showing dirs from those showing files. yes, and I don't even mention that the tagline is a very special frame of its own...

Would welcome more keyboard actions, like line up/line down, jumping to starts of words, to line-beginning/end. I appreciate very much moving left/right over characters, in case of hi-res screen (laptop), where exact mouse positioning is tedious.

Personal remark:
I miss very much something like a command window in 'Sam'... tagline is both very restrictive, and redundant, IMHO. Frame-specific commands could just remember  the last-touched frame (or two, if a parameter is to be sent) to solve the problem of frame-owned taglines (Am I right?? Dunno...).

End remark: I'm (probably) capable of some ideas, but not so of coding them. Please, excuse me. I'm an ethernal pupil.


===
is this a legal declaration?:
struct color      convert_position_to_color(struct position pos);
 Or should I do typedef first?

pcc complains about multiple declaration when function is defined.

======
to Andrey Mirtchowski:

If you had an [awk | rc] script to make thumbnails album in [PostScript | troff], I would be much interested. I don't care about html ;-))

=====
how do I quit 'con'  ??


=====
 

 


[-- Attachment #2: Type: text/html, Size: 5679 bytes --]