Skip to content

Latest commit

 

History

History
46 lines (24 loc) · 3.11 KB

README.md

File metadata and controls

46 lines (24 loc) · 3.11 KB

SUBTEXT (Demo - proof of concept - experiment)

SubText is a Lispy, mostly-text-based user interface.

SubText 'entangles' CLOS objects with arbitrary pieces of text, enabling simple, flexible, and familiar ad-hoc user interfaces.

Imagine that THIS PIECE OF TEXT was also a CLOS object. Whenever the mouse pointer or the cursor move over it, or text inside it is edited, functions (that you can specialize) are invoked. Imagine that the text snippet could bind keys Emacs style...

There are many situations that require minimal -- or not so minimal -- text-like user interfaces. That's what SubText is for.

Demo and Screenshot

To experience the (very early) demo, clone the repo and (ql:quickload :subtext)(in-package :subtext)(demo)

screenshot

Why?

Fluid, loosey-goosey editable text augmented with code makes for very flexible and efficient use of space and does not lock the developer into the same 'look-and-feel' box dictated by the OS vendor. See Background and Motivation

What the heck is it, really?

SubText is built on top of GTK. GTK text buffers already feature MARKS (locations in text that are preserved across edits) and TAGS (ranges of text with certain attributes). Now we add the idea of a context, a piece of tagged text bound to a CLOS instance.

These text/code contexts provide the setting for user interaction within their bounds. They can bind keys, visually modify their text, or execute arbitrary code. The CLOS hierarchies, together with the runtime placement within other contexts, provide useful defaults.

Contexts operate within a subtext- a text buffer which provides the plumbing connecting contexts to the GTK environment and controls their interaction.

The two terms describe the situation aptly:

  • contexts dictate how text looks and user input is handled;
  • subtexts provide environments for contexts.

Contexts are relatively light - the system works fine with tens of thousands of them. They can be created on the fly and printed to a subtext stream much like ordinary text - or created in advance and composed separately. They can allow the user to edit them freely - or enforce specific rules and bind keys to commands. They can be embedded inside other contexts. Text around them can be likewise editable (or not) - think of a note-taking application or a spreadsheet, but more free-form.

In practice, SubText may be used to create a simple screen with a couple of live 'buttons', like the demo front page, or a sophisticated system like a Lisp source editor, where contexts are directly bound to nested sexps.

Is it GTK only?

GTK was selected as the backbone of SubText (although it could be moved elsewhere) because it may be the easiest way to output decent-looking subpixel-antialiased type. This works well for the desktop paradigm.

A lightweight console version is envisioned for embedded/minimal scenarios.

Status

This is an extremely early prototype, here mainly as proof-of-concept. Many changes are taking place; I do not recommend taking anything here for granted.