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

TrguiNG/src/components/modals/servermodals.tsx

Line 107 in 5509a2f

if (TAURI) {

[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: Metal-Snake@15ea365

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.