[comp.windows.x] Question about App-defaults

rjc@uk.ac.ed.cstr (Richard Caley) (10/21/90)

Hi, sorry if this is a silly question but...

After  a little experimentation I have convinced myself that an
application default file always overrides my resource settings. Why?
Is there some reason for this which eludes my poor addled user level
mind? 

It seems to negate the purpose of app-defaults since they can't be
used to set _defaults_, only to _force_ settings.

Scenario as follows. We have an application which creates a load of
buttons etc. The person writing the X code (Hi Rick) wants to set
default fonts, button labels etc. but not to hard wire them into the
code, so he put them into the app-defaults file --

	*Command*font:	 -*new century schoolbook-medium-r-*-*-10-*

Now, being awkward I like my buttons in bold italics, so I have in my
.Xdefaults ( downloaded by xrdb ) --

	*Command.font: -*-new century schoolbook-bold-i-*-*-10-*-

When I run it it comes up with Roman button labels.

Just to confuse matters if I don't download it and rely on Xlib looking
for .Xdefaults, I get bold italic.

Now, we could make the app-defaults contain only class definitions so
that my definition is more specific and so would override, but that
looses both programmer and user the class-instance distinction and
would probably not work in general anyway (eg. a widget with 2 `Font'
class resources).

I assume _this_ is the reason it is such a pig to change the title on
an Xman window...

Explanations gratefully received.

--
rjc@uk.ac.ed.cstr

rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (10/22/90)

    After  a little experimentation I have convinced myself that an
    application default file always overrides my resource settings.

This is certainly untrue (at least in a correct implementation).  However, it
is certainly true that it is currently not possible for the end-user to apply
global overrides (viz., ones that always apply to all applications, not just
a specific application class or instance).  A solution to this is currently
under review in the X Consortium.

	*Command.font: -*-new century schoolbook-bold-i-*-*-10-*-
    When I run it it comes up with Roman button labels.

Perhaps because no fonts match?  (At least, none match against my server.)
The left-hand-side above should override "*Command*font:", so I think your
problem here must be a bad font name.  Substituting a different font in the
above line properly overrides for me, anyway.

    Just to confuse matters if I don't download it and rely on Xlib looking
    for .Xdefaults, I get bold italic.

Sorry, I can't explain that.  Perhaps there is something else going on that
you haven't told us about.

rjc@uk.ac.ed.cstr (Richard Caley) (10/23/90)

Summary: I was confused, the problem is not where I thought it was.

In article <9010221233.AA01306@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:


	[ Me... ]
	After  a little experimentation I have convinced myself that an
	application default file always overrides my resource settings.

    [ commants about global overides ]

	    *Command.font: -*-new century schoolbook-bold-i-*-*-10-*-
	When I run it it comes up with Roman button labels.

    Perhaps because no fonts match? 

This was a typo when I composed the message, delete the last `-' and
that was what I had.

    The left-hand-side above should override "*Command*font:", so I think your
    problem here must be a bad font name.  Substituting a different font in the
    above line properly overrides for me, anyway.

It may be a problem with the program, I get less obscure behaviour
from XClipboard. 

I think the real source of most of my confusion was that the program
was picking up app-defaults from my home directory Since I had copied
the app-defaualts file to have a look at it and didn't realise this I
was finding defaults I did not think I had.

This does not seem to be in the X manual page, though it is down there
in the Xt documentation for those diligent enough to search the
programmer documentation before using the system.

Sorry for bothering people with what apears to have been a
non-problem.

--
rjc@uk.ac.ed.cstr