Re: Arrow head filling patch, and "port.trm"

[Chris K <gnu...@li...>]

First: The result of rendering the commands sent by port.trm using
haskell/gtk2hs/cairo:

http://img102.imageshack.us/img102/2040/woo0nn.png

This is a 640x480 rendering of the test command.

Second: Where is the best documentation for the enhanced text format and =
protocol?

Hans-Bernhard Br=F6ker wrote:
> Chris K wrote:
>=20
>> Pre-Announcing "port.trm" :
>>
>> The ability to write the commands as ascii text to a file descriptor
>> port is why
>> it is called "port.trm".  The idea to for the parent process to read t=
he
>> commands and render/process them.
>=20
> Looks like you're re-inventing the 'xlib' terminal.  And/or tkcanvas.
>=20

I mildly disagree.  I re-invented debug.trm.

I still have not read through each and every terminal driver.  I do see t=
hat x11
is among the largest drivers, and is interactive.  The xlib driver merely
redirects the x11 commands to a file, which is a slightly different layer=
 than
port.trm which just sends the original commands.  This is highly speciali=
zed to x11.

The tkcanvas driver is stranger.  It is a tcl/tk code generator that emit=
s the
executable code to operate gui.  This is highly specialize to just tcl/tk=
.

=93Any problem in computer science can be solved with another layer of
indirection=94 -- David Wheeler.

What I have done is derive port.trm from debug.trm (Literally -- I starte=
d by
searching and replacing DEBUG with PORT).  The port.trm driver has to imp=
lement
a little policy, but is mainly concerned with creating a precise descript=
ion of
the commands as data.

In the end, gnuplot gains to ability to drive a rendering program via the=
 output
file, which I will redirect to a pipe (/dev/fd/5).  Then gnuplot has the =
ability
to drive any program that parses the protocol without recompiling gnuplot=
.  None
of the terminal drivers that I have read (besides debug) approached it th=
is way.
     This was an attractive idea because, like the experimental wxWidgets
terminal, I am ultimately using a Cairo backend which has commands like a=
re
nearly isomorphic to what gnuplot sends to the terminal.

The ascii format is very easily read by Haskell, but also very easily rea=
d by
people (Well..the text to display is hex encoded 0-9a-f, so that is less =
human
readable).  Each command is exactly one line.  Everything is in the
][a-zA-Z0-9(_)- character set (plus newline), and there are no escaping o=
r
endian issues.  I don't use them, but I expect every command could be par=
sed
with a scanf or a simple regular expression.

The ability to save the output to a file and replay or edit it makes for =
strange
possibilities.

--=20
Chris