[9] in release-74
proposal for changes to dash for release 7.4
daemon@ATHENA.MIT.EDU (vanharen@MIT.EDU)
Thu Apr 9 18:52:10 1992
From: vanharen@MIT.EDU
Date: Thu, 9 Apr 92 18:51:25 EDT
To: arteam@MIT.EDU, release-74@MIT.EDU
Cc: trb@MIT.EDU
The following discussion is fairly technical and long. I wonder whether
this is really an issue which should be decided by the Technical Review
Board -- at least the implementation details anyway.
The interface issues should be addressed by the ARTeam, though, I think.
One of the items which I was slated to do for the 7.4 release was
enhancements to dash -- specifically, changes to make it deal with color
displays better.
*** QUESTION/PROPOSAL ON COLOR/GRAYSCALE DEFAULTS FOR DASH/CONSOLE ***
What do people think of having Dash and/or console come up with some
colors, by default, on color displays? (Similarly, grayscale defaults
on grayscale displays.) There is some opposition to the idea, from some
people I have talked to. However, I can see no reason why this is "bad"
-- there is already precedence for it, as well (any Motif program --
olh, xolc, xcal, mwm).
Apart from the question above is the messier issue of implementation.
Normally, implementation is left to the programmer, but what I am
proposing has possible effects on other things.
Ignoring the implementation question for the moment, I propose that we
DO have color/grayscale defaults for the appropriate display types.
It raises the question as to what the colors should be, but I think that
some colors can be chosen that most people will not take offense at,
anyway. Maybe a toned-down version of the motif default colors, I
don't know.
*** BACKGROUND ON SPECIFYING COLOR/GRAYSCALE DEFAULTS USING XT ***
NOTE: For those of you who understand how users can specify color and
grayscale defaults already, you can skip to the next section.
Users already have the ability to specify seperate resource for mono,
grayscale, and color displays in their .Xresources files. The syntax
goes basically like this:
#ifdef COLOR
xclock.foreground: red
#elif (CLASS == StaticGray || CLASS == GrayScale)
xclock.foreground: gray75
#else /* MONO */
xclock.foreground: white
#endif
The reason that this works is that xrdb (which is automatically run when
you log in) passes the .Xresources file through cpp (the C
pre-processor) before merging the resources into the X resource
database. The appropriate symbols are defined by xrdb, so that cpp can
check for "COLOR", etc.
The only problem with this (besides the lovely syntax) is that cpp is
*not* used on system app-defaults files, so programmers do not have the
same ability to specify color defaults, etc.
X11r5 provides a mechanism for specifying alternate app-defaults files
for color, mono, and grayscale displays, but it is unlikely that we are
going to be switching to X11r5 for this release.
*** TECHNICAL QUESTIONS/PROPOSAL FOR SPECIFYING DEFAULTS IN DASH/CONSOLE ***
The concept I had in mind (and have already implemented, though it is
easy enough to back out, or maybe change) is as follows...
Wherever a color (such as foreground or background) is specified, the
user is allowed to specify THREE items instead of one. By way of
example, a user might write:
xclock.foreground: white,gray75,red
On a black&white display, white would be used, on a grayscale, gray75 is
used, and an a color display, red is used.
If only TWO items are specified, then the first is used on b&w, and the
second on grayscale and color.
If only ONE item is specified, then it is used on all 3 display types.
In this manner, it is backwardly compatible with the standard Xt method
of specifying colors.
The ADVANTAGE here is that I, as a programmer, can specify defaults
appropriate for each display type.
The DANGER is that users may assume that this method of specifying
colors applies to ANY program that uses Xresources, and this is
certainly NOT the case. Dash shares similar syntax with Xt programs,
but is entirely different code -- most users are probably not aware of
this fact, which is both good and bad. I would add, though, that the
danger is probably minimal, since most users probably do not read the
app-defaults files for most programs.
We could do some damage control by adding comment lines to dash and
console's app-defaults files, pointing out that this syntax was
non-standard, and only applicable to dash and console.
It would be trivial to write a routine for Xt which would provide the
same functionality that Dash has. However, in order for it to be in
effect for all programs built on Athena, it would need to be either:
(1) linked into each program on a case-by-case basis, or (2) compiled
into our X libraries, making them non-standard. Neither of these
solutions is optimal, and so I would simply propose writing the routine
and submitting it back to the X Consortium for possible inclusion into a
future release of X.
We could include that routine in selected programs (xlogin is one liekly
candidate) so that it has color defaults for color screens. Again, we
would have to be careful to add comments to the app-defaults file to
point out that this was non-standard. The reason that I pick on xlogin
is that it would be useful to be able to have some color on the xlogin
screen so that people could identify the machines as being color before
logging in. (Actually, I think it was Mark Rosenstein that had this
idea.)
-Chris.
