Open nvaccessAuto opened 13 years ago
Comment 1 by jteh on 2011-09-06 23:21 This is already possible without any additional functionality. All related commands are already documented, so you just drag like any other user would:
Have you tried this? Why is this not sufficient?
Comment 2 by Ahiiron on 2011-09-06 23:39 I can see this being useful to copy formatting and HTML markup from a webpage. Currently, doing the lock/unlock method and copying the text doesn't retain any of the formatting, it just copies the text from the virtualBuffer. Is there perhaps a way to get at the actual page with pictures and all?
Comment 3 by Ahiiron on 2011-09-07 02:47 On closer inspection, the formatting is copied correctly. I was testing in wordpad and wasn't getting any links /list item notifications from NVDA like in Thunderbird's compose message window. Should I open a ticket for a feature request to have markup be indicated in RichEdit apps like WordPad?
Thanks.
Comment 4 by jteh (in reply to comment 3) on 2011-09-07 07:09 Replying to Ahiiron:
On closer inspection, the formatting is copied correctly. I was testing in wordpad and wasn't getting any links /list item notifications from NVDA like in Thunderbird's compose message window. Should I open a ticket for a feature request to have markup be indicated in RichEdit apps like WordPad?
You should get notifications for links at least; I've definitely seen this. However, I don't think !RichEdit supports any other kind of structural formatting.
Comment 5 by jteh on 2011-10-16 22:36 No reply to comment:1, so assuming this is sufficient. Changes: Added labels: wontfix State: closed
Comment 6 by Palacee_hun on 2012-01-02 20:15 I suggest a simplification of the documented drag and drop procedure (see Comment #1) which would be very easy to implement. My suggestion would reduce the process from 4 steps to just 2 steps. The only thing to be done would be to modify the "lock left mouse button" script so that the "route mouse to nav. object" script would be called prior to locking/unlocking the left mouse button. This simple modification would yield the following drag and drop procedure whichseems much more practical, yet would not differ from the way sighted people do it: [Locate the object to be dragged with object nav., then activate the modified "lock left button" script (would route the mouse and then immediately lock the button)
Comment 7 by jteh on 2012-01-02 22:28 I'll grant that this reduces the procedure from four keystrokes to two. However, it also introduces redundancy, inconsistency and potential confusion. The user already has to learn how to route the mouse to left click, right click, etc., so why should drag/drop be any different?
Comment 8 by Palacee_hun (in reply to comment 7) on 2012-01-02 23:00 That's partially why I suggested to implement this modification on a clone script of the "left mouse button lock toggle" script turning it into a simple "drag and drop" script. I think this would not introduce any confusion and inconsistency, maybe only a bit of redundancy. In this way existing scripts wouldn't change, only users would have a more convenient drag and drop facility if they wished to make use of it. [to comment:7 jteh:
I'll grant that this reduces the procedure from four keystrokes to two. However, it also introduces redundancy, inconsistency and potential confusion. The user already has to learn how to route the mouse to left click, right click, etc., so why should drag/drop be any different?
@jcsteh https://github.com/nvaccess/nvda/issues/1755#issuecomment-155292395 responds to your initial doubts about whether or not drag-and-drop requires simplification. Is the cited comment cogent or do you still maintain that this ticket should be closed as a wontfix?
This is still arguably redundant. Having said that, I've seen quite a few users struggle with these concepts; it just doesn't feel natural and I guess it's a lot to think about. Also, I've seen a few other problems with this over the years:
So, I don't think the implementation proposed earlier will work because of the freeze issue I mentioned in 1). I think we're going to need a separate command for this. Rough thoughts:
Marking as feature.
Actually, the mouse dragging feature currently implemented is quite ok in my view. It works prety well in applications where the mouse can be routed reliably to the focus (i.e. internet explorer, Windows explorer, Firefox etc.). In my view mouse routing without using the mouse at all is quite inefficient. This is how I deal with this in Windows 10:
It is not a simple solution, but it works really nice after exercising abit.
Imo the only way that would make this process more agile would be to implement a customized dialog into NVDA which would let you to choose the application and the region you want to drop the file into. The process would look like this:
The biggest problems are the following:
cc: @JulienCochuyt maybe you have some helpful thoughts on this as well.
IMHO attempting to automate too much detection of drop regions and proper disposition of windows is a huge work with tons of reasons to fail and uselessly block the user.
The steps described in https://github.com/nvaccess/nvda/issues/1755#issuecomment-656385773 are tedious but hardly avoidable in a safe and generic way.
Still, I agree we could come up with something more user friendly than the current process, especially regarding drag & drop with modifiers (eg. right button drag & drop with control
key held, etc...).
Based on https://github.com/nvaccess/nvda/issues/1755#issuecomment-320566306, I'd propose:
I think this approach would be nice, however this also assumes that NVDA moves the mouse from an application into another by itself. This will fail in many instances due to missing object location coordinates, offsets and what not. I think an alternative API handling this specific drag 'n drop process is a better choice in the long term. However, I don't really have any idea on how this should be acomplished consistently. I think UIA defines drag 'n drop properties if I am not wrong, so at least between applications with UIA support this should work via the API without routing a mouse to a certain region. But I am not sure how this exactly works.
Another approach to simplify this could be as follows:
This approach would have following advantages:
@Adriani90, a "mouse cursor" is definitely a needed feature in NVDA, but IMHO it would not solve the issue altogether. It might be of some help in navigating from drag location to drop location, but ineffective in supporting drag&drop with modifiers or working around UI that do not emit AT events while the mouse button is kept pressed.
@Adriani90 wouldn't that just be duplicating the behavior of Microsoft's MouseKeys feature?
Not really, since the mouse keys just move the mouse and there is no simple way to work with it on laptops. But some of this functionality could be inherited to nvda though Von meinem iPhone gesendet
Am 16.07.2020 um 19:40 schrieb Luke Davis notifications@github.com:
@Adriani90 wouldn't that just be duplicating the behavior of Microsoft's MouseKeys feature? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
Hi,
As of NVDA 2022.4, UIA drag and drop state and properties are supported and announced if appropriate (see #12271).
Thanks.
@josephsl - do you think this issue can be closed then?
Reported by ateu on 2011-09-06 23:11 Sometimes, this is the only one way to select and copy texts, buth in web documents and others. Therefore I think NVDA should provide feature drag mouse functionality.