I think a lot about what I'd like to see in a front-end for network spaces and related applications.
I would like to have a user interface that permits mixing a command line interface with a GUI. One example of this from the past is that of CLIM, the Common Lisp Interface Manager and the Symbolics Dynamic Windows framework, which was a predecessor to CLIM.
This is not intended to be a completely general application framework (at least at the outset) or to create any sort of user interface. At the outset, it will be limited intentionally to a class of applications and interface styles.
There are a few things that made CLIM powerful.
Every interaction with the underlying system was done via a command. The command could be invoked in many ways: menus, context menus, command lines, mouse gestures, keyboard shortcuts, etc. In today's world, we could imagine commands being triggered by other input devices as well, such as accelerometers and gyroscopes.
Commands were grouped within command tables, and command tables were available within a context, and command tables could be added to or removed from that context. A context might be global, a command parser, a frame or sheet within the user interface.
We will differ from CLIM in this area, so for now, we'll just say that obviously, an application can generate output. That output may be in the form of data, responses to commands that are textual or graphical, or hierarchies of GUI sheets / widgets.
Presentations are a very powerful part of CLIM (and some predecessor systems going back into the early 1980s).
The idea behind a presentation is that it is a way to link a portion of the application output with the underlying application object.
This provides a couple of interesting capabilities.
First, it lets the user interface know what commands are available when the user interacts with something in the output. Mousing over, right clicking or other interactions allow the interface to query the underlying application to see what commands are relevant to be presented in a menu or should be executed.
Along with the link to the underlying application object, the user interface is aware of the "type" of the application object. This type can be used during autocompletion to allow the user to select the presentation of the object when an object of that type is needed.
When a command needs input either via prompting or autocompletion or automated via menu selection, this operation is called accept. When accepting input, the type of data required is specified. This corresponds to the presentation type of the application objects.
Because we have a single API where we go to fetch input (accept), we know the type of input required, and we have a way to reference underlying application objects directly, we are able to have a input history that is context sensitive. We can remember the last responses for each presentation type and present them intelligently. Also, we can keep track of the last objects presented and use them as a possible completion. For example, if we had a git client using this, then typing "git log -n1" would show the most recent commit, and when doing "git show" and prompting for a possible object to show, it would know that it had just shown an object from "git log -n1" and could offer that as an immediate auto-completion.
When we call accept, we might pass in a stream or other object that will be used as the input. In this case, we will attempt to translate the contents of the stream or other object to an underlying object with the correct presentation type. This is done via presentation translators as described below. An example of this might be entering a file name or path name when a file is needed.
Further, when prompting for input via accept, we could highlight all matching objects on screen that have the requested presentation type. In that case, clicking on the object would select it as the input value.
Much like we have an accept function, we also have a present function. This allows us to present an object for output to an output stream. The type of stream being used for the output can help decide how the object should be represented. This needs some further thought for how it should work and handle a lot of edge cases.
Presentation types, as have been described above, are how we are able to identify the nature of the object being prompted for by accept and how we know what type of object is being represented in some fashion on screen.
Presentation types can be subtypes of other presentation types. They can also be a union of a set of presentation types.
... Write more here ...
There will be many other details about the high level design to discuss. CLIM in particular has a lot of useful things that they've thought through and that we can learn and borrow from.
- Named gestures. Gestures have names and the underlying input system maps system input events to gestures. Instead of watching for a "left click" gesture, we look for a "select" gesture.
This section is going to be expanded a lot ...
I think the GUI shell will run in Electron or browser. Written in TypeScript. Maybe with react. Probably with RxJS which is written in TypeScript. It will run subprocesses which can be in many languages. Those subprocesses will supply additional CLIM-style command tables. They will provide data back to the shell to set up and update GUI. Data can be provided raw and content type handlers set up in the shell to do somethings automatically like data frames.
Data from the subprocesses can be tagged with presentation types and IDs to use with command completion as well as translating UI input on a presentation back to the possible underlying commands.
Nothing in it would really be specific to Dylan or anything else. And the subprocesses model explains partially how it is different from Jupyter which just talks to one kernel.
... Write more here ...