You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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.
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.
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.
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
browsewindow should proxy https/https via server. Needed for websites (like Google) that restrict use in iframes. Also,domterm browsein a remote session should request from that server so (say)localhostandfile: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.