[EMAIL PROTECTED] (Markus Kuhn) wrote on 29.01.01 in
<[EMAIL PROTECTED]>:
> A (quite large) project that might really be worthwhile doing is to
> author a concise video terminal standard. It should be
I think I should write down some thoughts related to this so they don't
>get lost.
Options - why and how to do them right
Why do we need options? We need them because not every terminal (emulator)
will have the same capabilities, nor would we want them to be identical.
They'll have different (maybe even dynamically changing) numbers of rows
and columns.
Some will have window titles that one might access, some won't.
Some may have additional graphics functionality, some won't.
And so on.
But we certainly don't want the old confusion, where software has to rely
on configuration to figure ut what a terminal will do, and on bookkeeping
to figure out what state it is currently in.
So I propose an interface that has approximately the following features:
* First of all, there is a basic feature set that MUST be implemented. The
rules here include the rules for what can be used to implement add-on
features, so one can easily code around unknown add-ons. (For example,
what escape sequences can be used. Oh, and how to get officially blessed
extensions - where to go for review, how to make them public.)
* There is a way (in that basic set) to query the terminal for the options
it does support. Preferrably, by name, and something like x-names for
private features.
* Similarly, there is a way to ask the terminal for enough internal state
as to be able to restore the state (this is important, for example, when
calling out to a different program that needs different option states but
wishes to restore the display before returning). One of the things one can
query should be the current display contents. Everything should be
returned in a form that can simply be sent back to the terminal for state
restoration, so software does not need to understand all the details.
* There should be a certain octet sequence that will *always* get the
terminal into a state where one can use the query-and-modify-state
functions, no matter what the terminal is currently doing. (Think of the
situation where a program is kill -9ed and you want to restore the diplay,
for example. Even if you just were in the middle of a multi-megabyte font
download, you still want to be able to reset right now.) Implementing this
right probably means you need to keep a state machine running directly at
the receive-a-character point, and you also need to keep this in mind when
designing escape mechanisms for binary data such as for font downloads.
* One of the items one can query should be a string exactly identifying
the terminal software version. No matter how standardized this thing is,
you still want to be able to figure out exactly what you're dealing with,
it's good for bug reports, and it helps people trying to inventory their
stuff, and so on and so forth.
* Maybe think about channel transparency issues. (Yes, I know this is
vague.)
MfG Kai
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
