Remove the window menu on electron

[mleduc]

Hello,

currently, when using the reload action from the menu in electron, the user ends up in a blank page (Loading...).
When investigating this issue, I noticed that no menu entry are currently useful.

Here is an exhaustive list of all the menu entries and the consequence of not having them on the menu.

• File
  • Quit (Ctrl+Q): Does not work without the menu, but the native way to quit an app (e.g., Alt+F4 on Linux) is working
• Edit
  • Undo: works when no menu
  • Redo: works when no menu
  • Cut: works when no menu
  • Copy: works when no menu
  • Paste: works when no menu
  • Delete: apparently does nothing
  • Select all: works when no menu
• View
  • Reload (Ctrl+R): no need for it
  • Forced reload (Ctrl+Shift+R): no need for it
  • Toggle developer tool (Ctrl+Shift+I): useful, at least when developing
  • Actual size (Ctrl+0): does not work without the menu
  • Zoom in (Ctrl±): does not work without the menu
  • Zoom out (Ctrl++): does not work without the menu
  • Toggle full screen (F11): TODO test without menu
• Windows
  • Minimize (Ctrl+M): Does not work without menu, but the native way to minimize a window is working (e.g., Win+H on Gnome)
  • zoom: apparently does nothing when the menu is activated
  • Close (Ctrl+W): Does not work without the menu, but the native way to quit an app (e.g., Alt+F4 on Linux) is working
• Help
  • Learn more: lead to https://www.electronjs.org/
  • Documentation: lead to electron/docs at v33.2.0 · electron/electron · GitHub
  • Community discussions: lead to electronjs.org
  • Search issues: lead to GitHub · Where software is built

Most of them can be removed, but I think a minimal set of actions must be preserved:

• useful for devs and debug:
  • Toggle developer tool (Ctrl+Shift+I)
• useful for accessibility
  • Actual size (Ctrl+0)
  • Zoom in (Ctrl±)
  • Zoom out (Ctrl++)
  • Toggle full screen (F11)

Then, we have two options:

• Option 1: redefine a menu with the minimal set of actions
• Option 2.1: only bind the shortcuts for useful features
• Option 2.2: bind the shortcuts but also provide a section about help (this is more work as we’d need to introduce a help UI, and provide a way to inject electron specific details, and maybe also a notion of shortcuts and shortcuts definition)

I’m +1 for option 2.1, and create the improvements to do 2.2 later.

WDYT?

[mflorea]

@mleduc

Option 2.1: only bind the shortcuts for useful features

Doesn’t this mean we keep the menu entries that are not working? Even without a shortcut key associated, the user can still open the menu and try those entries, no? If so, then I’d be more in favor of keeping only the entries that make sense for us, which is option 1.

Thanks,
Marius

[mleduc]

@mflorea

Doesn’t this mean we keep the menu entries that are not working?

No, in option 2.1 there is no menu in the UI anymore. We simply define the keyboard shortcuts for the important actions. The entries that are not working are not accessible anymore.

[mflorea]

Ah, I see, so option 2 is about hiding / removing the menu and exposing some of its features (that would stop being available otherwise) through shortcut keys. I’m fine with this. And yes, ideally we need a UI to discover the shortcut key bindings, but that can be implemented later.

Thanks,
Marius

[tkrieck]

@mleduc

• Option 2.1: only bind the shortcuts for useful features
• Option 2.2: bind the shortcuts but also provide a section about help (this is more work as we’d need to introduce a help UI, and provide a way to inject electron specific details, and maybe also a notion of shortcuts and shortcuts definition)

+1 for this plan

[mleduc]

Thanks for your answers, I’m going to opt for option 2.1.