Re: [Usability] gnome-terminal shortcuts



On Thu, 2005-12-29 at 20:07 +0000, Steve Fosdick wrote:
> Joachim Noreiko <jnoreiko yahoo com> wrote:
> 
> > SHIFT+CTRL+V is an awkward combination for
> > something that's used frequently.
> 
> Probably the easiest way round that is to use selections rather than
> copy/paste.  If you select some text in the terminal window, or
> another application, then centre-click in the terminal window the
> selected text will be pasted in without needing to type any obscure
> key combinations.

For my part I miss being able to use drag and drop on fragments of text.
This can be even easier as long as you work with overlapping windows and
don't use some irritating window manager that raises windows when you
click in them, obscuring the destination :-)  The open look window
managers had a key you could use to raise/lower windows during a drag,
but except on an AT&T or Sun keyboard, where it was the Raise/Lower key,
it was hard to discover.

[...]

> Back to the point about control-key combinations and gnome-terminal,
> different programs running in the terminal will have different needs
> for being able to transmit control characters through from the
> keyboard.  Emacs, for example, uses just about all of them while many
> programs only need those control characters that have been assigned to
> functions within the POSIX tty interface, e.g. (intr, quit, erase,
> eof, eol, start, stop, susp, and sometimes others).  It would be
> possible to re-assign the POSIX tty functions to different control
> characters that weren't otherwise assigned by the HUI guidelines and
> we could even add menu options to send them.  As most of the people
> who use the terminal are experienced unix people though we would
> probably anoy them and I am not convinced that we would get much extra
> usablility for those who are not so computer oriented as they would
> probably avoid the command line anyway.

The use of control-C for Copy comes from sloppy thinking in the first
place, but it's probably too late to change it.  Apple used command-C
and Sun used <>-C (meta-C) until they downgraded to CDE and OSF/Motif.

At any rate I think you need to take the traditional Unix control keys
as being unavailable for shortcuts at the between-windows level --
including control-C (intr), control-U (kill), control-W (werase),
control-V (lnext) and all the others.

I can imagine getting some momentum behind a new modifier used for
window manager and cross-client features such as raise/lower,
copy/paste, iconify/restore and so forth, if all the major players
adopted it.  That might leave emacs users stuck with using 9 modifiers
instead 8 (or whatever... the joke that "emacs" stands for esc meta
alt control shift is not entirely without basis in fact).

Some combinations (e.g. shift-control) make sense only in the GUI
environment, and cannot normally be used by terminal applications
(except for control-shift-"-", which is really ^_, and control-shift-6,
which is really ^^, both of which are used by programs like emacs and
vi, although ^^ is unavailable in gnome-terminal with a US keyboard).

Sun used shift to reverse the meaning, so ^U was delete to start of
line (as in the shell) and shift-^U was delete-to-end-of line,
control-return moved to the end of the buffer and shirt-control-return
moved to the start.  They were easy to remember, as I found to my cost
when I started using evolution and had to train myself that
shift-control-return now meant "send message immediately without
further confirmation" and not "go back to start of message to
review draft".

This is a good argument for standardising on them, but it would be
a big battle.

For now, you just have to live with terminal emulators (not just
gnome-terminal) using different keybindings for windowing operations.

Liam


-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin
Pictures from old books: http://fromoldbooks.org/
Liam (Ankh) on the Web: http://www.holoweb.net/~liam/
IRC (chat) programs: www.ircreviews.org/clients/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]