Article View: comp.windows.x
Article #24011Re: X.V11R4 resource inheritance hassles
From: Casey Leedom
Date: Fri, 21 Jun 1991 04:53
Date: Fri, 21 Jun 1991 04:53
142 lines
6816 bytes
6816 bytes
[[I've cc'ed this to XPERT since I think it may be interesting to many
others.]]
/ From: casey@gauss.llnl.gov (Casey Leedom)
| Subject: Xmail 1/PL3: fixes
| Date: Wed, 19 Jun 91 13:36:46 -0700
|
| In addition to the fixes below [[omitted]], I had to delete all
| references to color in your XMail.ad file. We have way too many
| monochrome machines to play with colors that way. Besides, even people
| who have color displays are pissed off at color definitions in
| applications default files. They have their buttons, borders, etc. all
| set up the way they like. When an application defines its own color
| scheme they have to copy all the color definitions out of the
| applications default file and change them back to what they want. This
| basically totally screws up the whole concept of personal defaults. This
| comment also applies to font definitions. Please don't include
\ preference type resource specifications in an applications default file.
/ From: michael@berlioz.nsc.com (Michael Wagnitz)
| Subject: Xmail 1/PL3: fixes
| Date: Wed, 19 Jun 91 15:01:29 PDT
|
| I have no problem with the default color definitions when running xmail
| on a monochrome machine (Sun 3/60M). Thus I don't have a clear
| understanding of your objections. The xmail application defaults file is
| set up for the non-sophisticated X user. What fonts would you have me
| default to (none?!?) if I don't specify something in the app-file?
| Fixed!?! (Yuch. %^) I made the change from source code specifications to
| using the resource file, at your request. This has already generated
| four mail requests for assistance from readers on the net who had not
| taken the time to a) read the documentation, or b) install the
| application defaults file, and who did not understand the apparent
| changes.
|
| The fact that your people are setting their preferred colors another way
| is fine, but don't expect me to cheat other users at the preference of
| yours. (This is not a flame, I just wanted a default xmail to come up on
| a color machine in other than black-and-white.) Since you obviously
| understand your user's and their environments better than I, it seems
\ simple enough to make the necessary changes when you first install xmail.
Ah, but I never promised to be easy to please ... :-) But really,
thanks for all your work!!! Now, onto a real reply (and some more fixes):
The problem is that an application should inherit preference
specifications whenever possible. These include color, font, button
styles, border widths, etc. It's extremely annoying to set up a series
of preferences and than have an application totally override them all
forcing you to include special resource overrides for each such
application.
For instance, I might have the following definitions in my resources to
control how I want to see applications, etc:
*Font : 8x13
*Command.Font : 9x15
*Command.Foreground : blue
*Command.Background : red
...
Note that this doesn't actually work entirely because things aren't this
consistent in X (sigh) ... But they should be!!! In any case, R5 is
supposed to fix all of this ... :-)
Now as for the final fixes. Both of these concern font selections in
xmail.
1. You have several specific font choices hard wired in which should
really be defaulted to whatever the user's defaults are. I chose
to use XtDefaultFont only to discover that it actually looks for
a resource named "XtDefaultFont"!!!! I expected that it would go
for whatever was bound to "*Font", but in retrospect I see that
that was silly of me.
2. You have your "helpFont" resource declared as an instance of a
[generally] nonexistent class "HelpFont". That resource should
probably be declared as an instance of the more generally available
class "Font". Note that this prevents the problem pointed out
with number 1 above. Now "*Font" binds to the font resources.
3. The use of the top level resources "helpFont" and "buttonFont",
while possibly convenient, prevent the use of "*Command.Font",
for instance, because "buttonFont" binds more specifically to the
general declaration "*Font". Perhaps this, and number 1 above,
points out the need for more ``official'' resources like
ButtonFont, HelpFont, CursorColor, etc. (Note that I supply
no ``fix'' for this ...)
Probably not making any sense ...
Casey
-----
*** xmail.c-dist Wed Jun 19 10:25:32 1991
--- xmail.c Thu Jun 20 16:35:14 1991
***************
*** 60,70 ****
static XtResource resrcs[] = {
{ XtNfont, XtCFont, XtRFontStruct, sizeof (XFontStruct *),
! Offset(textFont), XtRString, "9x15"},
! {"helpFont", "HelpFont", XtRFontStruct, sizeof (XFontStruct *),
! Offset(helpFont), XtRString, "8x13bold"},
! {"buttonFont", "ButtonFont", XtRFontStruct, sizeof (XFontStruct *),
! Offset(buttonFont), XtRString, "9x15"},
{"iconGeometry", "IconGeometry", XtRString, sizeof(char *),
Offset(iconGeometry), XtRString, (caddr_t) NULL},
{"mFileName", "MFileName", XtRString, sizeof(char *),
--- 60,70 ----
static XtResource resrcs[] = {
{ XtNfont, XtCFont, XtRFontStruct, sizeof (XFontStruct *),
! Offset(textFont), XtRString, XtDefaultFont},
! {"helpFont", XtCFont, XtRFontStruct, sizeof (XFontStruct *),
! Offset(helpFont), XtRString, XtDefaultFont},
! {"buttonFont", XtCFont, XtRFontStruct, sizeof (XFontStruct *),
! Offset(buttonFont), XtRString, XtDefaultFont},
{"iconGeometry", "IconGeometry", XtRString, sizeof(char *),
Offset(iconGeometry), XtRString, (caddr_t) NULL},
{"mFileName", "MFileName", XtRString, sizeof(char *),
*** Mailwatch.c-dist Wed Jun 19 10:25:40 1991
--- Mailwatch.c Thu Jun 20 16:34:37 1991
***************
*** 149,155 ****
{"useHost", XtCBoolean, XtRBoolean, sizeof(Boolean),
offset(useHost), XtRString, "FALSE" },
{ XtNfont, XtCFont, XtRFontStruct, sizeof (XFontStruct *),
! offset(font), XtRString, "fixed"},
};
#undef offset
--- 149,155 ----
{"useHost", XtCBoolean, XtRBoolean, sizeof(Boolean),
offset(useHost), XtRString, "FALSE" },
{ XtNfont, XtCFont, XtRFontStruct, sizeof (XFontStruct *),
! offset(font), XtRString, XtDefaultFont},
};
#undef offset
Technical Details
Message-ID:
<9106210453.AA23493@gauss.llnl.gov>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!bloom-beacon!dont-send-mail-to-path-linesShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!bloom-beacon!dont-send-mail-to-path-lines From: casey@gauss.llnl.GOV (Casey Leedom) Newsgroups: comp.windows.x Subject: Re: X.V11R4 resource inheritance hassles Message-ID: <9106210453.AA23493@gauss.llnl.gov> Date: 21 Jun 91 04:53:02 GMT Sender: casey@gauss.llnl.gov Organization: The Internet Lines: 142