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.
You can specify a preferred front-end using a browser specifier,
either using a --browser
option (or the shortcut -B
)
to the the The domterm command,
or with the browser.default
setting.
Multiple different frontends can talk to the same backend at the same time.
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 Wx
H,
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.
(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.
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 menus 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.
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 -Bwebview
option.
This is quite usable - nicer than using a web-browser. It uses JavaScript menus, which is OK except on macOS.
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:
File
->Quit
menu item works,
as does typing exit
from a shell.
About DomTerm
menu item doesn’t work.
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 -Bfirefox
option.
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 -Bchrome
options.
The -Bchrome-app
option creates a top-level Chrome window
without the standard Chrome location bar or other header “chrome”.
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.