Move less used actions from main context menu in submenus

[teamcons]

Problem

Less used actions, such as "Send in mail", create noise when looking for common actions such as "Move to trash" or "rename"

Proposal

Identify a list of actions that could be moved into a "More actions" submenu, below of "Open with"

i may edit this FR once i have access to our eOS puter, but off of the top of my head:
-Send by email
-Create shortcut

This would make the file manager more focused, and in the same breath provide room for extending it

Prior Art (Optional)

Nemo, in Cinnamon, has a "More tools" where user can expand with community-made "Actions"
Nemo and Nautilus have a scripts folder, allowing users to create custom actions on files via shell scripts

[jeremypw]

I agree the context menu for file items has become rather long. I think most items provided by contractors and plugins could be moved into a subfolder. These include "Send by Email", "Send by Bluetooth", "Compress", "Apply color tag", "Set as Desktop background/Wallpaper". Incidentally I noticed there now seems to be two items that do the same thing (set the background) so that needs sorting out. I'll raise a separate issue for that.

Flagging for design team input before implementing.

[teamcons]

Okay i think ill try my hand at this. But tbh doing a design seems to me much slower than doing the actual code and posting a screenshot of the branch in action
so ill try the latter

[jeremypw]

@teamcons I'll be glad to review code but it'll need sign off by @danirabbit . Thanks for contributing to Files.

[teamcons]

No promise, im already struggling to locate the necessary snippet of code to amend

[jeremypw]

I would start by looking at the show_context_menu method of AbstractDirectoryView. Plugins append their own items to this menu.

[danirabbit]

Couple things to keep in mind:

After the Gtk4 port we'll have a lot more layout freedom with popovers so some actions might be better done as image buttons which take up less space

I think in the future we probably will want some kind of portal-provided "share sheet" so that sandboxed apps can access things like "open with". It might make sense to think about which actions are specific to Files and which things should be available too any app sharing/exporting data and separate those things into a new "sharing" dialog to kind of prototype that. There's some prior art from other platforms in the portals repo I think

I think the way the context menu is built right now relies on GTK.menuitem pretty heavily so generally this will all have to be rewritten to use actions for the gtk4 port. So any work here should probably make sure it's not making that port even harder

[jeremypw]

Yes, you probably have to accept that any Gtk3 code you write at the moment might have a limited shelf-life although tbh the Gtk4 port seems a long way off (it was started quite a while back but proved hard to avoid intractably large diffs) and sandboxed seems Files even further off. However, its all a learning experience...

[jeremypw]

One of the tasks on the porting roadmap is to convert menus to GLib.Menu but you may feel that is outside the scope of this issue.

[teamcons]

okay better to wait then