New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drag Mouse Feature #1755

Open
nvaccessAuto opened this Issue Sep 6, 2011 · 10 comments

Comments

Projects
None yet
3 participants
@nvaccessAuto
Copy link

nvaccessAuto commented Sep 6, 2011

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.

@nvaccessAuto

This comment has been minimized.

Copy link

nvaccessAuto commented Sep 6, 2011

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:

  1. Move the mouse to the source position. You can do this with the help of NVDA's move mouse to current navigator object command.
  2. Lock the mouse button. You can do this with a physical mouse or you can use NVDA's left/right mouse button lock commands.
  3. Move the mouse to the target position, similar to step 1.
  4. Unlock the mouse button, similar to step 2.

Have you tried this? Why is this not sufficient?

@nvaccessAuto

This comment has been minimized.

Copy link

nvaccessAuto commented Sep 6, 2011

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?

@nvaccessAuto

This comment has been minimized.

Copy link

nvaccessAuto commented Sep 7, 2011

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.

@nvaccessAuto

This comment has been minimized.

Copy link

nvaccessAuto commented Sep 7, 2011

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.

@nvaccessAuto

This comment has been minimized.

Copy link

nvaccessAuto commented Oct 16, 2011

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

@nvaccessAuto

This comment has been minimized.

Copy link

nvaccessAuto commented Jan 2, 2012

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)
2. Locate the object where you want to drop and activate the modified script again (would first route the mouse to it, then unlock the button) and you are done!
[[BR]([BR]]
1.)]
Better still the suggested modification can also be done on not the original "left mouse button lock" script itself, but on a clone of it. This way the clone script would be turned into an independent "drap and drop" script (e.g. NVDA+D can be assigned to it), while leaving the original left button lock/unlock script alone. This latter solution would make it possible to lock/unlock the left mouse button independent of drag and drop operations, if it has any other uses besides that at all.
Changes:
Removed labels: wontfix
State: reopened

@nvaccessAuto

This comment has been minimized.

Copy link

nvaccessAuto commented Jan 2, 2012

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?

@nvaccessAuto

This comment has been minimized.

Copy link

nvaccessAuto commented Jan 2, 2012

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]([BR]]
Replying):

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?

@bhavyashah

This comment has been minimized.

Copy link

bhavyashah commented Aug 7, 2017

@jcsteh #1755 (comment) 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?

@jcsteh

This comment has been minimized.

Copy link
Contributor

jcsteh commented Aug 7, 2017

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:

  1. Some apps freeze or misbehave in terms of accessibility when you lock the mouse button. If I recall correctly, iTunes is one example, but I'm pretty sure I've seen others too.
  2. The fact that the lock left mouse button command involves the shift key seems to interfere with dragging in some apps; e.g. dragging icons on the Windows Taskbar. I guess it gets interpreted as a shift+click, which might have different behaviour.

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:

  1. The first press should mark for drag but not actually start it.
  2. The second press should begin the drag and then drop where it was pressed.
  3. Rather than just performing all the actions in quick succession, there will need to be some additional mouse movements and delays to stop some apps just treating this as a click. Dragging users to channels in Mumble is one example where this is necessary.
  4. If the user marks for drag by mistake (step 1), they can press it again at the current location to cancel.

Marking as feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment