BTT: Version: 5.158 (2025020202)
MacOS: Version 15.3 (24D60)
MacBook Pro M3 max 36GB
I have multiple app-specific floating menu with identical names. The reason is to use same trigger action to hide the app-specific flaoting menu. This trigger used to work, but no more after the Alpha 5.158 update.
Note:
Before bug reporting, please make sure you have tried the latest (alpha) version of BetterTouchTool and that you have already tried to restart your system :-). If you encounter a crash, please attach a crash log from the macOS Console.app from the "User Diagnostic Reports" section.
Describe the bug
A clear and concise description of what the bug is. Any bug reports that contain insults against me or my software will be deleted without warning (unfortunately this has become necessary to mention here).
the name/identifier must be unique to a specific menu. Otherwise all sort of things will fail in weird ways.
You can have multiple menus in different app / activation groups with the same name, however in that case they will be merged into one. A lot of BTT's floating menu logic depends on these identifiers
I could allow wild-cards for the menu name in these actions, that might be a good idea.
//edit: ah, I see now, the hide action doesn't work at all in app-specific menus? I'll check!
Yes, different UUIDs for each app-specific triggered menu, but the same name.
Given that there is only one visible active app at a time in MacOS, this method always works since the stable version of Floating manu is released - as far as I can remember.
in macOS yes, in BTT however you can have multiple "virtual" apps, i.E. Conditional Activation Groups or you can have the menu configured for "All Apps" and additionally in an app specific group.
If multiple menus with the same name are active, BTT will merge them into one. This is quite powerful as you can e.g. use it to define some base functions for all apps, then add items that only show up for specific apps.
However the hide issue was unrelated to that and should now be fixed.
(1) Thanks, after 5.159 the old trick's working again.
(2) I will experiment with with you suggest in near future, I think your method is more flexible and reliable.
I tested this method, and it's way more effective because I only need to maintain one set of common floating menus plus other app-specific menus or menu items! The idea of using ordering to line up the menus/menu items from different menus is fantastic.
I have now implemented the idea to full scale. But I'm not sure about the min height setting when I have to combine two floating menus of the same name -- one being the generic menu that always have the same min height and one being an app-specific menu that could have different heights for different apps.
I don't seem to figure out te best way to set the min height of the combined menu. Originally, I thought the logical way is that the min height of the combined menu should be the sum of the min heights for each menu, but it doesn't seem to be the case? I hope you can offer advice when you have the time.
maybe the "Fit Content" menu sizing mode can work for your case? (make sure to be on the latest versions for this, there have been some improvements recently)
It should also be possible to override the menu sizing behavior on the app-specific menus if this option is checked, however this is pretty new and the sizing options are the most complex.
I’m still testing the correct settings.
I set all menus to non-scrollable, and I check the option of override global menu’s setting of the same name for each app-specific menu, in which their min height’s value are all larger than the common menu.
The outcome is a bit unstable: all combined menus show up normally when BTT’s restarted, then sometimes the combined menu will shortened to the height of the common menu after a few app switching. Restating BTT will bring the height of all combined menus back to normal, but it will happen again after a few app switching.
It’s not urgent, I can live with that. Just FYI
P.S. Given the complexity of BTT, I'm aware that adding every new setting option can means a chain of changes in the codings. IMHO, it would be very useful to us if the "Menu Size" section can have both max width and max height, with the 2 options, the "Layout/Scroll Direction" will be able to provide "Fill row, uses max width, then continue to next row", and "Fill col, uses max height, then continue to next row".
