This makes possible applications that look and feel like native
without the overhead of something like Electron.
You can use any "embedded" bare-bones web browser, including
the Chrome browser with the
As an example, the DomTerm terminal emulator
has a "back-end" written in C, which communicates (using http and
websockets) with any modern browser. It can optionally run under
Electron, and the code for creating menus (see
is mostly the same whether using Electron to create menus, or using this
library in a generic browser.
Advantages and changes compared to the original
- Menu-items and menus can be shared between menus.
- Keyboard navigation (using arrow keys, Escape, and Enter).
- Some changes to work better with libraries such as GoldenLayout (for panes and tab) and full-screen.
- You need to explicitly call
Menu.setApplicationMenu(like Electron) - creating the Menu objects is not sufficient.
- Passes MenuItem as (first) argument to click handler (like Electron).
visibleproperty on MenuItems (like Electron).
acceleratorproperty (like Electron) as an alternative to
- Polishing so it works more like other menu systems, including various bug fixes, and working smoothly under Firefox.
- Styling changes to make it look more native-looking (on Linux or Windows); this is probably a regression on Mac (needs testing).
- Internal changes, such as when a menu is no longer shown, we remove its elements, rather than just hiding it with css.
Just load or require
There is API documentation in Documentation.md.
This shows the context menu for the DomTerm terminal emulator.
DomTerm is started using the
which starts the Google Chrome browser in "application mode",
without the default "chrome" (location bar etc).
- Test and polish style on multiple platforms, including MacOS.
- Internal cleanup - Menu or MenuItem should not have properties that depend on display/navigation state. Specifically, there should be no pointersMto the parent or DOM node, not even temporarily.