GNOME Bugzilla – Bug 513764
Implement a means to copy and paste from flat review
Last modified: 2013-01-02 10:50:13 UTC
(from the Orca list) Mohaned: ----------------------- Hey, I have a new feature suggestion for Orca and thought to mention it here. How about a virtual window feature to be able to copy and paste from dialogs? Orca could have an assigned keystroke that pops up a window containing all the text as sceen by the flat review script. One could use this feature to paste error messages into other windows for example. ----------------------- Hermann: ----------------------- But to avoid the same discussion we had about a year ago, I suggest a compromise: What about thinking of a copy-and-past-feature like Speakup? It comes with a clipboard of its own, and you can copy text between different consoles. What about that? ----------------------- Steve: ----------------------- I think for these examples a cut/paste function from the flat review function would be a good compromize; just cut or copy into the standard gnome clipboard and then it could be pasted into a terminal or wherever. I would think that nearly 100% of info cut or copied in this manner would be text so could only logically be pasted in places like text boxes, terminal, form fields, etc. -----------------------
Created attachment 104221 [details] [review] revision 1 I'm not sure (yet) if we can change the contents of the actual clipboard -- nor am I sure that we should be doing so even if we can. But I'll leave that up to others. In the meantime.... We can certainly have a special "flat review" clipboard. This patch implements such a creature along with three unbound keybindings: one to copy the current flat review contents to our special clipboard, one to append them to the existing contents of our special clipboard, and one to paste the contents of our special clipboard into an accessible which implements the editableText interface. I haven't yet worked out how to insert text into a terminal via at-spi. Important, important, important: To use the functionality implemented in this patch, you will first need to bind the unbound keybindings in the Orca Preferences dialog. When you do so, the new keybindings will get added to the appropriate settings file (e.g. user-settings.py). If you later reverse the patch or check out a new version of Orca from trunk, Orca will see these unfamiliar handlers and spit up. We should probably do something about that. In the meantime, either backup your pre-patched user-settings.py or edit out those bindings when you're finished testing this.
Created attachment 104230 [details] [review] alternate version: Use the real clipboard Steve asked about why not use the real clipboard. Personally I don't think we should be altering the state of items in the environment to which we are providing access. But that's just me. Besides, as Steve rightly pointed out, using the real clipboard solves the issue of not being able to insertText() in a terminal. <smile> This eliminates the need for the paste function so this patch has just two keybindings. The same warnings (remove the keybindings from the patch before using an unpatched Orca) still apply.
Created attachment 104233 [details] [review] alternate version: Use the real clipboard - correct docs :-) I forgot to update the docs in the alternate version to indicate that we're using the actual clipboard rather than a special Orca clipboard.
I think we're too late in the GNOME 2.22 cycle to address this one well. The problem I have is that there is support already in GNOME to allow users to copy/paste text from labels. For an example of this, run the "Dialog and Message Boxes" demo of gtk-demo and select the "Message Dialog" button. This will bring up a window where you can tab to, navigate (by caret), select (and copy the selection) of the labels. A more generalized solution like this can also be useful to all sorts of people. So, I wonder if we might want to just consider pushing for F7 type support in dialogs to enable adding labels in the tab order and also making them navigable/selectable? I'm on the fence, however, because I wonder about the more common (and more specialized) problem that arises, which is copy/paste from a terminal window. F7 wouldn't support that, but this patch would. Thoughts?
First coarse pass at GNOME 2.24 planning.
I see that this is on my 2.24 list. Whatever folks want to do about this is fine with me. But I'd like input so that I can proceed with it/re-target it/whathaveyou. Thanks!
With all the things on your plate for 2.24 this one is not a high priority for me. Just my opinion.
Makes sense Mike. Plus there has not been an outcry from the user community demanding this functionality. Therefore, I'm retargeting this one to FUTURE. If I get caught up with the things on my 2.24 plate sooner than expected, I'll revisit/retarget/reask my question. :-) Thanks!
I am in favour of pasting to the clipboard rather than having a special clipboard for this. I think that in most use cases you want to grab some specific text off the screen which you can't select in any other way and then you want to use it in another application and pasting is as good a way as any to get at the cut text. Just my two cents worth.
Pinging this bug. Yeah, I know, it's mine. :-) The question is: Do we want to revisit this, proceed with it, or call it a WONTFIX?
Well I think it would be good to get working at some point. Having said that there are many other things that would make a bigger impact on my user experience of Orca than this bug. So if it is easy to do and wouldn't take long I'd say go for it, otherwise leave it for the future.
(In reply to comment #11) > Well I think it would be good to get working at some point. It was already working. :-) New (master-compatible) patch coming up.
Created attachment 137196 [details] [review] master-compatible version This uses the real clipboard and provides two new commands -- currently unbound: 1. Copy flat review contents to clipboard. 2. Append flat review contents to clipboard. Will please review -- or declare this bug as a WONTFIX. I honestly don't mind either way. I just think keeping it open if we're not going to actually do it means we have an extraneous bug/RFE languishing in our list.
(In reply to comment #13) > Created an attachment (id=137196) [edit] > master-compatible version > > This uses the real clipboard and provides two new commands -- currently > unbound: > > 1. Copy flat review contents to clipboard. > 2. Append flat review contents to clipboard. > > Will please review -- or declare this bug as a WONTFIX. I honestly don't mind > either way. I just think keeping it open if we're not going to actually do it > means we have an extraneous bug/RFE languishing in our list. My question is this - with this, one can copy only the character, word, or line they have just reviewed. Is this sufficient for users, or are we going to end up needing to do more (and more and more)?
(In reply to comment #14) > My question is this - with this, one can copy only the character, word, or line > they have just reviewed. Is this sufficient for users, That's what the append command is for. This functionality is intended for those cases where something (perhaps inaccessible design over which we have no control because the bugs we file are ignored) is preventing the user from being able to grab needed text. So the worst case would, I believe, be flat review next line, append, flat review next line, append. Etc. I also think (hope) that any environment which has a bunch of lines of text will have a standard way in which all users can select and copy that text. Do you have suggestions which would improve the functionality associated with this RFE? > or are we going to end up needing to do more (and more and more)? You mean like implementing structural navigation in Gecko and having a user request table navigation for Writer? ;-) ;-) ;-) ;-) ;-) In all seriousness, I cannot predict what might happen down the road. All I know is that this RFE is assigned to me....
(In reply to comment #15) > Do you have suggestions which would improve the functionality associated with > this RFE? Heh - I'm not against what you've done. It could prove to be very useful. All I really want is for users to say "yeah, this will work well for me." Even if that approval came from only Mike or Bart, I'd be pleased with you checking this patch in. If it's not something they can work with, however, then my fear is that this will become some vociferous user's "most important bug of the day" and this will soak up a lot of time. Note also that we might consider binding this to BrlAPI commands (like we've done with brlapi.KEY_CMD_CUTBEGIN and brlapi.KEY_CMD_CUTLINE) to allow copying from the braille display.
Hi Given that the code already exists I think this should be put in. It does do a very specific job, but a job that in some situations can't be done any other way. I don't think that it will be used very offen but when it is it will be very useful. Only time will tell how much "real" day to day use will be made of this feature. I guess if that in 6 months time or so if noone is using it then it could be removed?
(In reply to comment #17) > Only time will tell how much "real" day to day use will be made of this > feature. I guess if that in 6 months time or so if noone is using it then it > could be removed? It's rare that you pull something out. Most likely, someone would end up using it and it would squeal very loudly if we took it out. Are you technically inclined enough to try to build/install Orca from git with the patch Joanie has provided? If so, it would be great to get your feedback on its usability.
Sure, I build from git almost every day. I'll download and apply the patch. Have to be tonight as I'm off to work just now.
I'd also like to give this a test drive before it gets committed. Because of some other deadlines I won't be able to do so until after Friday.
After talking with Will and Joanie about this one I really think the user experience should be as follows: It should be possible to mark the begin and end point of a region to be selected. It should be possible to include anything currently showing in flat review. For an example we should use the brltty selection functionality. While the current patch would be useful for some I'd be in favor of holding off on this one until we can really have the desired user experience.
Thanks for testing and feedback Mike. Based on this, and as discussed, I'm taking this one off my plate.
I wonder what happened to this enhancement? Is this going to be implemented later on, or never? :-)
I recall at one time being able to select portions of text in gnome-terminal by pressing the KP_divide key once at the beginning and then doing a shift+KP_divide key or something similar to end the selection and then use standard copy and paste operations with the standard clipboard. In fact that worked for a while but then that functionality failed some time last year. I could never reliably select text in the terminal again. Based on some e-mails on the list, it was mentioned that double and tripple clicks of the KP_divide key would select line and sentence respectively; I haven't yet tried this out yet to confirm if this will work but it is no replacement for being able to select text text as before. I don't know if the breakage happened in Orca or if it had something to do with gnome-terminal. If this were assigned to me, I would persue the ability to select text in flat review and then use the conventional methods of copying to the clipboard. This would work in the terminal though not so sure about other dialogs with static text that isn't normally able to be focused.
I think this patch (the latest version that uses the real clipboard) should be brought up to date, if necesssary, and integrated. It seems to me that there are two options: either Orca implements this functionality, or applications such as Gnome-terminal have to write their own keyboard-based text selection scheme. The latter is unlikely to happen, and ATK/AT-SPI already provides a mechanism to set the selection, so I think the responsibility really lies with the AT to support this functionality. This isn't a high-priority problem for me; it's just annoying to have to dance around with xclip to copy text from a console session into an X application - it would be easier if Gnome-Terminal could be used for this purpose. I'm sure Gnome-Terminal isn't the only example but it's the obvious one. I don't want to influence development priorities and I know there are a million other issues in play.
Jason, every time I asked about this on the Orca list, the impression I got is that most of our users were not interested and that those few who were could not agree on what exactly the functionality should be. So the patch stagnated. Given your comments, I have updated the patch and committed it to master. Thanks for the feedback! http://git.gnome.org/browse/orca/commit/?id=50f3d525ec6517d3c2a9c3828f4ac0f5e06350bd