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.

6

Hey @Andreas_Hegenberg , I'm trying to create a floating menu with a single textfield item. I want the text field to be focused/to steal the keyboard when the menu is activated, but this is not happening. I've tried the "Steal Keyboard Focus On Show" in the menu's setup and also the "Activate Window & Steal Keyboard Focus" in the action's configuration, but still the text field is not stealing the keyboard. Am I missing something?

I've just restarted BTT and upon the initial show the field is focused, but if I toggle it the field is no longer in focus.

Also is there a way to clear the text field on toggle?

7

There was indeed no good way to focus standard text items.

Could you check whether it works with 5.412 alpha when using the show floating menu action like this and checking the "Has Initial Focus" option for the text field item?

image
image3026×1894 403 KB

image
image3026×1894 352 KB

8

Yep, this solves it. Thank you!

9

The below is related to the initial floating menu which I've migrated from a "floating webview", and not to the menu with a textitem from my last comment.

Basically issue is like point 2 in the 1st comment, but it is "fixed" with a toggle:

It seems that if the window level == 0, the initial show of the menu is happening, however the window/floating menu is behind the currently active window. This stop happening after 1 or 2 more menu toggles. If the windows level is higher - no such issue, but the text field (configured inside HTML file) is not focused.

10

weird, the show action is set to "activate window & steal keyboard focus"?

11

Yep. Upon toggle few times, menu is being brought to front on and focus + keyboard are stolen.

12

do you have the autofocus text field option enabled on the webview item?

image
image1994×2026 301 KB

13

Yes. In the html file I have the following as well:

	<input type="text" id="searchInput" placeholder="Search for account names..." onkeyup="searchFunction()" autofocus>

		// Automatically focus the search input when the page loads and add keypress event listener
		window.onload = function () {
			var searchInput = document.getElementById("searchInput");
			searchInput.focus();
			searchInput.addEventListener("keyup", handleKeyPress); // Listen for "Enter" key press
		};