Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: invalid resources
Message-ID: <9007282124.AA00523@expire.lcs.mit.edu>
Date: 28 Jul 90 21:24:27 GMT
References: <5677@hplabsz.HPL.HP.COM>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 47


    I don't care about the IMPLEMENTATION issues involved in doing this.

Then you are being unrealistic.  Efficiency (or lack thereof) of Xt-based
toolkits is a major issue right now.  Performance is not to be dismissed
lightly.

    From a PROGRAMMERS PERSPECTIVE, it is completely unreasonable for a widget
    to remain silent when you set the wrong resource (either at creation time,
    or during XtSetValues())...

I don't know precisely what you mean by "at creation time".  Nor do I know
what being not "silent" means to you.  If you care to back up the complaint
with a thoughtful exposition of the problems (with cogent examples) and
desired changes, you are more likely to get somewhere.  As you are an
employee of a Consortium member, you should also know that there is a
Consortium channel that could be used for this discussion, which might
(or might not) be more effective.

    From an END-USERS PERSPECTIVE, it is unreasonable for no errors to be
    reported when a user sets the wrong resource in an .Xdefaults, app-default
    or xrdb file.

This is a nice general statement to which I have a very hard time attaching
any meaningful semantics.  For example, I have in my defaults file:
	*ShapeStyle: Oval
Should every widget in the universe that doesn't have such a resource go
blatting out somewhere that I tried to set a bogus entry at creation time?
You'll need to be much more precise about what your complaint is.

    How many times have you had to deal with a clueless user who
    claims your program is buggy because they mispelled a resource name and
    therefore the program didn't work right?

There are solutions to this problem.  But since I haven't really seen what
you propose the solution to be, it's hard to compare.

    How many end-users want to have the internals of the Xtoolkit
    and X resources mechanisms explained to them in response to the problems 
    outlined above?

None.  But I suspect most end-users also don't want to specify resources
the way they are specified today (with a text editor).  It is possible that
a better interface to resource specification will go a long way towards
helping with this problem.  I don't claim it's a complete solution.  But
until I understand better what your complaints really are, it's hard to
get very far.