[Linuxconsole-dev] Municon

[Jim P. <ji...@ag...>]

Hi all -

Okay, time to spill the beans.  I've been developing ideas for a new
terminal-type I'm calling `Municon' (for Multimedia Unicode Console, if
no-one's already used that name).  I'm fairly good with ideas and design,
but not necessarily so good at development or delivery (okay?), so I'm
sharing the ideas, to see where this leads.

WARNING: This is all VAPOURWARE at present.  No code yet.

I'm working from the idea that a terminal should be able to live on the end
of two pipes (or a fast serial cable).  `stty' settings and LF->CRLF mapping
and so on can stay in the kernel, where it's always been.  This ensures
compatibility.

My motivations are these:

- I like the console environment.  Everything runs full-screen.  I can have
lots of things running at the same time, and switch very quickly and easily
between them.  The keyboard drives (almost) everything.  Everything appears
in my favourite font, and at a size that is comfortable for me to read
(because I chose it).  The background is black by default, so I don't get a
headache.

- Things are moving on.  The console no longer is limited to text-mode, 16
colours and 256/512 characters.  Why not expand to meet the potential,
whilst keeping the essential features ?

- Let's not give too much control to the application.  Let's keep the user
firmly in control of their working environment.

- Let's make it dead easy to write scripts and programs to drive this.  No
more nonsense having time-outs to read the ESC key.

- Let's not try and do everything.  If you want to do streaming video, open
your own /dev/fb device.  But if you want to write a quick script to dump
your results graphically to the screen, this may be for you.  In a
restricted but flexible and easy-to-code-for environment, simple utilities
proliferate.  We love text files, right ?  Binary files ... hmmm, well ...
not so nice to hack ...

Basic features would be:

- Based on Unicode UTF-8 to support everyone's language, with right-to-left
text for those that need it.  Word or character-wrapping at line-ends.
Stick to across-then-down text, with upwards scrolling - I think Chinese
people can read across as well as down, right ?

- Modeless as far as I can take this.  I don't want my text suddenly turning
to graphics after catting a binary file.  Lose most settings (colours,
text-direction, etc) at a '\n'.

- Support for proportional and fixed-pitch fonts, but only one of each, and
those set by the user.  There will be a standard set of symbols that
applications can always expect to be present, such as ASCII + line-drawing
stuff, or whatever.  The application can define its own characters, but
perhaps we can limit it to the user-band of Unicode.

- Support for basic pixel graphics, in a few crude formats.  No complex
compression or anything, dead easy to code to get a quick picture onto the
screen.

- Support for PCM mono/stereo sound, again in a few simple formats, as the
next step up from BEL.  The BEL sound itself can be set by the user.

- Cut and paste with the mouse (as gpm).  Also, maybe, clickable regions
that generate key-sequences or commands (see later).  Maybe also generate
sequences from dragging one region on top of another.  This is crude, but
you can build a lot with this - even a shell-script based filemanager with a
trash basket, entirely navigable with the mouse.

- Mouse pointer disappears after two seconds or so without activity, so that
it doesn't get in the way.

Data stream to the terminal would consist of UTF-8.  Single-character
control codes work as expected, where this is useful.  Multi-character
`escape-codes', which I'm calling command-sequences, are introduced by a
special control code (I'm thinking ^^ right now), and look like a command.
They are terminated by another code (^_).  They are also aborted by '\n',
and certain other characters so that we don't ever get stuck in
`graphics-mode' or anything like that.

These command-sequences are very extensible - I'm thinking of starting with
a sequence of alphabetics for most commands, so the scheme could be extended
indefinately.  Any command-sequences or characters that are not known are
dumped to the screen, so nothing invalid ever gets silently forgotten.  This
also means that Unicode characters that aren't present in the user-selected
font are represented by something like a narrow box, so that you know that
you're missing something.

Anything that isn't a glyph (e.g. graphics or sound) is passed within a
command-sequence.  This doesn't have to be one immense command-sequence - it
can be broken up into manageable chunks as several smaller command-
sequences.

Coming the other way, the data-stream from the terminal also consists of
UTF-8.  Any key-press that does not represent a printable glyph, and that
isn't normally represented with one of the control-characters 0-31, comes
through as a command-sequence, in the same format as the command-sequences
in the other direction.  I'm thinking that they can come through in
Emacs-style, perhaps something like ^^key C-M-Up^_.  If I'm going to use ^^
and ^_ for sequence-delimiters, then these would have to come through as
`key C-^' and `key C-_'.

For complex applications, it's also going to be necessary to query the
terminal about many things from the application.  The application would send
a command-sequence (or several), then wait for replies to arrive back as
command-sequences in the input stream.  I know there are slight difficulties
for the application if it receives key-presses amongst the replies, but this
has to be lived with.

The queries would include Municon version-number, the screen-size, the
cell-size (for fixed text), width of a given string (for proportional text),
any many other bits and bobs.  There can be a lot more communication going
on than is common with a normal console application, especially if the
application is fussy about how things appear, mostly to handle proportional
text.  However, for a simple application that is happy to let words wrap
where they will, they can just dump it all to the screen.

Also, so long as we can get the screen-size to them, normal curses-type
applications will work without problem using the fixed-pitch font.  (Mapping
input keys might need some attention, though).

Other ideas include:

- Having a single timer in the terminal that sends a command-sequence back
when it expires (or maybe even a key-sequence).  The application can set
this timer to a clock-time, or a time-delay.  This could be used for easy
time-outs in shell scripts, or even for keeping an application's clock
display *accurately* up to date.

Remember that I'm seeing a big split between the terminal and the
application-hosting machine, that is, where the serial cable would be, even
if this is in fact all on the same machine.  I'd like to see the user firmly
in control of the configuration of the terminal-side of all this.  This
means that the user can set this up however they want.  For Chinese people,
for example, this may mean some peculiar keyboard mapping that allows them
to enter their characters into some pop-up box on the screen.  

I don't know, but this is all feasible within this scheme of ideas.  The
terminal is theirs to configure and adapt to their precise circumstances.
The application need know nothing of this.  All it gets is glyph-codes and
key-sequences - it need know nothing of how these have been entered.

You see - all I'd be defining with this is the valid sequences over the
link, and the behaviour of the terminal.  Implementation and operation of
the terminal could be extremely wild and weird without upsetting anything at
all.  This could be handled with plug-ins or whatever.

The implementation could live on top of fbdev, or GGI, or X - it doesn't
matter to the application.  It could be a daemon running in user-space with
pseudo-ttys (or maybe some modified version of these), or it could even live
in the kernel (though to be honest, I'd rather keep it out of there).

That's all I have for now.  This is all vapourware at present, but this
nails a whole lot of my concerns, and opens up the role of the console as a
device for quick graphics and sound hacks, as well as its traditional
role for text.

Remember that the console has always been very hands-on, handling many
different contexts within the same text-grid, whether that be scrolling
shell interaction, or paging text, or a text-editor.  All of these cross
over.  You can `cat' the caught output of a command, or page it, or edit it.
This doesn't happen in X.  If we can extend this to graphics and sound,
there is a lot of potential.  You can catch the output of your `beep'
command, and `cat' it later, or pipe your picture through `sed'.  

To realize this potential, however, everything needs a common standard to
work with, the equivalent of `plain text'.  This to me means UTF-8 +
command-sequences.  If all the common tools can be extended to handle UTF-8
(I suspect many do already), we're well on the way.  If command-sequences
can be made clean enough, maybe applications, like pagers or editors could
understand and edit these also.

I need to think more about handling tabbing and regions, and so on, and some
other implementation issues, but I hope you can see the potential.
Apologies for my inflexibility, but hope you can see where I'm heading.
Actually, no apologies for my inflexibility - there's a reason for it !

Am I being too much of an idealist with all of this, perhaps being a little
unrealistic ?  I don't know.  I'd much rather take the time to come up with
a clean design than add more gunk to the ANSI terminal, and try to live with
that and feel happy.

Any comments ?  Anyone spotted any design flaws ?

Does anyone see how we can take this forwards ?  Would anyone like to join
me on this, bearing in mind the current (undeveloped) state of play ?  

Does this seem to be a worthwhile project to you ?

I have some design work to do, I think, if this is going to fly.

Jim

-- 
 Jim Peters         /             __   |  \              Aguazul
                   /   /| /| )| /| / )||   \
 jim@aguazul.      \  (_|(_|(_|(_| )(_|I   /        www.aguazul.
  demon.co.uk       \    ._)     _/       /          demon.co.uk