Conference unxa::cde

    I do not know the exact resources used, but I think you will find that
    each of these applications uses slightly different X resources to
    specify the same *effective* resource.  Some use a class name in front
    of background, others use a different format.  Still others hard code
    the characteristics, or use a resource file that overrides .Xdefaults. 
    The resource names *look* similar, but I've found the names and orders
    they are searched to differ.
    
    In the case of dxterm, for instance, between ULTRIX and Digital UNIX,
    the name of the first resource file searched changed.  [That turned out
    to be good for me because a few of the resource names ALSO changed, so
    I could not use a common resource file for both.]
    
    If you are interested in how I get around all of this, send mail to
    quarry::masinick or [email protected].  My .Xdefaults is overkill,
    but by also using application-specific resource files for certain CDE
    and X applications, I get the results I want.
    
    Brian   16-APR-1997 14:22:13

    You might also want to experiment around with editres.  Editres is the
    X Resource Editor.  From it, if you learn how it works, you can figure
    out the full name of all supported resources for any application (even
    some you've never heard of).  This is how I found some of the weird
    differences in resource names to begin with.
    
    Brian   16-APR-1997 14:28:51

>>>So first question is: what resource name is used for the 'white' colour; I can't
>>find a resource containing it, so how does dtterm (for example) know to use the
>>'white' colour for its background)?  NB: it isn't pure white, so it isn't
>>re-using colour cell 0 or 1, whichever of those is white.
>>

foo*background: FFFFFFFFFFFF
will set application "foo"'s background to white.

>>Can I change, within CDE, how CDE defines *background?

Not easily. CDE wants to be able to change the default background based
on color palette selection. So the problem is that your .Xdefaults is
read, but then later the color palette is processed. Unless application
specific color resources are selected, the palette is supposed to provide
the final values.

>>So: how can I make my .Xdefaults take priority over what CDE thinks I should
>>have?  The man page for dtsession implies that .Xdefaults has top priority, by
>>virtue of being loaded last, but this doesn't seem to be the case.

Since you want to override what the CDE color object model code wants to
do, you'll need to create "*background" resources for each application,
or find out what is causing the default "grey" background.

Check your .Xdefaults for a line like

#ifdef COLOR
!!*Background:  #e6e6e6e6e6e6
!!*Foreground:  #000000000000
#endif

Note that I have these lines commented out in my .Xdefaults. Before this,
certain applications wound (eg, dtpad) wound up with a different background
than I expected. These are legacy entries from when I ran DECWindows.

>>And/or: how can I make CDE save the 'current' colour values in
>>session/dt.resources when I exit the session?

CDE only wants to deal with this with regard to palette selection.

.1/.2: Brian, Thanks for the pointer to editres, I shall play with that later...

.3:

>> foo*background: FFFFFFFFFFFF
>> will set application "foo"'s background to white.

Yes, I know this and it's what I've done to work round the problem.  What I'm
trying to find out is: in which resource does CDE 'store' the active palette
colours, so that applications like dtterm can find and use them?  Or maybe it
doesn't use resources at all, in which case how does dtterm 'know' what colours
to use (for example, do CDE-compatible applications 'know' that they're always
supposed to use colour cell 'x' in the default colour map for their background)?

>> CDE wants to be able to change the default background based
>> on color palette selection

Hmmm, but in this case the 'problem' colour is one of the ones that I explicitly
set in the palette, not one of the black-white pair, etc, that CDE automatically
flips between for maximum contrast.  [As an aside, it doesn't flip the text
colours for the wording in Style Manager et al, which is a real pain!].  Also,
the white colour (actually FFFFFFFFF0F0) I set *is* the colour that CDE uses for
lots of backgrounds.  I'm just trying to figure out why it *isn't* the one it
then puts in *background!

Yes, obviously if I change colour palette CDE is at liberty to recalculate all
the non-explicitly-set colours, but if I set up a colour palette and associated
resources in a particular way, and then don't change anything, I would like CDE
to preserve those settings between sessions, particularly as it saves a value
for *background (but not the current value!) as part of the session data.  After
all, isn't that the whole point of CDE?

>> the palette is supposed to provide the final values.

In which case the facilities within CDE for setting colours / palettes would
seem to be inadequate.  Things were sometimes obscure / convoluted with
dxsession and Mwm, but at least I could set them all! :-)

>> or find out what is causing the default "grey" background

That's easy.  It's the colour (light grey) I explicitly set for non-active
window borders in the palette.  CDE also uses it for non-text backgrounds (eg
the front panel, that's OK), but has unfortunately put it in the global
*background.  More confusing is where the dark grey comes from that File Manager
et al use for their non-text backgrounds; that isn't one of the colours in the
palette at all, or in .Xdefaults.

The only colour settings in my .Xdefaults are:
    DXterm.main.terminal.background: #FFFFFFFFF0F0
    *background: #FFFFFFFFF0F0

to undo the CDE settings.

>> the problem is that your .Xdefaults is
>> read, but then later the color palette is processed

I think I can solve this by manually re-reading .Xdefaults (xrdb etc) in
.dtprofile, although it's unfortunate that it's necessary.

Thanks for the info so far,
Scott