Floating menus to behave like a normal window + few other observations

Bugs or Unexpected Behavior
1

  1. I've tried to migrate a "floating webview" to a floating menu with "Web Item", however it seems it cannot behave like a normal window - at the moment I'm looking for a way to be able to move the window (the floating menu) to the next monitor, using the shortcut I'm using for all other windows + the "floating webview" but this doesn't work. The floating menu is configured with window level "Like A Normal Window (0)".

  2. If the window level is "Like A Normal Window (0)" the floating menu is opened, but behind the currently focused one. Is this expected?

  3. In my html I have the following function:

	    // Function to detect Enter key and copy the value
	    function handleKeyPress(event) {
	        if (event.key === "Enter" && matchedAccountIdElement) {
	            copyToClipboard(); // Copy the value and close the window
	        }
	    }

Which is working only partially - the copy is working, but not the close. I've tried "Close After Button Press" but it seems to not have effect. This is working great with the "floating webview".

  1. If I choose the floating menu to have a "standard title bar", it looks like that between the titlebar and the menu item, there's a space which is either transparent or the titlebar is not right next to the menu item, basically it seems that they are two separate UI elements (I guess they might be, but should not look like this). In the below screenshot you can see that that a part of the BTT icons can be seen:

image
image870×114 9.35 KB

I can use "Title Bar Overlaying Content" to ...workaround this, but in that case there's no actual titlebar which I can grab and move with the mouse if needed.

When using "floating webview", the window is ... whole:
image

Here's the floating menu:
accounts_floating_menu.bttpreset (6.4 KB)

I've removed "BTTFloatingMenuRenderedPreview", hope it is not necessary.

2

You can improve the layout by disabling spacing & round corners:
titlebar.bttpreset (22.8 KB)

In 5.264 I slightly changed the "Show Floating Menu" action so it activates the BTT process if "Activate Keyboard Focus When Showing" is checked - this should make sure that window level 0 windows are brought to front.

image
image2798×1606 323 KB

To close the floating menu via Java Script you could use

let result = await trigger_action({json: JSON.stringify({
  BTTPredefinedActionType: 387,
  BTTPredefinedActionName: 'Hide Floating Menu',
  BTTAdditionalActionData: '{\"BTTMenuActionMenuID\":\"accounts\"}',
}), wait_for_reply: true});
3

Yep, now the floating menu is shown infront of the focused one, but still cannot be moved using a shortcut.

Thank you for the spacing, I've played with it, but maybe I've missed something.

I'm not sure about the Java Script - how should I use it? The function I've pasted above is in my HTML file. My use-case is: once the floating webview is shown, I have a search field in it which will upon search will match and select a text from it, which on enter copies it and closes the floating webview

4

you could add the script after the "copyToClipboard()" call.

Moving the window via the standard actions doesn't work because floating menus in general exclude themselves from macOS Accessibility (this is important for menus that don't behave like normal windows). However maybe I can change this for the "floating menu with titlebar" usecase.

//edit, 5.265 should not exclude menus from Accessibility if they have a standard titlebar

5

With 5.265 there's not need of the JS and the shortcut works. Thank you!

One more thing - when "floating webview" is toggled, the initial state is shown, and with the floating menu, the last state (after a search) is shown. "Keep menu in cache" is not enabled.