Menu should not close systematically after a selection

[mbolo01]

Dear "tlk"

I think that the drop down menu should stay unless another area of the screen is clicked, where currently it closes after an action is chosen.
E.g. for a previously selected product, If i want to select a radio and change the volume consecutively, I have to (1) select the B&ORemoteGui icon in the menu bar, (2) select a radio, (3) select the B&ORemoteGui icon in the menu bar (4) choose the volume .... and assuming the volume chosen is not good, (5) select the B&ORemoteGui icon in the menu bar and (6) reposition the volume.

[tlk]

I have adjusted the app since this issue was filed, so the menu does not automatically close when the volume slider is moved. Note that this differs from how the built in volume slider works.

Changing the behaviour for menu items is not desirable in my opinion, as this would go against the Principle of least astonishment.

Suggestion for the use case sketched above:

1. select BeoRemoteGUI in the menu bar
2. select a radio station
3. press F11 and F12 to adjust the volume

Please note that radio stations can be changed by pressing F7 and F9.

[mbolo01]

I appreciate the volume behavior change, thanks for that.
Maybe you could improve the user experience when no device is selected or when the only action performed is to select a device?
Case 1: I want to start a source on device A, I start the app and no device is selected yet. I choose device A, the application closes, I open the app again, device A should be selected an I choose my source. I think the app should remain open until I have sectes a source and an action.
Case 2 : I want to select a source on device B, I start the app, device A is selected, I select device B, application closes, I start app again, application B is selected, I select a source. I think the app should remain open until an action other than selecting a device has been performed.

[tlk]

I am with you - fewer clicks are better!

The menu widget closes automatically when an item is clicked and this is common behaviour for all menus in macOS. I am not sure it is possible or desirable to change this behaviour, however as an experiment I have added a small work-around that will re-open the menu when a device is selected.

[tlk]

An alternative approach is to restructure the menu.

The "Sources" submenu and the device menu item could be merged, such that each device would be displayed with its own submenu. This would allow the user to move the cursor over a device menu item to open its submenu and then click the source.

Now, changing the device menu item(s) to have a submenu means that there would no longer be an easy way to change the device without opening the submenu and picking a source. Not sure how to solve this in a good way. Could add a menu item to the top of the submenu called "Select this device" (or "Control") but not sure if that adheres to the Apple Human Interface Guidelines.

[mbolo01]

I was about to propose something similar to your alternative approach, but your small work-around is clever and does the job IMO.
Trying to introduce menus / submenus may add user perception complexity.
Let me see if the work-around has caveats.
Regarding the code, I still have to do the manipulations you sent me (remove package, cleanups, reload) in order to be able to compile the newest code with Xcode, is is expected?

[tlk]

Agree, let's leave it as is for now - but I am definitely open for suggestions on how to improve this.

Regarding the build-issues, they should have been solved once and for all by the instruction. Perhaps Xcode needs to be closed while cleaning the folders, but I am not sure. Let's track that in its own issue.

[tlk]

Bonsoir Jérôme,
By the way - just wanted to mention that the previous/next device can be selected with F1 and F2 hotkeys. As the devices are sorted alphabetically there should be some predictability in which device you connect to, but honestly I am not sure how usable this is.

Finally, I don't know if you are already using the devices.default property (see example) but it can be used to auto-connect to a certain device when BeoplayRemoteGUI.app starts or loses connection to a device.

EDIT: the app has ben adjusted so it auto-connects to the device it was last connected to.

Best,
Thomas

[mbolo01]

Bonsoir Thomas,

Using the Fn to jump from device to device requires to remember which device is currently selected by the app, if any. So usually I open the app for that. I have 6 devices, 3 starting with the same letter, which means that I have to think about the second letter for the sort order .... I'm too old for that :-), but the feature is nice when you have a good memory, a naming logic made for sorting or a reduced number of devices.

I'm not using the "device.default" as the one I would use is powered off every night, while the app isn't. As we had an issue previously with down devices, I never tested this feature since and I rely on discovered devices only. I'll try this feature and provide feedback.

Regarding re-arranging the items, Apple's menu logic is to allow only one single action after items' navigation where the requirement here is to (1) select a device and (2) perform an action against the selected device in one session which counts for two actions from an Apple logic perspective. I had a look at several app menus and one way could be to popup a window when a new device is selected. This popup window would enable setting the source or TuneIn for this device as well as the desired volume. This device would then become the default device for the app for subsequent actions.

Kind regards,
Jérôme