The first alpha with Floating Menu support has just been released: 4.076 https://folivora.ai/releases/btt4.076-2292.zip
The floating menus / widgets have been an idea I have been thinking / working on for quite a while. My first experiments have been based on webviews, which unfortunately came with some disadvantages so I moved away from that approach again. Now since macOS 13 SwiftUI has become pretty powerful and I was able to implement the floating menus using that technology. I'm pretty happy with this now, so I'm releasing the fist alpha version to the public.
There are still many things missing, but now that I have a working base, it should be fast to iterate on this.
Things I'm still working on:
- Various Widgets (e.g Weather, Dock, Clipboard)
- Keyboard navigation
- Sub menus (currently basic support for 1 level of sub menus is there, but this will be improved)
- Plugin system to allow arbitrary SwiftUI views to be added
- Performance improvements
- Long press and other click variations
The floating menus will also be the base for the new BTT Remote for iOS. (So you can show them on your iPad/iPhone and control your Mac). In the future the existing Notch Bar and the Stream Deck implementation in BTT will also migrate to be specialized versions of Floating Menus.
1.) A floating menu that shows up when hovering the Notch of a current Macbook:
NotchMenu.bttpreset (28.5 KB)
2.) A floating menu attached to the side of the currently focused window. It expands when hovering the pill shape.
MiniEmojiMenu.bttpreset (45.6 KB)
3.) Menu showcasing how to run scripts & use modifier keys
ScriptExamples.bttpreset (109.8 KB)
This looks really, really promising. Thank you very much!
A lot of options and settings... that's good! But it takes time to try everything.
Some things I probably do not understand yet. For example, this action should show/hide a menu by name with a shortcut? That does not work here. Otherwise everything works so far.
For Show/Hide use the "Toggle" action instead:
Definitely! I'll work on documentation and various examples. Many options are necessary to cover as many use cases as possible.
I had assumed that the modifiers
give the possibility of "different layers" for the same floating menu. As it is the case with the Notch Bar. Without modifiers I see one layer, with modifiers another. But I don't understand how this works right now.
With the Notch Bar, the visibility (with/without modifiers) can be set for each item. With the floating menus only for the whole menu. So, I can not have a menu open, press and hold cmd so that I can see other buttons?
The modifier thing should now work similar to the Notch Bar in v4.077!
Mm, I'm sure it's me, but unfortunately I don't understand how. Also in v4.077 the "modifier thing" applies to the whole menu, not to the individual buttons as is the case with the Notch Bar.
The menu has separate modifier key settings, maybe you are currently looking at these?
Here is an example menu:
modifiers.bttpreset (36.5 KB)
Yes, I overlooked the right ones ... there is so much to see
Thank you, Andreas!
The horizontal option causes BTT to crash.
weird, could you check whether there is a crashlog?
It seems to work fine here (example preset:
horizontal.bttpreset (35.7 KB))
Is there a possibility to keep a hovered window open and close it only upon a specific command? The use case is that I would like to execute multiple buttons consecutively in a hovered window without closing it being closed and then minimize it afterwards.
How can I remove icons that have been assigned to buttons when not needed/wanted any longer?
Yes, disable this option and instead add the predefined action "Hide Floating Menu" to your action sequence
This button will remove the icon again:
What's cool ... BTT hyperkey can trigger a named trigger when the key is released.
So if you use hyperkey, you can make a floating menu appear by pressing and holding caps lock ... then click something or a lot ... as soon as caps lock is released again the menu closes.
Somehow it's not working, or I expressed myself wrongly. The concept is to dock a hovering window as a drawer. When the mouse hovers over it, it should remain open until a command arrives to close it. All button actions should not trigger the window's closure. I have disabled the feature as shown in your screenshot, but as soon as I move the mouse away from the hovering window, it closes again.
Ah, I see. That's not yet possible. You can adjust the time until the menu minimizes again, but you can not prevent it completely. I'll add an option for this.
that would be awesome. thanks.