contrapunctus
/
magrathea
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
magrathea/doc/magrathea.org

7.7 KiB
Raw Blame History

Magrathea - a malleable environment to empower users

Motivations

  1. Malleable Systems

  2. Emacs - a single package has the capability to (more or less) consistently enhance the whole environment.

    • Completion packages like Ivy improve completion no matter what you're looking for or in what application. Themes apply to your notes, your code, your chat client, your package manager, your web/Gopher/Gemini browser. Evil/Boon changes your interaction with all of the aforementioned. Swiper improves your search interface in all of the aforementioned.
  3. Empower lay users. Why is composition and abstraction hidden away in an archaic shell, separate from the theoretically more capable GUI most users are familiar with? In such a world, programs become uncooperating silos and create half-baked duplications of each others' features.
  4. Programs must be easy for users to start using, to tinker with, and to program/reprogram. Each user is different, and must be able to change almost anything about a program.
  5. Make a system a single person can implement and maintain.
  6. All data on screen must be available to the user for use. All operations applicable to a piece of data must be available at all times, regardless of context.

Keybindings and terminologies

We use CUA keys by default. (Ctrl-c copy, Ctrl-x cut, Ctrl-z undo, Ctrl-v paste) Different keybinding packages will be provided for those used to Emacs, Vim, etc.

  • Personally, I'm interested in a mouse + left-hand-oriented keyboard setup.

We use conventional terminology as far as possible.

Window management paradigm

The default uses tiling windows, but the system aims to be flexible enough to implement a stacking window paradigm if a user desires it.

  • I have not seen any particular benefits of overlapping windows. It only seems to increase the burden of window management for the user.

Types of objects

The main objects a Magrathea user deals with are -

Data
whether from a file or just in memory. Anything visible on the screen is data on some level, and the system permits its use as such.
Commands
generic functions meant to be used by end users.
GUI widgets
which are either associated with a command, or with displaying some kind of data
Application windows
collections of GUI widgets

Operations on objects

Drag and drop can be tiresome for the hand and difficult for casual users to do on a touchpad (via tap-to-click), so we use "pick and place" instead.

Mousing over any visible object (text, image, file, windows, GUI widgets, etc) brings up a description and a halo menu of operations possible for it. Some common operations -

View

Launch the viewing program associated for the object.

Edit

For files and data, open the associated editing program (or offer a choice if there are many).

For GUI widgets, edit the properties of the widget, including the code or pipeline used to implement its behaviour.

Send (via chat, email, etc)

Clone

Create a copy at the place selected by clicking. Both the original and the clone can now be changed independently of each other.

Collect

Object is picked up (the mouse cursor may change to indicate this) - click somewhere to "place" it, which offers operations such as View, Move, Clone, Mirror, etc.

More than one object may be picked up before placing them all. This is how we implement multiple selection.

  • The "Collect all" and "Collect all like" operations are provided by any "container" displaying multiple objects, such as -

    • a tool bar containing multiple buttons,
    • a file manager window containing multple files and directories, or
    • a workspace displaying multiple windows.

Mirror

Create a copy at the place selected by clicking. Changes made to one mirrored object are reflected in all of its mirrors.

Attach

(Only applicable to commands and application windows.)

Create a persistent connection between two applications/commands. Data from one is sent to the other.

This may also result in a visual connection between the two (e.g. two application windows becoming a single window with two panes), which itself can be customized/modified.

Present

Click a position to present the object in a different representation.

Inspect

Concerns and remarks

Halo on mouseover

Halo menu on mouseover makes discoverability a breeze, but may turn out to be visually noisy. It may even be slow, since available operations for the object are inspected to create each menu. One alternative is a line or two of contextual text at the bottom, like the "echo area" in Emacs. Genera has something similar.

Making GUI-modifying operations less accessible?

Usually, one may not want to use the operations in the halo for GUI widgets. At the expense of some consistency, the halo could appear -

  • on mouseover for data and application windows, and
  • only with a right click for GUI widgets.

Keyboard-oriented use

So far, this makes use of both mouse and keyboard. Some people prefer to use only the keyboard. Can this interaction model be extended to work mouse-free too?

  • And what about touchscreen (phone) users? There's no hover on a phone…
  • The halo menu could use single-key shortcuts.

  • A system-wide filtering interface could be used to narrow down/select an object on screen via keyboard. Issue the command to select, then type a query (the on-screen objects that match are visually highlighted as you type; multiple matches can be scrolled through with e.g. the arrow keys).

    • Similar to incremental selection using Vertico/Ivy/Helm, except this selects on-screen graphical objects rather than candidates from a list of textual items.
    • Interfaces like Avy are often suggested as a replacement for the mouse, but I'm not a fan of them. Still, our system does not inhibit the creation and use of such an interface.

TODO Catch-all operation?

Similar to Android's "share", a single "Use" operation could be the catch-all primary operation for data. The actual action could either depend on the application/command selected, or the system could ask for disambiguation - select "Use", then select from a list based on installed applications (e.g. View [if a suitable viewer exists], Edit [if an editor exists], Send [if chat/email clients are present], Embed [in a document or GUI], etc).

Undo/redo anything

The user may undo/redo each operation above.

  • How can this be made discoverable?

    • A message could be shown when an action is taken - "Press Ctrl-z to undo <operation>." And when an action is undone - "Press Ctrl-y to redo <operation>."

    • A log of operations could be displayed in a side window (similar to Emacs' messages buffer, but more powerful). Each operation object in that window could have "Undo"​​/"Undo till"​/"Redo till" as one of its actions.

      • The side window could be a tab shown on a screen edge, with a label (e.g. "Undo/Redo"); mousing over it would bring up the graphical operation log and undo/redo interface.
      • This operation log should probably adapt to the current context.

The type, operations, and programs database

(Similar to a MIME/application database. Probably best modeled using CLOS.)

The system holds a database of types, e.g. audio, video, etc.

Each type has associated operations, e.g. view, play, edit, send, etc. The type defines a primary operation, usually play for audio/video, and view for most other types.

Packages may define new types, new commands operating on new or existing types, and applications built using those commands.

Each application/command registers itself for an operation given a certain type.