-
-
Notifications
You must be signed in to change notification settings - Fork 355
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
Disabling mouse hover should disable mouse dragging as well #1617
Comments
Hi @GoranKrajnovic, Thank you for clarifying the situation with the video and additional text. I understand your situation now. Are you aware that you can drop the file onto the AltTab thumbnails directly? It will pass it to the app the same way it would if you dropped the file on the app's Dock icon, or on the app's icon in the built-in app switcher. Now think of people who actively use that workflow. It would be pretty bad I think if we didn't highlight the thumbnail under their mouse as they are dragging the file around. First, it helps them understand the drag-and-drop session can interact with AltTab, because there is a visual change, so it implies interactivity. Second, it helps confirms the drop target. And of course, the same users who don't like mouse-hover may want to do that workflow, that's why the preference mentions mouse-hover, not mouse-interactions (hovering, dragging over, etc). It seems like a dilemma to me. If we remove the useful interaction of dragging a file over the thumbnail, then we make the experience of these users worse. But I also understand your workflow where you would like to not have any mouse interaction with AltTab at all. First, wouldn't dropping the file straight on the thumbnail work for you? If your goal is to drag the file on the other app, maybe it would be faster to do that, rather than focus that app, locate the window, then drop on it? Alternatively, do you see a solution that would respect the other people using drag-and-drop on AltTab? I can only think of adding or refining the existing preference. We could either add a new checkbox
I think I prefer the additional checkbox here between the 2 options, but both are bad in my eye because this is a very niche feature, and I'm actively trying to not add more preferences to avoid the app becoming more cluttered than it already is (see #351) |
Hey, thanks @lwouis for the detailed reply and your thoughts! Actually I wasn't aware I could drop a file to the thumbnail of the window - now I understand why you didn't consider it a bug before (I totally didn't think of that). But that doesn't really fix my use case. My use case is that I'm actively alt-tabbing between two windows, let's call them A and B. So I'm frequently doing an alt-tab and not really looking at the thumbnails or searching for a window, I'm just flipping between the current and previous window. When I start dragging file to drop it from A to B, suddenly the brief alt-tab doesn't flip me into window B, but throws me into an unexpected window C. So my flow isn't about finding a thumbnail and dropping a file onto it, it's just about flipping back to the previous window B. If you don't want to add another checkbox, I guess you could also solve it by ignoring mouse hovering for the first 100 msec or so of an alt-tab event when a file is being dragged - so a short alt-tab would still flip to the previous window, and a longer holding of the key would work as expected for those wanting to drag and drop the file to the thumbnail they choose. The downside might be that this is a difficult to explain behaviour to the user, not sure how intuitive this is. |
I explored this idea and development it further in #286. Please see #286 (comment) for a recap of the issues with these strategies to avoid accidental mouse input. Nothing seemed like a clear winner, so I never moved forward with this. I kept the ticket open though, hoping someone more clever than me can share a breakthrough idea. |
I see, thanks. Well, for what it's worth, I vote for implementing a dropdown with the 4 options you suggested, in place of the current 2 checkboxes. |
I use alt tab to alternate between A & B all the time. That’s the primary benefit for me. I can see how the mouse cursor position could get in the way with that. |
# [6.53.0](v6.52.1...v6.53.0) (2023-02-09) ### Bug Fixes * don't focus window when dropping a file on it ([c386a0c](c386a0c)) ### Features * allow status item removal by dragging ([216c5d8](216c5d8)) * improve localizations ([7a30b18](7a30b18)) * separate mouse hover from keyboard selection ([3fb9a19](3fb9a19)), closes [#2078](#2078) [#1617](#1617)
Hey, so I originally opened #1583 which got closed as unreproducible and you asked for a video.
I've made a video showing the issue: https://www.youtube.com/watch?v=rnVc4Ge0sNQ
So to recap:
Option "Also select windows using: Mouse Hover" does not work correctly while dragging & dropping files. (Grab file in one window, hold it, alt-tab to another window, drop the file).
Specifically, I have the Mouse Hover option unchecked and it works for normal alt-tabbing. I do NOT want the mouse to select the window I alt-tab to.
However when I start dragging a file, and alt-tab to another window to drop the file there, the location of the mouse pointer chooses the window which will be selected. It behaves just as if the option "Also select windows using: Mouse Hover" is ticked active.
The video demonstrates this.
Video was recorded with previous version, but same behaviour is observed with 6.38.0, just tested this morning.
The text was updated successfully, but these errors were encountered: