jtc@van-bc.UUCP (J.T. Conklin) (02/27/90)
I am writing a set of utilities, lets call it the "foo" toolkit,
that, for reasons of end-user flexibility, I would like to have
system-wide and per-user configuration files.
I was thinking about a /usr/local/lib/foo/app-defaults/*, for
the system configuration, and a ~/.foodefaults file for the
per-user configuration.
My thoughts are that I could write a set of wrapper functions that
clean up the interface to the RM (perhaps like is done in Xt?) and
use that.
Should I do that, or should I be looking at a different approach?
--jtc
--
J.T. Conklin
...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.caglennw@crevasse.WV.TEK.COM (Glenn Widener;;61-049;;orca) (03/06/90)
J.T. Conklin writes:
< I am writing a set of utilities, lets call it the "foo" toolkit,
< that, for reasons of end-user flexibility, I would like to have
< system-wide and per-user configuration files.
< I was thinking about a /usr/local/lib/foo/app-defaults/*, for
< the system configuration, and a ~/.foodefaults file for the
< per-user configuration.
< My thoughts are that I could write a set of wrapper functions that
< clean up the interface to the RM (perhaps like is done in Xt?) and
< use that.
< Should I do that, or should I be looking at a different approach?
I take it that you are asking for a simple XGetDefault-like interface to
the Xlib Xrm facility, that uses Xt-like database initialization, for
non-Xt Xlib clients. My belief is that such a facility in Xlib is long
overdue, and I will be proposing it for R5. In the meantime, I'd
recommend that you steal the Xt XtInitialize code and remove all the
widget-isms (which is basically what I will propose for Xlib.) Your call
interface might be something like:
XrmCreateDefaultDatabase(dpy, res_name, res_class,
options, num_options,
argc, argv, argc_return, argv_return,
database_return)
Display dpy;
char *res_name;
char *res_class;
XrmOptionDescRec *options;
int num_options;
char *argv[];
int argc;
char **argv_return[];
int *argc_return;
XrmDatabase *database_return;
XOpenInitializeDisplay configures a resource database for a display and
supplied command line and options description.
XOpenInitializeDisplay returns a resource database which has been loaded
from the conventional locations:
- Application-specific class resource file on the local host or by
XSetFallbackResources
- Application-specific user resource file on the local host
- Resource property on the server or user preference resource file on
the local host
- Per-host user environment resource file on the local host
- Application command line (argv)
...
Per Xt spec.
char *XrmGetDefault(display, database, resource, resource_class)
Display *display;
XrmDatabase database; /* In: resource database */
char *resource_name; /* In: resource name specifier, in ASCII */
char *resource_class; /* In: resource class specifier, in ASCII */
display Specifies the connection to the X server.
resource_name Specifies the resource name.
resource_class Specifies the resource class. If NULL, defaults to the
resource argument with the first letter of each
(dot-separated) component upper cased.
Resource_name and resource_class are prepended with the res_name and
res_class supplied by XOpenInitializeDisplay for the specified display.
XrmGetDefault returns the value NULL if the requested resource does not
exist. Note that it is permissible for resource or resource_class to
contain a hierarchy of names, separated by ".", e.g. or
resource="exitButton.font" resource_class="Myprog.Cae". The number of
resource and class names should always match.
Glenn Widener
Tektronix, Inc.jtc@van-bc.UUCP (J.T. Conklin) (03/07/90)
In article <6337@orca.wv.tek.com< glennw@crevasse.WV.TEK.COM (Glenn Widener) writes: |> My thoughts are that I could write a set of wrapper functions that |> clean up the interface to the RM (perhaps like is done in Xt?) and |> use that. | |> Should I do that, or should I be looking at a different approach? | |I take it that you are asking for a simple XGetDefault-like interface to |the Xlib Xrm facility, that uses Xt-like database initialization, for |non-Xt Xlib clients. You have the right idea, but in my case the only reason the application is linking Xlib is for the resource manager routines. |My belief is that such a facility in Xlib is long |overdue, and I will be proposing it for R5. In the meantime, I'd |recommend that you steal the Xt XtInitialize code and remove all the |widget-isms (which is basically what I will propose for Xlib.) I have started to do this. When I'm done, I should have a "resource manager" library totally separate from X. --jtc -- J.T. Conklin ...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.ca