casey@gauss.llnl.gov (Casey Leedom) (10/05/90)
A while back someone asked whether it was ``good etiquette'' for an
application resource file to define specific fonts for application
resources. People were concerned because such application specific
definitions override more general definitions like *Font that a user
might set up.
If I remember right most people felt that specifying application fonts
was bad etiquette. Yet I keep on running into programs which do.
In the same vein, I keep on running into application resource files
which spend a lot of time defining which colors to use in which buttons,
etc. which almost invariably don't work right on monochrome displays.
Since a majority of our workstations are monochrome I spend a lot of time
commenting out all those carefully wrought color setups. I did run into
one application that put ``#ifdef COLOR ... #endif'' around those
definitions, but of course that was useless since application resource
files aren't passed through cpp.
I'd like to hear peoples comments on the following with respect to
application resource files:
1. Should fonts be defined?
2. Should colors be defined?
3. Is there any way to allow colors to defined, but only for color
displays? (Short of using two different resource files which
the application picks between based on the display.)
Caseyrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/05/90)
People were concerned because such application specific
definitions override more general definitions like *Font that a user
might set up.
We're working on a (simple) solution to this problem.
In the same vein, I keep on running into application resource files
which spend a lot of time defining which colors to use in which buttons,
etc. which almost invariably don't work right on monochrome displays.
We're also working on a (simple) solution to this problem.dce@smsc.sony.com (David Elliott) (10/05/90)
In article <69294@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes: |> In the same vein, I keep on running into application resource files |> which spend a lot of time defining which colors to use in which buttons, |> etc. which almost invariably don't work right on monochrome displays. |> Since a majority of our workstations are monochrome I spend a lot of time |> commenting out all those carefully wrought color setups. I did run into |> one application that put ``#ifdef COLOR ... #endif'' around those |> definitions, but of course that was useless since application resource |> files aren't passed through cpp. I had a discussion about this recently, and the result was two ideas: 1. Add simple preprocessing to the X resource manager. Allow only a simple subset of the xrdb variables, the #ifdef, #else, #endif, and #define operations, and a subset of #if (maybe only string equality and inequality, and simple number comparisons like <, =, and >). 2. Modify the color namespace to handle "fallback" colors, which would allow the user to specify the desired color and the color to use if that can't be handled. The example that prompted this was a set of users that had their xterms set up to be black with green characters. When they used a black and white screen, the result was black with black characters. A fallback scheme would allow the user to say XTerm*background: black XTerm*foreground: green(white) So that instead of the foreground going back to the default (black) if green can't be handled, white is used. The second idea here is OK (please allow me at least some vanity ;-), but could be too confusing. -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."He'll become the Sun. We must have one you know" "Oh"
rlh2@ukc.ac.uk (Richard Hesketh) (10/06/90)
In article <1990Oct5.155651.7094@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes: >2. Modify the color namespace to handle "fallback" colors, which would > XTerm*background: black > XTerm*foreground: green(white) > > So that instead of the foreground going back to the default (black) > if green can't be handled, white is used. > >The second idea here is OK (please allow me at least some vanity ;-), but >could be too confusing. Whilst a complete (or at least better) solution is being developed this actually looks quite useful right now. For toolkit programs all it requires is a change in the StringToPixel converter which checks to see what type of screen this conversion is being made on and chooses the appropriate colour. Here's a patch to mit/Xt/Converters.c [patchlevel 18] (you can apply the patch then rip the converter out and put it in your own programs) that changes the StringToPixel converter to recognize the following format: XTerm*foreground: green/white I use a slash "/" because its easier to parse 8-). I really don't think it is any more confusing than specifying any other resource! The first colour is chosen if the screen has a depth greater than one. *** Converters.c.dist Sat Sep 29 16:46:26 1990 --- Converters.c Sat Oct 6 16:46:10 1990 *************** *** 351,357 **** XrmValuePtr toVal; XtPointer *closure_ret; { ! String str = (String)fromVal->addr; XColor screenColor; XColor exactColor; Screen *screen; --- 351,357 ---- XrmValuePtr toVal; XtPointer *closure_ret; { ! static String str = NULL; XColor screenColor; XColor exactColor; Screen *screen; *************** *** 360,365 **** --- 360,366 ---- Status status; String params[1]; Cardinal num_params=1; + String slash; if (*num_args != 2) XtAppErrorMsg(pd->appContext, XtNwrongParameters, "cvtStringToPixel", *************** *** 369,374 **** --- 370,393 ---- screen = *((Screen **) args[0].addr); colormap = *((Colormap *) args[1].addr); + + if (str != NULL) + XtFree(str); + + str = XtNewString((String)fromVal->addr); + slash = str; + while (*slash && *slash != '/') + slash++; + + if (*slash) { + if (DefaultDepthOfScreen(screen) == 1) { + /* use fallback colour for monochrome screens */ + slash = XtNewString(slash+1); + XtFree(str); + str = slash; + } else + *slash = '\0'; + } if (CompareISOLatin1(str, XtDefaultBackground) == 0) { *closure_ret = False; --- Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!{mcsun|mcvax}!ukc!rlh2 Computing Officer, Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/7590 Fax: +44 227 762811
casey@gauss.llnl.gov (Casey Leedom) (10/07/90)
/ From:,dce@smsc.sony.com (David Elliott) | | 2. Modify the color namespace to handle "fallback" colors, which would | | XTerm*background: black \ XTerm*foreground: green(white) / From: rlh2@ukc.ac.uk (Richard Hesketh) | | Whilst a complete (or at least better) solution is being developed this | actually looks quite useful right now. For toolkit programs all it requires is | a change in the StringToPixel converter which checks to see what type of | screen this conversion is being made on and chooses the appropriate colour. | | Here's a patch to mit/Xt/Converters.c [patchlevel 18] (you can apply the | patch then rip the converter out and put it in your own programs) that | changes the StringToPixel converter to recognize the following format: | | XTerm*foreground: green/white | | I use a slash "/" because its easier to parse 8-). I really don't think it | is any more confusing than specifying any other resource! The first colour \ is chosen if the screen has a depth greater than one. 1. Thanks for your incentive and investigation into this, but don't you think that publishing a note like yours will cause an explosion of non-portability as some people impkement your patch and others don't? Or are you an official spokesperson for the X Consortium? (Not sarcasm. An honest question.) 2. Nit picking time: wouldn't it be more consistent to use colons (`:') as your color name separator as is done for other alternate choices? In any case I'm glad to hear people are working on this problem. It's really annoying to have to either sanitize every program or include lots of redundant font and color definitions in my own resource database. Casey
mouse@LIGHTNING.MCRCIM.MCGILL.EDU (10/07/90)
>> 2. Modify the color namespace to handle "fallback" colors, which > Whilst a complete (or at least better) solution is being developed > this actually looks quite useful right now. > Here's a patch to mit/Xt/Converters.c [patchlevel 18] [...] The > first colour is chosen if the screen has a depth greater than one. Not to detract from a useful hack, but.... This is a good example of the sort of nonportable assumption people make that renders their programs hard to use on unusual servers. I have seen 8-bit grayscale Suns. There is also a NeXT next to my desk whose only visual is a 2-bit StaticGray visual. Either of these would break this patch; the NeXT would break it worse, of course. And though I've not heard of such a thing existing, a 3-bit StaticColor display having the normal eight "primary" colors in its colormap would also break it. As I said, this is not to detract from something many will find useful. I just want to make sure that people using this patch realize that it is a stopgap measure and should not be considered as a proper fix to the problem. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dce@smsc.sony.com (David Elliott) (10/07/90)
In article <69391@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes: |> 1. Thanks for your incentive and investigation into this, but don't |> you think that publishing a note like yours will cause an explosion |> of non-portability as some people impkement your patch and others |> don't? Or are you an official spokesperson for the X Consortium? |> (Not sarcasm. An honest question.) I don't think this is exactly fair. I believe that it is understood that code and patches sent to comp.windows.x and xpert are unofficial and unsupported. Most people tend to use these items as emergency stopgaps, and do not incorporate these things into their work. Of course, Richard did suggest it, so people might... |> 2. Nit picking time: wouldn't it be more consistent to use colons (`:') |> as your color name separator as is done for other alternate choices? Where are there other alternate choices in X? (Just interested.) As a side note, I think that the method of choice in the code change is incorrect. The original description said that the fallback should be used if the color request fails. This deals cleanly with all screen depths and visual classes, not just 8-bit PseudoColor and StaticGray. In any case, I don't like this solution myself because it is yet another syntax for the poor user to have to learn. The person who suggested this scheme should be slapped. -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."He'll become the Sun. We must have one you know" "Oh"
dce@smsc.sony.com (David Elliott) (10/07/90)
In article <1990Oct7.050129.21669@smsc.sony.com>, dce@smsc.sony.com (David Elliott) writes: |> In any case, I don't like this solution myself because it is yet |> another syntax for the poor user to have to learn. The person who |> suggested this scheme should be slapped. Oops. Just in case there is any misunderstanding, the "person who suggested this scheme" does not refer to Richard or Casey, but to that Elliott character. -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ..."He'll become the Sun. We must have one you know" "Oh"
casey@gauss.llnl.gov (Casey Leedom) (10/07/90)
/ From: casey@gauss.llnl.gov (Casey Leedom) | | 2. Nit picking time: wouldn't it be more consistent to use colons (`:') \ as your color name separator as is done for other alternate choices? / From: dce@smsc.sony.com (David Elliott) | \ Where are there other alternate choices in X? (Just interested.) Actually *BitmapFilePath is the only example I can think of. It's a weak precident but a precident nevertheless ... :-) Personally I can hardly wait for the Simple And Elegant solution Bob has promised us. :-) :-) Casey
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/07/90)
Personally I can hardly wait for the Simple And Elegant solution Bob has
promised us. :-) :-)
I said simple, not necessarily elegant. :-) One of the things I'm concerned
about is backwards compatibility: is it possible to introduce "customization"
features into R5 while still permitting an R4 executable to share the same
resource file (whether app-defaults or .Xdefaults). This seems important to
me (although others might disagree), and it's what argues against syntactic
changes such as altering color names, and a previous (unrelated) suggestion
about adding grouping mechanisms for resources.
On the subject of colon vs. slash, be warned that in R5 there may well be
a convention for "color space" prefixes in names, e.g. "rgb:444" instead
of "#444" (old syntax still supported, of course), with multiple spaces
supported.marbru@auto-trol.UUCP (Martin Brunecky) (10/07/90)
In article <9010051240.AA25524@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: > People were concerned because such application specific > definitions override more general definitions like *Font that a user > might set up. > >We're working on a (simple) solution to this problem. > >We're also working on a (simple) solution to this problem. Can we get some hint(s) about what that (simple) soultion is suppoosed to be before it is thrown on us in R5 implementation ? [ or, is there a way to get involved if I myself can not afford to become an XConsortium member and my eployer does not want to ? ]. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/08/90)
Can we get some hint(s) about what that (simple) soultion is suppoosed
to be before it is thrown on us in R5 implementation ?
Before being adopted, such changes would be put out for public review, and
would be announced via xannounce.
[ or, is there a way to get involved if I myself can not afford to become
an XConsortium member and my eployer does not want to ? ].
Sorry, no there isn't.