[37] in Zephyr_Comments
re: zephyr font glitch (OLD MESSAGE)
daemon@ATHENA.MIT.EDU (Mark W. Eichin)
Fri Jun 17 00:53:10 1988
Date: Fri, 17 Jun 88 00:52:49 EDT
From: Mark W. Eichin <eichin@ATHENA.MIT.EDU>
To: Jerome H Saltzer <Saltzer@ATHENA.MIT.EDU>
Cc: zephyr-comments@ATHENA.MIT.EDU
In-Reply-To: [0026] in Zephyr_Comments
[Sorry for the delay; due to a bug in discuss, I never found out that
the meeting got expunged, and so missed the last 30 or so
transactions. I realize this was posted at the end of April, but a
response is again appropriate...]
[0026] daemon@ATHENA.MIT.EDU Zephyr_Comments 04/27/88 14:14 (14 lines)
Subject: re: Zephyr font glitch (mostly excuses)
Date: Wed, 27 Apr 88 14:13:42 EDT
To: zephyr-comments@ATHENA.MIT.EDU
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
> (Side note: what
> parameters would be useful to change during runtime? fonts? window
> position? Send suggestions to zephyr-comments. Flame flame flame!)
Is there any reason for Zephyr not to follow the full-bore
options/resources/defaults route just like the other X applications?
That is, one can specify everything--geometry, fonts, reverse video,
which display, border widths, background color, etc., etc. Doesn't
use of the Xtk provide most of that for free?
Jerry
--[0026]--
The problem is that Xtk provides these at fairly great performance
expense. All of the memory leaks in the release version of zwgc are
via Xalloc (I debugged the system under a custom malloc() which logs
the return address in the header of the block of memory, and before
the release had only calls from Xalloc remaining.) Admittedly, Xtk is
going to improve with time; until then, using it is still prohibitive.
The current version of zwgc (under watchmaker test, ie. you don't want
it quite yet, in spite of the immense speed improvement) supports a
large, appropriate set of Xdefaults, including geometry (position),
borders, colors, fonts, reverse video, and several debugging options.
The vax version (for test purposes) also supports flushing the cached
Xdefaults/resources, although the X library does not document any call
to perform this (I haven't checked the sources thoroughly yet.)
The original questions was whether X related parameters should be
mutable; the current test version allows this.
_Mark_
