fix: app was responding to drag-drop mouse moves even with setting disabled

[jeffbargmann]

App continued to respond to mouse moves during drag-drop even if "respond to mouse" setting was disabled.

[lwouis]

Hi @jeffbargmann,

I'm not sure i perceive this behavior as a bug like you. Mouse hover is different from drag-and-drop. Disabling mouse hover not disabling drag-and-drop seems expected to me.

Mouse hover annoys some users as it can be triggered without meaning too. Drag-and-drop is quite intentional usually, on the other hand.

Could you elaborate your use-case? You're dragging something, then you trigger alt-tab, and at that point you don't want AltTab to interact with the dragged item? Well why did you drag it first then? AltTab acts similarly to the built-in app switcher here. Dragging something right before using AltTab seems intentional to me, so i'm not understanding the use-case you're trying to solve here.

Hopefully you can shed some light on this~

Cheers 👍

[jeffbargmann]

Sure yeah; anticipated as this code did seem intentional.

It's particularly problematic because even if the mouse is still, the item under the mouse is still activated.

Use case is:

• Beginning state, in target application
• Switch to Finder window with folder open/files
• Begin drag file
• Attempt to alt-tab to switch back to prior application
• ⚠️ Alt-tab inadvertently selects the item under mouse
• I end up dropping file on wrong program, or these days, just then frantically re alt-tab'ing again and again until I can alt tab to the correct window. My choice is to either ensure mouse is entirely out of the way, or, mouse over to the window in the list.

Effectively, the keyboard can't be used at all if the mouse happens to be over Alt-Tab during the drag. 😬 In this scenario, you can press the keyboard command all you want, but app will instantly revert to the item the mouse is over. So anywho yes it just feels like with it as-is, we end up with random behavior (based on where mouse happens to be) upon hitting alt-tab key combo - as the idle mouse position ultimately takes precedence over the keyboard activity. Keyboard activity being the more explicit behavior, I'd think that would take priority.

*Extra nuance bits here, because #programming: "mouse activity" is a relative term i.e. might move a few pixels = active "technically" but not in practical sense. Worse -- one could also imagine of moving mouse towards anticipated drop zone of target app while using the keyboard command to switch apps; I'm sure I've run into this as well. Unexpected behavior as "mouse activity" moves current selection to random spot in list, user releases the keys and boom random window. The scenario there is the same as the use case above, except I'm just tapping alt-tab a single time for 1/100th of a second while moving mouse across screen... bam, the mouse activity "counts" even though screen was up for ~1 frame, and I end up opening a random window from the middle of the list. Even for folks with "mouse hover" enabled, this result probably still isn't desirable ha 😳

Thoughts?

[lwouis]

Oh, I understand better now! It's the dragging alone (without dropping) that's messing up your workflow here.

Just to confirm: you still want the ability to drag-and-drop onto AltTab, right? What you don't want is for dragging to select thumbnails, but you still want to be able to drop onto thumbnails to drop files onto apps, right?

That's tricky because we can't have a new preference checkbox "disable drag-and-drop" because you only want to disable the dragging-select-thumbnails parts of it. I guess using the existing "mouse hover" is fair in the sense that you have to hover when dragging, to select thumbnails.

My worry is for user who don't want hover, but do want visual aid when doing drag-and-drop. These users will have no aid, and will have to drop without feedback that they are hovering over the right thumbnail.

I wish I could come up with a better solution, but right now I can't imagine better than what you did.

*Extra nuance bits here, because #programming: "mouse activity" is a relative term i.e. might move a few pixels = active "technically" but not in practical sense. Worse -- one could also imagine of moving mouse towards anticipated drop zone of target app while using the keyboard command to switch apps; I'm sure I've run into this as well. Unexpected behavior as "mouse activity" moves current selection to random spot in list, user releases the keys and boom random window. The scenario there is the same as the use case above, except I'm just tapping alt-tab a single time for 1/100th of a second while moving mouse across screen... bam, the mouse activity "counts" even though screen was up for ~1 frame, and I end up opening a random window from the middle of the list. Even for folks with "mouse hover" enabled, this result probably still isn't desirable ha 😳

Please see my research here: #286. If you find a solution that doesn't have big downsides like discussed there, please write it down there~