Newsgroups: comp.windows.x.intrinsics
Subject: Re: default resources
From: tp@mccall.com (Terry Poot)
Date: Wed, 30 Sep 1992 16:55:08 CST
Reply-To: tp@mccall.com (Terry Poot)
Distribution: world
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-User: tp


In article <lcj9i2INN1tf@utkcs2.cs.utk.edu>, wade@austin.cs.utk.edu (reed wade)
writes:
>Also, I would prefer to avoid requiring people to install an app-defaults 
>file. Our main audience tends to be fairly naive with regard to installing
>software and would need to have someone else install an app-defaults
>file. 
>
>What I had in mind was for my widget to load a different XtResource struct
>at instantiation so that I could have different default colors depending.

How about fallback resources? The application could have a different set of
fallback resources for different situations (color/grey/mono being only one
case). Instead of XtAppInitialize, use the component routines. Open the display
with XOpenDisplay, find out what kind of server you have and select the
appropriate fallback resources. Pass these to XtAppSetFallbackResources. Then
call XtDisplayInitialize.

By using fallback resources, you still allow any other form of tricks with
app-defaults files, such as those David Brooks discusses. Without R5 you could
conceivably just use multiple app-defaults files and change your application
class name depending on the server type.

I've never done this, but I might have to some time, so I'm interested in
whether this approach would work (or what a better one would be). I know it's
bad form, but in my apps, I do this at run-time, which means the colors aren't
customizable. After I manage my widgets, but before I realize them, I change the
color resources based on the server type. (I do it before realizing, because
sometimes I change the visual for testing purposes, and you can't change the
visual of a window once it is created, I believe. So I just do all the color
hacking between the XtManageChild and the XtRealize.)

I suppose you could use application resources that the code could reference to
get the colors. That way the resources wouldn't be tied to the widgets directly,
so you could have a different resource for each server type, all user
customizeable, and at run time, you'd choose the appropriate ones and set your
widget resources before realizing them. Of course, this loses you the Xrm sort
of matching, allowing you to easily customize particular widgets. But it would
be suitable for an application that only needed a few colors, and used them
everywhere throughout the application consistently (mine are like that).

I suppose another way would be to use Xrm routines directly. DEC's session
manager seems to do something along these lines. It has a resource file for
non-color resources, and different resource files for the color resources. I.e.
they have a color version, a bw version and a grey version, only one of which is
used at a time, depending on the server. I'm only guessing, but they must be
explicitly merging the resource databases. Maybe someone out there from DEC can
tell us exactly how that is done.
--
Terry Poot <tp@mccall.com>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
(800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
Newsgroups: comp.windows.x.intrinsics