Frontends including browsers

A frontend is a program that handles the user interface for a session, in a window. A frontend is either a web browser, or some application that has an embedded web engine. You have a number of options for a frontend, with different advantages and limitions. The two most polished frontends at this point are the Electron and Qt frontends.

Multiple different frontends can talk to the same backend at the same time.

Window size and position (geometry specifier)

You can request the initial size and position of a top-level window using an X11-style geometry specifier, using either a --geometry command-line option or a window.geometry setting in settings.ini. A specifier is either a size or a position or a size followed by a position (with no spaces). For example --geometry=775x600+20+10 specifies that the window is initially 775 pixels wide, 600 pixels high, and positioned (if possible) 20 pixels right and 10 pixels below the top left corner of the screen.

A size has the form WxH, where W and H are the width and height in pixels, both positive integers. The default if not specified on the command-line is that of the previous window, or the window.geometry option in the Settings file, or otherwise currently 800x600. (When creating a new window using a menu entry or keyboard shortcut, the default size is that of the current window.)

A position requests an initial position of the window, in the form [-+]X[-+]Y. The X specifies how far (in pixels) the left edge of the window is from the left edge of the screen, or (if preceded by -) how far the right edge of the window is from the right edge of the screen. Y specifies how far the top edge of the window is from the top of the screen, or (if preceded by -) how far the right edge of the window is from the right of the screen.

A position in settings.ini is only used for the initial window.

A size works for the Electron, qtdomterm, and --chrome-app front-ends. A position currently only works for Electron.

Browser quirks and limitions

(These can all change as browsers change or work-arounds are implemented.)

Exiting the inferior process can sometimes fail to automatically close the DomTerm window, due to browser security limitations. It currently works on Google Chrome, but not Firefox.

Saving the console display to a file in a browser may save to the browser’s “Downloads” area. You may be able to save the file elsewhere, depending on the browser and its settings.

Microsoft Edge at time of writing does not handle the tab-size CSS property, so on that browser tab characters are always converted to spaces.

Copy and paste

Paste should work on all front-ends if domterm makes use of libclipboard. Otherwise, only Electron and WebView work as they should, though the keyboard shortcut Ctrl-Shift-V works on all tested platforms, (On Qt the Paste menu-item is unreliable if the previous Copy was from a different application. On a desktop browsers like Firefox, custom menus can’t do Paste though system manus can, because of security concerns.)

The Copy menu-items work on Electron or Qt, but there are issues on other front-ends. The keyboard shortcut Ctrl-Shift-C works on all tested platforms.

Middle-button paste seems to work on most frontends (on Linux). An exception is WebKit-based browsers (Webview, Epiphany aka Gnome Web), though it works if you use libclipboard.

Note on menus

The Electron and Qt front-ends use their respective menu interfaces, which works well.

On Electron disabling the menubar by clicking “Show menubar” is currently not working.

Most other frontends use a menu package written in JavaScript that works fairly well, but has some minor issues. One is that all menus are constrained to the main window. Also (as mentioned above) copy and paste menu items may not work due to browser security restrictions.


Start the Electron frontend (if available) with the --electron option.


Start the Qt frontend (if available) with the --qt option.


Start the Webview frontend (if available) with the --webview option.

This is quite usable - nicer than using a web-browser. It uses JavaScript menus, which is OK except on Mac.

Cat’ing large files is much faster than other browsers, probably due to deferred re-display. Window re-sizing is slower. Both of these may change if we implement smarter lazy line-breaking.

Some known issues:

Desktop browser

Modern desktop browsers should work ok, but note the limitations mentioned above (most notabley copy and paste). However, only Firefox and Chrome are tested frequently.


To open a Firefox window or tab use the --firefox specifier. Recent versions of Firefox should work well.

Exiting the inferior process (such as by typing exit in a shell) does not automatically close the browser window.


To open a Google Chrome window or tab use the --chrome specifier.

The --chrome-app specifier creates a top-level Chrome window without the standard Chrome location bar or other header “chrome”.

Embedded in other environments


There is a fairly nice package for embedding DomTerm panes in the Atom text editor framework. See the repository.


There is an experimental package for the Theia IDE. See this fork.