Re: [orca-list] Copy, Cut and Paste feedback Orca feature request



-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Given how you just described this feature, I will would still contend
it to be a bad idea.  Let me give you one verry good reason.  What if
by chance, the particular keys in question are not assigned to
cut/paste/copy or if that particular didn't support cut/paste
operations? One example is the gnome-terminal.  it uses
shift-control-v to paste and I think shift-control-c to
copy... Whenever I'm un sure,  I look in the edit menu to find it.  I
also don't feel it is the screen reader's responsibility to support
cut/paste/copy directly either.  Speech annotation is nice when an
operation is performed but even the Windows screen readers don't
actually speak when the operation was a success; they just speak
because the key was pressed.  That is no guarentee that you really
cut/copied the text at all.

Now one exception  here is with Speakup on the text console; it has a
copy/paste feature that allows one to copy text from one console to
another or or simply from one point in time to another.  That comes in
extremely handy as there isn't any other simply way for a blind person
to copy/paste text in a text console without having to use GPM and a
mouse.  I'm not personally aware of any other way to do it in a linux
native console.  As a side note, that xclip package is a really cool
way to copy text between native consoles and gnome applications.

On Wed, Aug 19, 2009 at 03:08:29PM +0100, Isaac Porat wrote:
Hello Michael 

The screen reader in question checks if say text is selected.  If it is,
when you do Ctrl + c and Ctrl + x it will say 'copied' and 'Cut'
respectively.  If not it will say nothing selected.
I find it useful sometime when one jumps to edit boxes etc when the state is
unknown or text can not be selected so one knows if copy occurred or not.  I
don't think the clipboard is monitored as such it is the selection in the
application itself I think.
Otherwise there is no intelligence in respect to the paste for example if
one copies a file to the clipboard and one tries to paste it by mistake to a
text file it will still say 'Pasted' which I still find a sort of
confirmation that one pressed the right key but otherwise is of no real use.
So it is the copy and Cut mainly which give if you wish meaningful
confirmation.

Regards
Isaac

-----Original Message-----
From: orca-list-bounces gnome org [mailto:orca-list-bounces gnome org] On
Behalf Of Michael Whapples
Sent: 19 August 2009 13:39
To: Orca-list gnome org
Subject: Re: [orca-list] Copy, Cut and Paste feedback Orca feature request

Hello,
here are some of my thoughts regarding this. I have got very used to orca
not announcing this information, so I don't feel a great need for me to have
it. However I can see that for some it could be useful. I would say though
we do need to make sure it is done correctly. I can think of an example of a
screen reader on another OS which seemed to speak cut, copy and paste
regardless of what the action really was, I believe it did this because it
was set to speak cut on control x, copy on control c and paste on control v,
unless the settings file for the specific application said otherwise. This
example is as bad, possibly even worse than our current situation with orca
as its speech output could actually be wrong rather than non-existent.

Now Will's suggestion of a way of monitoring the clipboard directly (or
checking the clipboard) would be the best way as this doesn't depend at all
on the key presses. I haven't got a clue whether this would be possible or
not (either directly with at-spi (although Will doesn't think there is a
way) or through another application).

Isaac, do you have any clue as to how the screen reader you are thinking of
does this? Does it respond to the key press and then check whether cut, copy
or paste may have occurred or does it do it by monitoring the clipboard? I
know that the accessibility APIs on different OSs do differ in the way they
work, but it would indicate whether a satisfactory solution could be done by
monitoring the most commonly used cut, copy and paste keys (IE. ctrl+x,
ctrl+c and ctrl+v). As an example of my thinking here, we could make a
pretty good guess that something has been copied if the user presses ctrl+c
and there is something selected.

Michael Whapples
On -10/01/37 20:59, Isaac Porat wrote:
Hello All

The Cut, Paste and Copy feedback is a feature which I appriciate with 
my screen reader in the other OS and wonder if other people share the 
same view, I would like to suggest a similar feature in Orca.
Please find below my communication with Will which will clarify the issue.

I am looking forward to your feedback.
Regards
Isaac

And the communication with Will...
Hi Isaac:

   
I send this to the list but received no feedback; perhaps lost among 
the discussion on text processing...
So I send this to you privately.
     
Using the list would be preferred.  I get lots of e-mail and rely upon 
others on the orca-list to help me out with answers.  I also prefer to 
have public discussions around these kinds of things.  :-)

   
A feature that I find very useful with my screen reader on that other 
operating system is feedback on Copy, Cut and Paste.
So If I try to copy something that was highlighted I press Ctrl + c 
and it will say 'copied'
If nothing is highlighted it will say 'nothing to copy' it works in a 
similar way with Cut.
With paste it will say 'pasted' and if there is nothing to paste from 
the clipboard it tells you 'nothing to paste'.
I find the above very useful indeed but as far as I can tell Orca 
does not do this.
Can I request this as a feature?
     
Right now, I'm not sure there's anything in the AT-SPI that allows us 
to know for sure that something was added to the system clipboard or 
pulled from the clipboard.  There might be some other API's that can 
help us, but I'm not sure.  I see something here, but I don't see a 
way to be notified when something is posted to or copied from the
clipboard:

http://www.pygtk.org/docs/pygtk/class-gtkclipboard.html

There might be some sort of D-Bus protocol for working with the 
clipboard, but I'm not aware of it.  In addition, there seems to be a 
GUI applet
(http://sourceforge.net/projects/glipper/) for monitoring the clipboard.
This might be something that could be scripted.

In any case, if you open an enhancement request at 
http://bugzilla.gnome.org against the Orca project, we can track it.

Will



   

_______________________________________________
Orca-list mailing list
Orca-list gnome org
http://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca for more information on Orca.
The manual is at
http://library.gnome.org/users/gnome-access-guide/nightly/ats-2.html
The FAQ is at http://live.gnome.org/Orca/FrequentlyAskedQuestions
Netiquette Guidelines are at
http://live.gnome.org/Orca/FrequentlyAskedQuestions/NetiquetteGuidelines

_______________________________________________
Orca-list mailing list
Orca-list gnome org
http://mail.gnome.org/mailman/listinfo/orca-list
Visit http://live.gnome.org/Orca for more information on Orca.
The manual is at http://library.gnome.org/users/gnome-access-guide/nightly/ats-2.html
The FAQ is at http://live.gnome.org/Orca/FrequentlyAskedQuestions
Netiquette Guidelines are at http://live.gnome.org/Orca/FrequentlyAskedQuestions/NetiquetteGuidelines
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREDAAYFAkqRseAACgkQWSjv55S0LfG8eACgosSndodlVqKluYJiVktjWbuN
vEkAoMykxGNbJh76e5rQ8dxByJssQPki
=nBZi
-----END PGP SIGNATURE-----



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