RoadMap

[PerBothner]

This roadmap implies no commitment. Priorities may change depending on unexpected difficulties or insights, user requests, or whim.

Short-term

These items are being worked on:

• Make custom titlebar be smarter about how much space it uses. If space is limited, replace menubar by a hamburger menu.

• Design and implement a flexible "template" mechanism for setting values. This includes general conditionals that can define on other settings or the environment. This is high-priority because it changes settings syntax. In progress: Template syntax has been designed; parsing and expansion is implemented in front-end; many settings have been converted to the template framework. To do: Template parsing/expansion in backend; convert remaining settings; improve documentation; implementemore functions/operators (for expressions).

Medium-term

• Dynamic window list browser/selector: Issue window list display #117

• Configurable titlebar for front-ends. Most useful for front-ends that support user titlebars (Electron, Qt, Wry).

• Better control and more options for handling connection loss - especially important for remote sessions. Automatic backup of window contents.

• Settable hover text (issue feature request: hover text #61), including rich multi-line text with clickable buttons/links. (Use the new hover-over-link framework.)

• For browse window should proxy https/https via server. Needed for websites (like Google) that restrict use in iframes. Also, domterm browse in a remote session should request from that server so (say) localhost and file: urls are correct.

• Localization: A framework for providing strings (menu labels, error messages, reports etc) in languages other than English. Preferably in a way we can use a single translation file for both front-end (JavaScript) and back-end (C++).

• A mode for "infinite lines" so applications can defer line-breaking to DomTerm. This can optionally be used with variable-width fonts.

• An extension mechanism to load JavaScript, add commands, keybindings, etc. One use-case: MathJax support (issue Compiling error: ‘class ads::CDockManager’ has no member named ‘addContainer’; #96)

• A "command palette" (as in VSCode and other applications), by default bound to Ctrl+Shift+P.

• A command to browse the manual in a (sub-) window.

Longer-term

• A plug-in for VSCode (and hence also Theia). (An old experimental Theia port exists.)

• A command to open a text editor in a (sub-)window. Probably either Monaco or CodeMirror 6. Maybe also a file browser. Alternatively (or additionally): improved integration in an IDE like Theia, Atom (old plugin exists), VSCode and/or Jupyter.

• Port backend to native MS-Windows (without WSL) - see issue request for msys2/mingw64 build  #84.

• Migrate backend to use libwebsockets Secure Streams. This should simplify the code, and may make proxying/forwarding easier.

• Possibly use xterm.js for the default JavaScript engine - probably the canvas renderer. This should speed up things quite a bit, but would need major changes (probably a fork) to xterm.js.

[PerBothner]

Lazy line-breaking is now working pretty well and some things (such as cat of large files) are much faster due to f701705

[PerBothner]

Removed two short-term items from the roadmap, as they are now implemented and documented:

• Automation/testing framework (new commands do-keys/send-input, capture, await).

• General -w window-specifier option works on many commands, including all the old window subcommands.

[PerBothner]

Removed this item from the roadmap, as it is now implemented:

• Handle multi-character graphemes. If using a fixed-width font, use 1 or 2 columns. For line-edit, view, or find-text modes: Treat graphem as single character.

[ghost]

Hello again @PerBothner !

I have been coding since December -- to my utter surprise -- and am pushing a bit further into images+text. If I notice any issues with DomTerm, would you be interested in hearing about them? I don't want to be a pest if this not an area of concern for you.

[PerBothner]

@klamonte I'm absolutely interested in hearing about your issues and ideas. Lately I've been focusing the "window managent" aspects, but I have been thinking about which image protocols to support (in addition to HTML and Sixel), and how to handle text/image overlap/combination.

[ghost]

@PerBothner

Sure! Well, right now qtdomterm specifically is having issues with any-event mouse (not sure why, I know you looked at it earlier once), and my latest images code left quite a few artifacts.

In the broader picture, I am gunning for bling and gaming. (notcurses inspired me.) I will be collecting more things here -- right now we have translucent windows (including images), a much better and faster sixel encoder for me (but still only ~1% of the performance of chafa and notcurses), pulsing text, different button shapes (using images for the edges and shadows), and quite a bit more performance. And pink...a lot more pink. ;)

On the images side, I have actually gotten "un-sold" regarding the need for higher bit depth formats. I can do my own image layering with alpha blending, and due to the use of 1-cell-high images the apparent bit depth is much higher than the per-image palette size. I would challenge people to look at this and tell me whether those are sixel or PNG images on the screen. Or see DOOM animating inside foot and say the only way to get this effect is via proprietary or local-machine-only shortcuts.

Sixel can actually do almost everything people have asked for. It is just hard to encode quickly, and is not mutually destructive with text. So I would be interested in Good Image Protocol (GIP) if/when that gets specified, because it would specify text vs image interaction. GIP would also have specific support for multiplexing without requiring image decode/encode: the most serious obstacle for tmux et al. (Speaking of, vtm and zellij are both quite cool multiplexers, with very energetic developers. Another source of inspiration for me lately.) So my vote is:

• If you have sixel, keep using it. Wait for GIP.
• If you really need easier encoding/decoding sooner rather than later, then iTerm2 isn't too bad.

EDIT: I'm back.

[PerBothner]

If you can submit a concrete issue, with a way to reproduce it (there simpler the better), I'll take a look.

"I am gunning for bling and gaming" So what would you prioritize for DomTerm? What would make you use DomTerm (more)? Should I aim to implement the iTerm2 image protocol?

[ghost]

I've got the sixel glitches I'm seeing submitted.

I don't think iTerm2 would be worth it, actually. notcurses dropped support for it, favoring sixel and kitty instead for example. I would prioritize solidifying sixel: DomTerm's sixel performance is rather good.

[PerBothner]

Removed this item from the roadmap, as it is done (modulo more testing and possible bugs):

• Handling of non-terminal sub-windows: Fix problems when initial or only subwindow is non-terminal - like domterm browse http://example.com. Create a top-level WebSockets connection in such cases. Include in status listing.

[PerBothner]

The following is now implemented:

Line-oriented motion (such as "line-down" or "move-to-end-of-line" in edit or view modes) should probably work with visible (screen lines), not logical lines. This is non-trivial in case of browser line-breaking with variable-width fonts (such as from embedded html). Might add commands like down-paragraph (possibly bound to Alt+Down) to move by logical lines / paragraphs. Also, "move-to-end-of-line" could move to end-of-paragraph if already at end of screen line.

[PerBothner]

I think this currently works as well as can we reasonably expect without using more front-end specific "native" code (Rust for Wry, C++ for Qt, JavaScript for Electron):

• [MOSTLY WORKS] Support drag-and-drop of sub-windows betwen top-level windows (and preferably desktop). (see notes). (This assumes experiments using JavaScript drag-and-drop work out.)

[PerBothner]

Using xterm.s is now working on an experimental basis, though some work is needed.

Hence removed the following from the roadmap.

• An option to use xterm.js for the terminal emulator, including the ability to mix DomTerm and xterm.js sub-windows in the same window. Xterm.js has some benefits compared to Domterm (mainly speed). There is some old support for xterm.js but it needs to be updated, and we need to add the ability to switch dynamically.