Rracking.

*** Bug 319754 has been marked as a duplicate of this bug. ***

Add accessibility keyword.  Apologies for spam.

*** Bug 400730 has been marked as a duplicate of this bug. ***

Comment from Mario on bug 400730 (it was marked as a dup of this one):

BRLTTY already provides bindings (commands) for:
 * CUTBEGIN (start new cut buffer at character)
 * CUTAPPEND (append to existing cut buffer from character)
 * CUTRECT (rectangular cut to character)
 * CUTLINE (linear cut to character)
All of these commands provide a character position as an argument.
So we already have two different types of "shift" + one cursor routing key
for starting and ending an area.
These bindings are frequently used when BRLTTY is used for console review
since they provide cut'n'paste support between consoles (like gpm does for
mouse users). So the user is already familiar to them, and kind of expects them
to work for selecting text in GUIs as well.

Even though the functionality will be slightly different because we will be using the selection functionality from the application I'd really like to se us just do what Mario states here and use the existing brltty key bindings.

I see my name has been added to the summary, but I'm not sure what the expected response/action is. :-)

O just because you and I talked about you taking this one a while back.

Mike and I talked about this, and he's going to put [requirement] back in the bugs that were marked as requirements.

First coarse pass at GNOME 2.24 planning.

Now that we've dropped the old 3.7.2 support and have readjusted the braille handling code to be much more in line with BrlAPI, implementing the feature of this bug report becomes something that is much more achievable.

In looking at this, however, I'm wondering if the BrlTTY meaning of "cut" is more like the GUI equivalent of "copy".  I was playing with these commands:

KEY_CMD_CUTBEGIN:  Dot 1 + cursor routing key
KEY_CMD_CUTAPPEND: Dot 2 + cursor routing key
KEY_CMD_PASTE:     Dots 1-2-3-4 ("p")

It seems like the workflow in BrlTTY is:

1) CUTBEGIN marks the beginning of the area to copy
2) CUTAPPEND marks the end the area to copy (and performs the copy, I guess)
3) PASTE inserts the copy buffer to where you might want it

There's also KEY_CMD_SETMARK, which I'm not sure is related to this space or not.

I'm trying to figure out how to map this to the typical GUI tasks:

* Copying and pasting as above
* Merely selecting text for other operations (e.g., changing font attributes)
* Really cutting text from the document (e.g., selecting it then deleting it)

I'm CC'ing Mario on this in hopes he can lend some insight as to whether BrlTTY already provides recommended series of commands to perform the above or if we need to invent something new for Orca's use of BrlTTY.  Mario, do you have any insight?

In reply to comment #11:
> In looking at this, however, I'm wondering if the BrlTTY meaning of "cut" is
> more like the GUI equivalent of "copy".
Right.  The term was probably choosen due to its resemblance to the popular
phrase "cut&paste", but what it really does in console mode at
least is copy, i.e. it does not delete any on-screen text.
> There's also KEY_CMD_SETMARK, which I'm not sure is related to this space or not.
SETMARK is not related to cut&paste.  In console mode, it is used
to remember a certain screen position, and jump to that later on (GOTOMARK).
> * Copying and pasting as above
I think this would be what most users would expect.
> * Merely selecting text for other operations (e.g., changing font attributes)
This is a very interesting idea.  If it works across most
toolkits, I'd actually prefer this, since it would allow me to
choose if I want to invoke cut or copy.  However, I guess it
depends on compatibility with toolkits if this is really a good idea.
> * Really cutting text from the document (e.g., selecting it then deleting it)
While it resembles the name, I think this behaviour would
violate the principle of least astonishment, at least for those users
used to the cut&paste behaviour on the console.

(In reply to comment #12)
> > * Copying and pasting as above
> I think this would be what most users would expect.

Sounds good.  Can you describe in more detail what the expected behavior is?  For example.  I assume once the user presses KEY_CMD_CUTBEGIN, they are going to start a whole new selection.  The "append" part of KEY_CMD_CUTAPPEND, however leads me to believe the user might keep pressing KEY_CMD_CUTAPPEND to somehow adjust what is to be copied.  Is this correct?

BTW, I'm assuming the implementation of this would probably put things into the clipboard.  KEY_CMD_PASTE would then paste the content from the clipboard into the insertion point of the current text area.

> > * Merely selecting text for other operations (e.g., changing font attributes)
> This is a very interesting idea.  If it works across most
> toolkits, I'd actually prefer this, since it would allow me to
> choose if I want to invoke cut or copy.  However, I guess it
> depends on compatibility with toolkits if this is really a good idea.

The standard operation procedure is that the user first selects the text and then performs some operation on it (e.g., copy, cut, change attributes, etc.).  If that's what you'd prefer, then it seems like KEY_CMD_CUTBEGIN and KEY_CMD_CUTAPPEND would be used for selection.  If we do that, which BrlTTY commands would one use for copy and cut?  Would we require the user to move their hands to the keyboard to do Ctrl+C or Ctrl+X?

From IRC today:

"(15:10:58) delYsid: Anyway, so to sum up, for the benefit of making paste across virtual terminals work, it might be desireable to not bind PASTE just yet, and only use CUT(BEGIN|APPEND) and CUT(LINE|RECT) for now"

So, the initial model I'm going to shoot for is this, and it will only be done for text areas:

* KEY_CMD_CUTBEGIN (Dot 1 + cursor routing key on my display) - this will specify the start of a selection.  Orca will merely move the caret to the given spot.

* KEY_CMD_CUTLINE (Dot 4 + cursor routing key on my display) - this will specify the end of a selection.  Orca will use the text API to select from the caret to the character selected by the routing key.  The selection will also automatically be copied to the system clipboard.

With this, the state is maintained in the application and not in Orca.  In addition, because selection will always start from where the cursor/caret is, this can reduce text selection to a simple KEY_CMD_CUTLINE.

Note that this will be the initial approach and we can play with it from there.

Created attachment 134219 [details] [review]
First patch to play with

Here's a first pass at a patch.  Seems to work OK.  Here's the behavior:

KEY_CMD_CUTBEGIN (Dot 1 + cursor routing key on my display) - this will specify the start of a selection.  Orca will merely move the caret to the given spot and will clear any existing selection.

KEY_CMD_CUTLINE (Dot 4 + cursor routing key on my display) - this will specify the end of a selection and the selected text is automatically copied to the system clipboard.  If a selection doesn't exist, Orca creates a new one where the other endpoint of the selection is where the caret is.  If a selection exists and the selection point is outside the existing selection, Orca extends the existing one.  If a selection exists and the selection point is inside the existing selection, Orca trims the selection from the right (i.e., the selected text that's after the selection point becomes unselected).

This only works in text areas, and there's some strangeness with speech feedback: it sometimes says "unselected" when the text is selected.  This should be fixable, but there also probably shouldn't be any speech feedback when doing this from the braille display.

A couple things on this one.  

1.  I agree that there should be no speech when selecting from the braille display.  

2.  The highest priority issue here for things to fix in the future would be the limitation of not being able to select across paragraph boundries in open office.  

Even with these to issues I think this patch is worth checking in for community testing as it is a nice improvement.  

Patch committed to master for 2.27.2 to make it easer for more people to use.  Leaving this open, however, because of known issues that need to be resolved:
    
    1) This only works in text areas.  It doesn't work across things such as
       paragraphs in OpenOffice.
    
    2) There's some strangeness with speech feedback: it sometimes says
       "unselected" when the text is selected.  This should be fixable, but
       there also probably shouldn't be any speech feedback when doing this
       from the braille display.

We are late in the 2.28 release cycle and I want to focus on "high impact"/"low risk" items that also fall within the release team's restrictions in place.  Regretfully, this bug doesn't fit well within those constraints and we'll review it for the 2.29 release cycle.

Bulk reassigning Will's bugs to the default assignee. (Sorry for the spam!)