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
Revert "BugFix: Repairs shortcuts to work 100% of the time" #5427
Conversation
This reverts commit 596bf57.
Hey there! Thanks for helping Mudlet improve. 🌟 Test versionsYou can directly test the changes here:
No need to install anything - just unzip and run. |
clang-tidy review says "All clean, LGTM! 👍" |
Closes #5429. |
TBH I am not convinced this is a fault of #3994 as that was just making OUR shortcuts work again - and then they are triggering this issue. I have seen it before, and I said so in Discord see https://www.discord.com/channels/283581582550237184/283582068334526464/853278452416118834 :
a follow-up message I posted shortly thereafter expanded on this https://www.discord.com/channels/283581582550237184/283582068334526464/853324221387767829 :
Notice how I say I temporarily redesignated one that was clashing (the compact input line one of |
@Faenriis do shortcuts in PTB work for you again now? |
Yes, my develpmnent branch build and PTB are working again as they used to in 4.12. Sorry for not reporting it right away, thought that lack of my complaints would autmatically state that it works, I'm lazy. 😝 |
…again This should close Mudlet#3985, and *finally* Mudlet#649! I was prompted to look into this as a result of what @demonnic reported in: Mudlet#5715 (comment) Previously the code was attempting to detect whether the main menu bar itself was actually visible and using that to determine whether EITHER: "key sequences" should be assigned to menu items and have the menu items activate the desired slots (menu bar shown) OR: "key sequences" should themselves be assigned to shortcuts that directly call the desired slots (menu bar hidden) This PR instead uses a state variable (boolean) and uses that to record whether the menu bar is visible and only perform the changes required for the above alternatives if the state is changed (or has not previously been performed). There have been several past attempts to get the short-cuts working: * Mudlet#2071 monitored the state of the main toolbar and NOT the menu bar * Mudlet#3994 changed to monitor the state of the menu bar but only enabled (menu shown) or disabled (menu hidden) shortcuts that were assigned key sequences and those shortcuts were connected directly to slots yet the key sequences were assigned to menu items that themselves were ALSo connected to the same slots. * Mudlet#5427 reverted Mudlet#3994 so the code went back to that of Mudlet#2071 Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…again (#5723) This should close #3985, and *finally* #649! I was prompted to look into this as a result of what @demonnic reported in: #5715 (comment) Previously the code was attempting to detect whether the main menu bar itself was actually visible and using that to determine whether EITHER: "key sequences" should be assigned to menu items and have the menu items activate the desired slots (menu bar shown) OR: "key sequences" should themselves be assigned to shortcuts that directly call the desired slots (menu bar hidden) This PR instead uses a state variable (boolean) and uses that to record whether the menu bar is visible and only perform the changes required for the above alternatives if the state is changed (or has not previously been performed). There have been several past attempts to get the short-cuts working: * #2071 monitored the state of the main toolbar and NOT the menu bar * #3994 changed to monitor the state of the menu bar but only enabled (menu shown) or disabled (menu hidden) shortcuts that were assigned key sequences and those shortcuts were connected directly to slots yet the key sequences were assigned to menu items that themselves were ALSo connected to the same slots. * #5427 reverted #3994 so the code went back to that of #2071 Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…again (Mudlet#5723) This should close Mudlet#3985, and *finally* Mudlet#649! I was prompted to look into this as a result of what @demonnic reported in: Mudlet#5715 (comment) Previously the code was attempting to detect whether the main menu bar itself was actually visible and using that to determine whether EITHER: "key sequences" should be assigned to menu items and have the menu items activate the desired slots (menu bar shown) OR: "key sequences" should themselves be assigned to shortcuts that directly call the desired slots (menu bar hidden) This PR instead uses a state variable (boolean) and uses that to record whether the menu bar is visible and only perform the changes required for the above alternatives if the state is changed (or has not previously been performed). There have been several past attempts to get the short-cuts working: * Mudlet#2071 monitored the state of the main toolbar and NOT the menu bar * Mudlet#3994 changed to monitor the state of the menu bar but only enabled (menu shown) or disabled (menu hidden) shortcuts that were assigned key sequences and those shortcuts were connected directly to slots yet the key sequences were assigned to menu items that themselves were ALSo connected to the same slots. * Mudlet#5427 reverted Mudlet#3994 so the code went back to that of Mudlet#2071 Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Reverts #3994.
It causes a regression: