Re: cut and paste in gnome-terminal

[Bill Haneman <Bill Haneman Sun COM>]

Mario said, of the assertion that cut-and-paste is a function of the 
application, not the terminal:

> That sounds more like an excuse than a solution to me  :-) 
>  
I know what you mean.  However, it is true that many console 
applications provide their own keystrokes for text selection, which is 
the core feature you really need here.  In general if an application 
already provides a feature, trying to introduce it into the 
application's operating environment (in this case the terminal emulator) 
can be a recipe for conflicts.

Basically every keystroke combination you can think of is already used 
by some terminal application, so no matter what key combination we chose 
for 'keyboard selection', it would conflict with _something_.

I've suggested (in bugzilla bug #78291) that keyboard selection should 
be modal, for that reason - i.e. the terminal user could invoke some key 
sequence to toggle 'selection mode' on and off.  Of course that key 
sequence itself is likely to conflict with something else, but we 
already have hotkeys for menus in gnome-terminal, so I think it would be 
reasonable to add this functionality to the gnome-terminal menus.

But the lack of keynav cut-and-paste is something that comes up rather 
frequently in applications.  I agree that the applications _should_ 
provide keyboard navigation for all these features, but the reality is 
that putting a feature like this into gnopernicus and/or orca (via the 
AccessibleText API) would probably still be helpful.  I object somewhat 
more strenuously to relying on mouse-motion synthesis to help us - I 
know that for instance JAWS provides this, and gnopernicus is supposed 
to provide some mouse synthesis too, but I consider a mouse-only 
application to be quite broken.

We have the 'MouseKeys' feature via the numberpad which can be used to 
move the mouse around, but for blind users the feedback for this is very 
poor, and as Kenny has pointed out, the use of the numberpad for this 
conflicts with gnopernicus keybindings.  Mouse motion often has side 
effects, so I think that moving the 'mouse cursor' by default is a bad 
idea - it's better in my opinion to use this as a method of last resort.

>  We will
> need mouse motion at some point anyway (some windows apps come to mind, where
> the only way around certain accessibility problems is to go and use
> the mouse somehow).  I kind of like the approach that JAWS
> is taking here, you can switch between two cursors, the
> editing cursor, and the mouse.  If you are in mouse mode, your arrow
> keys move the mouse, and the display (braille or speech) follows.
> Actually, in that mode you can even use the real mouse to navigate,
> since your braille display will follow it around.
> So ideally, I'd just switch to mouse mode, go where I need to start my cutting,
> hold shift, and move the cursor to where my cut ends...
> This could also be useful for people with certain physical disabilities.
> I've known a girl once who had real difficulties holding her hands still.
> Mouse usage was not easy for her, since the pointer used to jump
> around on the screen.  She even got a special keyboard where the
> keys were kind of holes, so that she wouldnt accidentally miss them.
> A simple cursor based mouse movement method would probably have helped her.
>  
We do have this, but since it uses the numberpad, gnopernicus needs to 
provide some alternate keybindings in order for both MouseKeys and 
gnopernicus to be useful at the same time.  Note that MouseKeys use of 
the numberpad is specified via X keymaps, so it makes more sense to 
modify the gnopernicus keybindings than to try making MouseKeys use 
something else.

Regards,

- Bill

> (Maybe we already have that, but we'll need to make sure that it works in
> combination with screen readers like say, gnopernicus)
>
> Just my 2 euro cents.
>
> -- CYa, Mario