[EMAIL PROTECTED] wrote:
> >I don't understand. In what way is scrolling related to the terminal
> >emulator, i.e. the parser filtering out control sequences ?
>
> the problem is that some keys are also control sequences (CR, LF, TAB,
> F1, etc). if you press Shift+PgUp in a linux console, what happens is
> that lines that were scrolled before become visible again. this isn't
> expected in a true vt100 emulator (it didn't have this capability).
> now where do you put the Shift+PgUp functionality (where do the extra
> lines go, etc)? it can be done, but it gets a little weird. and i can
> surely make up new key sequences that do weird things and that would
> put some weight in the terminal design.
wait. a terminal *program* consists of a UI element, which intercepts the
UI event (key), and renders the text received from the tty. It also
forwards characters and other codes to the tty in response to key events.
It may look so in ascii art (I know you like ascii art :):
\0/ event +------------+ input +-----+
| ------> | Controller | --------> | |
/ \ +------------+ | TTY |
| |
+------+ output | |
| View | <--------------- | |
+------+ +-----+
Not all events will be forwarded to the TTY. Those which cause scrolling,
for example, will *not*. They are interpreted by the controller, which then
asks the view to change the 'viewport'.
Your <shift><Page Up> will be handled by the Controller, while <Delete>
will be sent (encoded appropriately depending on the emulator type) to the
tty. The UI can get arbitrarily rich, i.e. you could add a menu, with
accelerators etc. None of that concerns the tty or the terminal emulator.
> >I would never try to put everything into the same code. Most codes
> >mean similar things anyway (cursor positioning, font / color setting,
> >etc.), so all that changes is the interpreter which filters out the
> >commands. That shouldn't be too hard to get right.
>
> it isn't. my problem is that i don't really see a huge necessity for
> it. it seems one of those cases where a perfect program design is
> actually much more than what's needed in practice. i may be wrong.
"640 k ought to be enough...". I think you are wrong indeed. You may remember
from our OffiX days, how amazed I was at the internals of the DDD architecture,
i.e. in particular the Agents (TTYAgent). They use it to communicate with the
gdb sub process. Now imagine that you don't want a pure terminal, but one
running a particular process, and you don't want to deal with all the i/o
yourself, but you want to add other parser layers, such as intercepting a
'prompt', filtering out special output (error messages, warnings, etc.)
and present this information in different ways (a notice box popup for example).
This is all the very same design. I would just insert a new Interpreter for
the i/o ! Of course, you might not be interested into that at this point.
But I guess all the existing terminal programs (xterm most notably) certainly
started with a similar attitude, i.e. they didn't have a broad scope in the
early days. Now have a look into the sources after 15 years or so, if you dare...
> >(have a look into the berlin code, we do have a terminal widget.
> >What's missing is the emulator, i.e. a pluggable parser which reads
> >out the control sequences. Right now we simply ignore them, i.e. all
> >we can run are programs in canonical mode)
> that's pretty good. once i finish my thesis i'll spend some time
> designing a new terminal which is impossible to be emulated by it ;)
Heh, you read "G"odel, Escher, Bach", didn't you ? :)
Best regards, Stefan
PS: sorry to the group for that offtopic thread, hope we didn't annoy you
too much
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
