casey@gauss.llnl.GOV (Casey Leedom) (06/21/91)
[[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
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (06/21/91)
> From: casey@gauss.llnl.gov (Casey Leedom) > [...color specs in app-defaults file...] > [P]eople 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. How does this differ from an application that uses black-and-white by default? In each case it needs customization...what am I missing? > This comment also applies to font definitions. > From: michael@berlioz.nsc.com (Michael Wagnitz) > What fonts would you have me default to (none?!?) if I don't specify > something in the app-file? Fixed!?! (Yuch. %^) How about the server default font? If a user really cares so little about fonts as to have no specification anywhere else, using the server default seems eminently reasonable to me. > I made the change [...]. 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, I have little pity for users who don't read documentation before calling for help. As for not installing the app-defaults file, that depends. If the documentation says such installation is necessary, the again I have little pity for the person. If not, the documentation is what's at fault, not the user. [back to quoting Casey, I think -dM] > 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. To my mind, an application should always look for resources first in the screen's resource database, and fall back on its internal defaults (the app-defaults file, the compiled-in defaults, whatever) only if it can't find what it wants in the resource database. Anything else is a bug, that simple. No? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rthomson@mesa.dsd.es.com (Rich Thomson) (06/25/91)
In article <9106210733.AA06821@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: > >To my mind, an application should always look for resources first in >the screen's resource database, and fall back on its internal defaults >(the app-defaults file, the compiled-in defaults, whatever) only if it >can't find what it wants in the resource database. Anything else is a >bug, that simple. No? Does one have this fine a level of control in an Xt based application? The widgets look up their resources via XrmGetResource, but you don't get to control which database the resource fetch is done on. [Please correct me if I'm wrong -- I'm not talking from the position of having examined the Xt code, it just seems the most logical thing to do] -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson Internet: rthomson@dsd.es.com PEXt Programmer