julie@cruc.UUCP (Julie Spiegler) (03/01/90)
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
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (03/03/90)
> 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