🚀 go-pugleaf

I'm writing an application using Xlib (no toolkits) and I'd like
to use the X Resource Manager for my user-configurable parameters.

I've read what doc I can get my hands on (no R4 pieces), and I think
I understand the basic usage of Xrm and how resources should be named
and put into classes (recall, I don't use any widgets).

I'm having trouble understanding how to deal with certain aspects of
the tools.  Perhaps there is no really elegant or standard way to do 
some of these things, or (I'm hoping) I've just missed it.  

On to the questions....

1.  Should the fundamental application defaults be completely specified
(with tightly bound instance names), or should they as loosely 
specified as possible (with class names)?  

If the former, then it seems that the user is then forced to always use 
completely specified instances to override my application defaults (which 
then completely defeats the advantage of having classes and loose binding).  
The latter isn't totally intuitive though, as a mechanism for ensuring SOME 
value is set.

2.  Even using loosely specified application defaults, it seems that
I will still have to hardcode stopgap settings in case the user 
specifies a bogus value for a resource.  This seems pretty clunky to me....

3.  I've seen three different suggestions of how to set the user's 
resources.  Since I'm not very familiar with any other X applications
(or how xrdb is usually invoked), I'm not sure what (if any) "standard" 
exists.  Obviously, I should read my app-default file first, and then 
the resources in the server, and finally command line options.  If there 
are no resources set in the server, then I should look in XENVIRONMENT 
for a file, and if that's not set, then I should look in $HOME/.Xdefaults.  
Is is reasonable to skip both XENVIRONMENT and .Xdefaults if the resources 
are set in the server (by which I mean in the XA_RESOURCE_MANAGER property 
on the root window)?

4.  It seems that the RM is designed so that ALL configurable parameters 
should be put in the resource database; that way I have a single method 
of setting/retrieving them.  But some parameters are not necessarily 
appropriate for users to set or are strictly run-time options (such as 
-debug).  It is sufficient to simply not document them, or should I not 
make them resources?

5.  Specifically, should there be display and name resources?  They are
obviously important command line options, and XrmParseCommand is very 
handy for dealing with command line options.  Is it a problem if these 
are resources?  (They certainly don't make sense being set as resources.)
If display is considered a valid resource, and it's not set on the
command line, should it really be searched for in the other resource
specifications, or should it just default to $DISPLAY (which means that
setting the display resource is always ignored!)?

6.  A large part of the reason I want to use the RM is so that resource
changes made while my application is running are immediately affected.
I understand I look for PropertyNotify events and call XGetWindowProperty
for the XA_RESOURCE_MANAGER property, which gives me the new server 
resource database string (and I can tell if something changed, or was 
simply deleted).  But I can't detect WHICH resource changed, so I need
to go reinitialize ALL my (dynamically settable) variables from resources 
using this new database (seems like a big waste of cpu cycles!).  For 
completeness it makes sense to add them in to my local database as well 
(in case I need to retrieve a value from there later).

7.  Am I right in thinking there is no way to create a SearchList which
has only all the values possibly appropriate for my application (assuming 
I have some resources which have more than a single component name: 
e.g., myapp.menu.font)?  The SearchList routines appear to be of limited 
usefulness (since I have to specify all but the final component of my
resource name), which is unfortunate, since it seems like a great 
timesaver (considering the gobs of resources users are probably going 
to start specifying once all our apps are super-configurable via 
resources).

Any guidance about use of the Resource Manager would be greatly appreciated!

julie spiegler
[uunet|ucscc.ucsc.com|ucscc.ucsc.edu]!cruc!julie