🚀 go-pugleaf

> 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.

Agreed.  We are looking into solving this problem by giving the user greater
control.  Until that time you should attempt to bind resources as loosely as
you can.  One common way to do this is that when you load in your "application
default resource file" you specify the resource w/o the application name.

e.g

*foreground:	blue

Since things to the left bind more tightly than things to the right, and the
user will need to specify an application name in his .Xresources file he should
almost always override your default values.  This method is not completely
satisfactory, but it is as good as you can get currently.

> 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....

What?!  If you want to be nice your should check to see of teh value is 
aceptable, but it is certainly okay to fail to run if you resource are
specified incorrectly.

% foobar
foobar:		Resource value "a.b.c.d.d" must be an integer greater than 1.
%

Or put up an error dialog if you are exclusivly window based.

> 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.

There is no "standard" set of places to load resources in XLib, just a bunch of
functions to operate on them.  What most people have done is use the same set
of files and locations that Xt uses.  This is becoming the de-facto standard
location for resource files.

> 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?

That is up to you.  "mechanism not policy"...

> 5.  Specifically, should there be display and name resources?

You need to know then before you look up your resources.  Therefore these
don't really need to be resources.  But I suppose you could stuff then in your
database of you wanted to.

> 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.

Xrm wasn't designed to deal with dyamic change to the database and I don't know
of any application that attempts to use the resource manager this way.  It you
do this you are on your own.

> 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)?

I don't know.  You might want to take a look at the R4 client "appres".


						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213