Trigger key behaves as if it was held, even though it was pressed just shortly #633
Comments
|
Demo video. Note to interpret demo video: the interesting part is between 00:01 - 00:05. There, a single short press of Cmd+Tab triggers many forward movements in the AltTab grid. I do another Cmd+Tab at 00:07 - 00:11, but this time I hold Cmd+Tab down. Note the difference in the KeyCastr overlays in the lower left corner. When I hold the Cmd+Tab in the second instance, it displays a lot of repeated overlays, while in the first instance it only displays one, since it's just a short keypress. |
|
This has happened to me too recently. +1 on this issue. |
|
What refresh rate do you have on your screen? I just tested on a 240hz screen and the repeat rate is way too high. The reason is that I aligned it to the screen refresh rate. I'll replace it with a fixed Could you please try this preview build and tell me if that behaves better for you? |
|
I am convinced the issue I am facing has nothing to do with the monitor refresh rate. Maybe that is also an issue, but this is different. I use an external UHD screen which runs at 60Hz and there's additionally the screen of the 16" MacBook Pro (not sure about the refresh rate, but I guess it's similar). When the windowing system is not under load, everything runs nicely. When under load, the new way of handling keyboard shortcuts produces this behavior I described, quite consistently. I managed to trigger this behavior with almost every invocation of AltTab, when the windowing system is under load ( |
|
+1 from me too. |
|
Oh then it could be that the repeat timer i used has too much I'll look into that |
|
I just checked, and there is no I'm not sure what's happening. I'll continue investigating |
|
Does the issue happen with backward cycling (i.e. |
I never trigger AltTab directly with backward cycling. I trigger it forward cycling and maybe later do a few backward cycling steps if I overshoot. Is it even possible to trigger AltTab backward cycling? Because this issue happens when triggering AltTab, not after it's already open. |
## [6.7.2](v6.7.1...v6.7.2) (2020-10-06) ### Bug Fixes * crash in rare unknown scenario scenario ([08581f5](08581f5)) * crash on blacklisted app with main shortcut cleared ([c3f0686](c3f0686)) * ignore more non-user-facing apps (xpc processes) ([8417564](8417564)) * key repeat rate was too fast on high fps monitors (closes [#633](#633)) ([b408f14](b408f14)) * keynote was not showing while in slideshow mode (closes [#636](#636)) ([ec7b69f](ec7b69f)) * space transition sometimes absorbed the shortcut (closes [#588](#588)) ([5e6a0c2](5e6a0c2))
|
Just to follow up on my experience of this, I'm noticing it under slightly different circumstances (as detailed in #588): notably in my case though I've already released all the keys, including the modifier. I've also noticed that when it occurs it makes it difficult to reliably select the correct window using the mouse as it keeps cycling through. And hitting the escape key (which used to hide the UI without switching), instead now always selects the currently highlighted window. |
|
Since many times I can see the selection changing in front of my eyes, with the AltTab grid doing a repaint in each of these grid position advancements, possibly at 60fps–certainly fast enough for me to see an absolutely fluid movement of the selection rectangle to the very end of the grid–, I would be very surprised if this was about thread scheduling. To repaint the grid really fluidly, that would involve a lot of CPU cycles, orders of magnitude more than what it would take a delivery of a key event. It feels much more like a missed event. Strangely, some times AltTab pops up–after a short trigger combination keypress–with the selection stopped (i.e. not moving forward 60fps like crazy), but not at the second item in the grid–as you would expect–, but somewhere in the middle. That means that the key release event was certainly delivered. It feels like the position where it stops depends on the duration it took for the OS to bring up the AltTab grid. The appearance of AltTab in these cases feel delayed, like in those cases that were partially mitigated–but not entirely solved–by the thumbnail refresh being partially done in the background asynchronously. Could there be such a relationship? Do you have any part of the code where you calculate the number of key repeats based on timestamp deltas? If yes, that could very well be one part of this issue. The other part being, where the key release event seems to be missed entirely. This issue looks and feels like a combination of two different issues, both possibly happening in a windowing system under load. Sorry for the complex sentences, I know it makes a difficult read. I tried to simplify my thoughts about the issue as much as possible, but I couldn't think of a better way to describe what I am experiencing. |
|
@lwouis the bug is still present. I had it less often though, but I cannot tell whether this is due to improved code or because I didn't push my system as much as when I originally stumbled upon this issue. I lean on the latter. |
|
I'm having the same issue again even in the local build. The local build did manage to fix #603 somehow. The issue happens particularly often when my computer is slowed up with tons of apps running. Not sure if thats relevant, but I added it anyway. The laptop I mostly use alt-tab on is a late 2013 Macbook air, and it has 8 gigs of ram and 2? cpu cores. |
|
First of all thanks for the great application! 😃 I'm not really sure if this is related but I have the feeling that selection with Alt+Tab is quite sensitive. Sometimes I miss the window because I likely pressed Alt+Tab a few milliseconds too long. It would be nice to have a configurable "lock in" value that waits for the specified time until the next Alt+Tab is triggered. Imho it should behave more like the native Cmd+Tab switcher. |
|
Hi @svenjacobs! AltTab uses the System Preferences > Keyboard values for the initial delay before repeat, and for the repeat rate once it starts repeating. I think it makes sense that way. It should be the same values as the default app switcher. Try modifying those and see what you like. You could also modifying these 2 values specifically for AltTab by using some command lines. Any setting in System Preferences can be applied to 1 app with different values basically. This is how Apple designed User Preferences. I didn't think it was worth the added complexity added to end-users to expose this. Was I clear? I'm on the phone so hard to do a long reply with links and more details 😅 |
|
Also i think this issue is done. I'm going to close it. Please let me know if the issue is still relevant. I assume it was fixed somewhere in the past month. (I'm talking about the OP, not some other issue) |
|
@lwouis While I'm not sure if this can be completely fixed, can we have an option to turn off the key repeat feature, just like the older versions of AltTab, please? 😅 |
|
Thanks for the reply @lwouis 😃
It feels different and repeat is definitively much faster for AltTab than for the default app switcher.
I have no idea how to do this. Could you please explain? 🙏 |
I'm also getting the same issue in 6.9.0 with inconsistent triggering of Alt-Tab |
Unfortunately it's still present. I had to revert to an older version because of this issue. |
|
@SoPat712 @jaekyeom I'm wondering if you are all talking about the same issue from this current ticket. Do you both experience exactly the behavior that @nfekete showcased in the video above? The issue being:
I want to be sure that we are all talking about exactly these symptoms. |
|
@svenjacobs could you try playing with these 2 sliders in
Left one is how fast the repeat rate is when you hold a key. Right one is the initial delay when you hold, before it starts repeating. |
Yes, I am receiving the exact same behavior at random times. I, like @nfekete have a ton of windows open, and it just instantly switches through every single one of my apps without stopping. |
Yes, changing these values chances the behavior of AltTab. |
|
Just chiming in with another +1 from me, I'm still experiencing the OP issue occasionally on 6.9.0 (albeit much more intermittently than when first reported with 6.7.0). I hadn't even thought previously to play with the global or per-app*see below settings to see how AltTab reacts. I've since realised that AltTab only respects the settings with the I don't know if (but somehow doubt) it's related to whatever's causing the OP issue, or something worth filing separately - it's hardly a dealbreaker in terms of functionality as you (rightly) can't invoke the UI directly with the backward shortcut. The OP issue happens so infrequently for me that I've not been able to gauge if / how turning the repeat off might affect it - which may help other users who are holding off on updating because of it. Just thought I should report here as you'd mentioned it replying to @svenjacobs question. And also as I was previously considering asking if there's any way of turning off the key repeat entirely. The per-app setting would appear to be exactly that, subject to working consistently for forward- and backward-cycling. *For anyone else previously unaware (like me 2 days ago), the settings can be changed per-app via the command line with:
A quick gif to illustrate the behaviour: (I was going to use KeyCastr but thought it's press&hold behaviour was confusing for the issue at hand so please forgive the description)
|
Thanks, I didn't know this 👍 |
It's an open question. Some apps for instance show an option to switch the app language (e.g. your whole macOS is in French, but you want that 1 app to show in English). Most apps though, only read the user's preferred language in the System Preferences, and display in that language, with no option to change it for that specific app. Is it a problem? Probably for a very small subset of users. Should AltTab expose an override for the system language, the dark/light mode theme, the scrollbar being always visible or auto-hide, etc, etc? It's an open question. In this specific case, it seems you want keyboard repeat to be at a different speed only in AltTab. Don't you want the same repeat speed in all apps, so you can have it predictable and get used to it? How many other users want to customize that global preference? I could add additional UI to enable that more easily than through the macOS built-in terminal way. Is it worth the added complexity? If I added all preferences for all possible lever, the app settings would be 10 tabs and people would tell me to simplify it. Preferences are a hard problem. Usually I wait for at least 2 people requesting one before considering it. I also put no spyware in AltTab, so I have no idea how people use the app, and what preferences they set in a statistical sense. Anyway, I hope I gave you some elements of answer and perspective. Update: I realize now that maybe you meant to expose these, so people can disable key repeat all together? If I would, then I would expose a toggle to disable it, not a number people would have to set to 30000. However, I don't like the idea of exposing a toggle off instead of actually fixing the bug. It seems to happen for a small number of people. I feel the people in this thread have now 3 options: apply the workaround listed above to fix the case on their machine, try to help reproduce/understand the issue so it can be fixed for everyone else, or both. |
|
I see your point. I don't think apps should offer configuration for any preferences like language etc. but in case of AltTab key repeat is directly related to the user experience.
Not in this particular case. I want to have fast key repeat for my IDEs and editors but have it a bit slower for AltTab. As I said before - and I don't know why - key repeat for the default app switcher is definitely slower and doesn't seem to be related to the system setting. I immediately noticed this when switching to AltTab. The values are different than what I'm used to all the time.
No, not in my case. I just want to slow it down a bit. |
On my system, they are the same. Could you please share a video (at 60 frame-per-seconds if possible) so we can see it motion? |
This is my ideal use case also, but it's a niche enough requirement that I wouldn't expect it to be implemented at the expense of extra programming effort, especially if there's a way around it as we've discovered.
From my POV, I'd vote for leaving it out and just setting via the CLI defaults rather than adding further complexity - as ever it's a matter of documentation. @lwouis is there anything we can do on that front to help? You've put so much effort into this and I see many issues filed and then closed after a single helpful reply from you, where someone doesn't understand some particular setting / added bit of functionality and you have to explain. A wiki would seem to be the way to go (and something I'd be happy to assist you on), but people are people and who even reads the instructions (😬 😆 )? And as the functionality is constantly evolving, where would we even start with structuring etc., not to mention providing language-independence / localisations like you've done in the app itself. I was generally aware of user defaults either for System Prefs or for tweaking functionality and settings provided by individual apps, just hadn't put 2+2 together that you could apply the concept across the 2 domains like that. Well, I learn something new every day. Mostly from this repo tbh 😄
I've not noticed the OP issue yet since changing this setting yesterday, although it was pretty infrequent beforehand anyway. The only consistent thing when it happened previously was moderate (or higher) CPU load. Will keep an eye on it and report any further findings.
Same here, although I swear I remember the same behaviour @svenjacobs described prior to messing with the System Prefs and defaults over the last few days.
I've since tested a bit further and realised the default switcher exhibits the same ignorance of I realise this is all very esoteric, doesn't require any fixing on your part and is probably unrelated to the OP issue. However, somehow with AltTab the forward-cycling just never repeats, indicating that AltTab is definitely handling things differently - leading me to wonder could the OP issue be related to ShortcutRecorder itself? Apologies if you've already considered / investigated that possibility, I'm just spitballing ideas. |
|
imho AltTab doesn't need a UI for adjusting key repeat if the |
Okay, I have to correct myself. It seems that after playing around with the system settings the behavior of the default app switcher is now in sync with these settings. Maybe the switcher was using some old system default settings from a few macOS versions ago (I never changed the values) 🤷♂️ |
Yes of course! You can contribute to improve the website. There is a list of things that would be nice here already #211, but you could focus on adding a new "Manual" section with screenshots and explanations of the app. Maybe a video. As you have mentioned though, documentation is unhelpful in general. The same kind of people who need it are the kind of people who don't read manuals, so it's an ineffective in my experience. A more productive approach would be something like #351 (comment). Preferences with more visuals, illustrations, clarity. Even then, only a fraction of users look at the preferences I think. Another layer that may reach those users is something around #85, which could be showing overlays/tooltips on first launch, or after N launches, to try to teach users about available preferences, and tips and tricks. I hope I gave you some ideas of things that you can contribute if you're interested. Let me know if you'd like more details to get started 👍
I can't believe the default app switcher actually has such a bug! AltTab however properly follows user preferences. You said "exhibits the same ignorance of...". I'm confused because on my machine if I turn off the repeat keys, AltTab never repeats in any scenario (unlike the built-in switcher). Could you please share a video to show what you're experiencing? I'm thinking that perhaps the specific shortcut or keyboard you use may be both the reason of this specific edge-case, but also the OP issue. AltTab implements completely custom repeat. Normally pressing a key triggers an OS-level repeat. That is, the OS sends AltTab the key multiple times, with an attribute so that AltTab can know it's a repeat, not a actual key press, but still AltTab receives multiple events. That whole process does not happen with certain shortcuts, for example |
It's possible that the built-in switcher doesn't listen to changes while it's running, and changes would only reflect after it is restarted. Listening to user preference changes is extra work. I know that well since AltTab listens to many things, and it adds significant complexity to have the user be able to update things plug-and-play and have the app handle all sorts of exotic situations in a clever way. |
This is what I was attempting to show in the gif at the bottom of this post. Having played with EventTaps in the last few weeks I was vaguely familiar with how key events are conveyed by the system, ie a press, multiple presses with a repeat flag while held, and then a release. You mentioned the end-of-list behaviour, and this part actually always works (including when I've experienced the OP issue). I guess these OS-level repeats are what KeyCastr is actually showing, so I made a video to hopefully better illustrate. Weirdly, updating the SysPrefs GUI Weirder still, clearing all 3 of these relevant global defaults with The behaviour is even more complex and difficult to describe clearly when I start setting per-app defaults for AltTab. It feels like I've hit on some edge-cases where it's missing a check on one defaults value when the other is updated, but my head hurts from trying to work out the full logic of it 😅 . And as to why it's only for the backward shortcut, I'm absolutely stumped.
I'd had the same thought with regard to the bluetooth keyboard I generally use (Logitech K380), or possibly some weird interaction while BTT is enabled, or even just my choice of keys. However I've tested with a bunch of different combinations of all these factors and this repeat bug seems to happen consistently regardless of any of them - even with an Apple A1243 wired keyboard. The only exception to this is if I change to use a modifier+modifier shortcut for TL;DR - For me, and only ever for the backward shortcut after the UI has appeared, AltTab is apparently:
Obviously there's a load of other combinations that I didn't test (or at least got too confused while doing so), and very few of them would reflect real-world usage. Does AltTab update its read of both values whenever either one is changed? It would also have been helpful for describing all this if Apple had named the Update: I don't tend to use the arrow keys with the UI so hadn't thought to test them before, but they exhibit the same erroneous repeat symptoms as I've described here for backward switching. So do hide (⌘H) and minimise (⌘M). The latter also seemed to crash the UI (spinning beachball and unresponsive to keys or mouse) as it tried to minimise and de-minimise the same windows over-and-over. I had to killall from the terminal, but AltTab didn't ask if I wanted to send a crash report when I reopened. I've tested again and the repeating happens irrespective of changing them to non-standard keys. I'd already changed the quit and close shortcuts to incorporate an additional ⌥ and stop myself invoking them accidentally, you'll understand if I'm not eager to test those as well! I'm wondering if UX-wise it's not better to exclude these 4 "window operations" shortcuts completely from repeating, regardless of the rate. Although if the problem is specific to my setup it's likely you'd already intended that to be the way it works. |
|
Closing as duplicate of #719. Let's continue the discussion there 👍 |
I have Cmd+Tab set up as a trigger key. With moderate system load, many times when I press the trigger key combination and hold the modifier key, the trigger key is registered as if it was still held and the key repeat kicks in. Expected behavior would be that the AltTab grid opens with the previous window selected in the grid, i.e., the second element in the grid. Actual behavior is sometimes selecting a random element in the grid multiple positions away from the expected grid element, sometimes, scrolling to the very end of the list and stopping on the last element.
When this bug occurred, I had moderate system load with quite a few open windows, WindowServer constantly using about 30% CPU time of a core in a 12 virtual core (6 cores x HyperThreading) system.
I am running 6.7.0, so the new keyboard handling mechanism is in place. With the old keyboard handling I never experienced this issue. It feels as if the key release event was delivered delayed to AltTab or not delivered at all.
The text was updated successfully, but these errors were encountered: