Add options to MacOS menu bar menus

[nicknlsn]

Feature request: it would be nice to have things like server settings and layout accessible from menu options.

[qu1ck]

You probably mean the system menubar that only mac has. I agree that it would be nice but it's a very small benefit for a disproportionate amount of work, I'll leave this as a wishlist item.

In case anyone wants to implement this you would need to add menu items in macos.rs, add handlers for them in main.rs that would send a custom event to frontend, add handlers in frontend that would trigger corresponding actions.

[dukobpa3]

I can try to do it but let's discuss list of options in this menu, their grouping etc...

[qu1ck]

This is what end goal looks like for me, not everything has to be implemented at once:

TrguiNG menu

Create torrent... Toggle theme Toggle font size ? Change layout --------- Server settings Application settings --------- About Close window Quit

Torrents menu

Basically same as context menu

Window menu

list of current open tabs --------- Connect submenu -> list of unopened configured servers --------- current items (minimize, zoom, close)

It's been a while since I used MacOS so if the above is breaking any conventions it can be rearranged but from I recall there were plenty of apps that basically did whatever they wanted in menus.

Note that a lot of menu items would only work when the window is open even though the menu is still there when it isn't. So they would probably need to be disabled/hidden when window is not open. Keeping frontend and backend synchronized, updating menus and patching through the event calls will not be just a couple lines of code.

[Algwyn]

Native system menu bar items would be nice, but indeed not critical ... In term of menu structure, I would suggest the following:

trguiNG menu

Limit to app level actions. It would match the actions linked to these icons:

• About ---------
• Settings ---------
• Toggle theme
• Toggle font size ---------
• Hide TrguiNG
• Quit

Servers menu

• Connect submenu -> list of unopened configured servers
• Server settings -> settings of active tab server
• Turn alternative bandwidth mode
• Disconnect -> list of connected servers (or simpler, disconnect current tab)
• Add server

Torrents menu

Options in context menu would be great, but maybe too detailed. The top left icons actions would probably be enough and simpler to implement:

• Add torrent file
• Add magnet link
• ---------
• Other actions from context menu
• Start torrent
• Pause torrent
• Remove torrent
• Queue sub-menu (Move to top, up, down, bottom)
• Move torrent
• Tags
• Priority sub-menu

View menu

Actions from the Toggle button

• Change layout
• Toggle filters
• Toggle details

[Metal-Snake]

I want to do the necessary changes to the menu. Personally I was annoyed by the missing Hide command. Adding that was easy, works just fine. But for a PR I would do the full menu. But I don't understand how to add a command like "Add Torrent".

In macos.rs I added a menu entry with the ID "addTorrent", now what do I need to do in main.rs? I think I need the serverModal somehow, but no idea how to get it.

.on_menu_event(|event| {    
            match event.menu_item_id() {
                "addTorrent" => {
                    // get the serverModal somehow and call AddTorrent?
                }
            }
        });

[qu1ck]

There is ongoing effort to migrate TrguiNG to tauri v2 which will affect the code you are touching, you might want to do your changes on top of tauriv2 branch. Btw if you are a macos dev then fixing or at least root causing the crashes of tauri v2 version on mac will have more impact.

On the topic: the way you communicate with frontend is through events. You can't get specific modal from rust because "modal"s which are just html elements only exist in the frontend. The algo on backend should be like this:

1. Check if the main window is visible
2. If not visible, then show, wait for frontend to load (it sends listener-start event) and then
3. Send show-modal event with modal id as data

On frontend you add a listener to show-modal event to pop the corresponding modal in javascript. You can add the listener in Server component, just make sure to do it only in TAURI context (web app version of TrguiNG shares the same frontend code but obviously will not have any backend event system) Example https://github.com/openscopeproject/TrguiNG/blob/5509a2ff3dc9a51e992cad7942805b5ee3420f70/src/components/modals/servermodals.tsx#L107

[Metal-Snake]

I'm not really familiar with tauri and rust (yet?), but I will give it a try to check the tauri v2 branch.

For now I finally got the Open Torrent menu to work. Before I do the rest of the menu it would be great if you could have a look at what I did so far. I committed it here: https://github.com/Metal-Snake/TrguiNG/commit/15ea3650341b761c3e8342450aaef23f47b916d3

macos.rs: I replaced the CustomMenuItem "Quit" with a native one. Is that ok, or was there a reason to have it custom? Is there a reason why the app_name and "View" menus are created inline, using the fluent interface, while the others don't? Is one way favored over the other?

main.rs and servermodals.tsx: Is the code in the right place, coded the right way?

hotkeys.ts: The cmd+h hotkey to setPriorityHigh conflicts with the Hide command, so I changed that to ctrl+h for now. Weirdly, before my change, cmd+h and ctrl+h both triggered the setPriorityHigh event. Same for setPriorityNormal, setPriorityLow and focusSearch. But selectAll doesn't work at all cmd+a does nothing while ctrl+a moves the cursor to the front which is the emacs shortcut which are also built in into macOS . But maybe we can just not run that code block on mac when all those commands are added to the menu.

toolbar.tsx: Oh no more hotkeys. The cmd+o hotkey to toggleFiltersPanel conflicts with the new "Add Torrent" menu. I used cmd+o for that as it's the default for open file actions. I think it makes sense to change those hotkeys on other systems to, as ctrl+o is used for open basically anywhere. I'm in favor of using 1, 2, 3, 4 for those toggles. That would also be more compatible with non english keyboards. Like the "[" character is typed using alt+5 (mac) or alt+8 (windows) on German keyboards. So it just won't work as it is.

So, what do you think?

[qu1ck]

Your commit is headed in the right direction but you will have to redo it on tauri v2 branch because menu APIs changed in tauri.

I replaced the CustomMenuItem "Quit" with a native one. Is that ok, or was there a reason to have it custom?

Reason is with native item the app does not receive window close event and will not save the config. I could catch the termination event and have a custom handler for that but having a custom menu event is easier.

Is there a reason why the app_name and "View" menus are created inline, using the fluent interface, while the others don't? Is one way favored over the other?

No reason, whoever makes them consistent gets a cookie. I probably added them at different times or copied different examples.

Is the code in the right place, coded the right way?

Mostly, just do it on top of tauri v2 branch. Don't name the event "addTorrent", make it "openModal" and pass which modal as data of the event. You will also have to make sure other modals are not opened already when you extend this to more modals.

selectAll doesn't work at all

That's because macos needs native menu item for it to work, tauriv2 branch has this fixed.

I do agree about cmd+o, it is ubiquitous to mean "open" action. You can change current cmd+o to cmd+k. I'm not keen on changing other shortcuts. Ctrl/cmd+number is more intuitive to use as shortcut to activate corresponding tab. It's ok if cmd+[ is not as easy to type on alternate layout keyboard owners, it's not a frequently used option. The native Hide menu option should not be there at all, the app implements it's own hide logic and needs custom handlers.

[Metal-Snake]

It's ok if cmd+[ is not as easy to type on alternate layout keyboard owners, it's not a frequently used option.

It isn't "not as easy" but it's impossible because pressing cmd+alt+5 is something different than cmd+[. It just doesn't trigger.

The native Hide menu option should not be there at all, the app implements it's own hide logic and needs custom handlers.

Where does the user activate the hide logic?

I will have a look at the Tauri v2 branch now, and try to implement the changes as you mentioned.

[qu1ck]

It isn't "not as easy" but it's impossible because pressing cmd+alt+5 is something different than cmd+[. It just doesn't trigger.

And that is ok because the feature is used once or twice total.

Where does the user activate the hide logic?

It activates automatically when you minimize/close the window, based on your preferences.

[Metal-Snake]

hi, sorry for the very late reply.

Where does the user activate the hide logic?

It activates automatically when you minimize/close the window, based on your preferences.

I checked this, I understand what it does. It basically hides the window, but that is different from hiding the app. At least on macOS that's the case. By hiding the window, the app is still active, the menubar still shows TRguiNG, and shortcuts are still received by it. Hiding the app hides all windows of that app, and the last used app becomes the frontmost app that gets the focus. This missing shortcut was the reason why I even started looking at the code. It's a very essential feature on macOS. This really needs to be in there.

Communication regarding Tauri v2 happens in issue 231? Or is there a better place? So far I was able to build and run it, and found no problems in my short test run.

[qu1ck]

There is a different mode that doesn't hide the window but closes it instead, I'm assuming it will be more like what native macos hide function.

Communication regarding Tauri v2 happens in issue 231?

yes

So far I was able to build and run it, and found no problems in my short test run.

For me it reliably crashes when I close the app.

[Metal-Snake]

There is a different mode that doesn't hide the window but closes it instead, I'm assuming it will be more like what native macos hide function.

I saw that and tried it. But no, closing a window will not hide the app. Also you can hold down alt-key and click on the Desktop or any other app and the frontmost app will hide, doing the same as the native cmd+h shortcut. I see no reason to try to circumvent the native hide feature.

For me it reliably crashes when I close the app.

ha, I was just running and using it, not closing it. I will check and move further communication regarding that to issue 231.

[qu1ck]

I see no reason to try to circumvent the native hide feature.

Goal is not to circumvent it, it is to ensure that the app catches the hide event and performs necessary tasks. If you can implement it natively I'm all for it.