warsaw@cme.nist.gov (Barry A. Warsaw) (06/28/90)
I have some questions about using resources to specify the "personality" of my Athena based applications. If the answer to my questions is "Here's the way to do what you want..." then that's great. If the answer is, as I suspect, "Nope, you can't do what you want", then consider this a Wish For R5. I want to be able to use resources to control the personality of the applications running in my environment. The kinds of things I want to do are: 1) Make all command buttons be oval shaped, with Black on Wheat colors, using the helvetica.b.12 (*) font. 2) Make all SimpleMenu objects use the newcent.14 (**) font, with Black on LightYellow colors. (*) alias for -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 (**) alias for -adobe-new century schoolbook-bold-r-normal--14-140-75-75-p-87-iso8859-1 I want things like this so that all clients I run will have a consistent look to them. Now, I can, for the most part, accomplish this easily and consicely by setting up my resources like so: *Command.ShapeStyle: Oval *Command.Foreground: Black *Command.Background: Wheat *Command.Font: helvetica.b.12 *SimpleMenu.Foreground: Black *SimpleMenu.Background: LightYellow *SimpleMenu.Font: newcent.14 These simple settings will give me the look I describe in my examples 1 & 2 above for the vast majority of Xt applications. The rub comes when an application, in its app-defaults file, sets one of these resources. The typical application will provide the application class name as the first componant in the resources in the app-defaults file, and such a setting will take precedence over my more general settings. An example of this is xpostit. The relevent settings in the Xpostit app-defaults file are: ! ! Fonts ! Xpostit*Command*font: -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-* Xpostit*Menu*font: -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-* Xpostit*Text*font: -b&h-lucidatypewriter-medium-r-normal-*-*-120-*-*-*-*-*-* You see here that the Xpostit*Command*font setting will override my *Command.Font setting, even though what I really want is my more general *Command.Font resource value. Though I can set all command button's fonts for most of the general cases, I am forced to deal with xpostit as a special case. The only way to get xpostit to conform to my personal "Look" policy is to have this setting in my Xdefaults file: Xpostit*Command.Font: helvetica.b.12 For this limited example it may not seem like much, but it can get to be a big hassle with a large number of resources and/or applications, especially considering that I'm forced to check out each application's app-defaults file for those resource settings which might override my general ones. Further, there is no way that I can nullify a setting in an application's app-defaults file without editing the root-owned file, or tell Xt not to load the app-defaults file in the system location. One thing that I *can* do is copy the system app-defaults file into a directory I own pointed to by XAPPLRESDIR, and comment out the font setting mentioned above, but this does not perclude the loading of the system app-defaults file; my local copy gets loaded *after* the system file (ORA, vol. 4, pp 245) so the higher precedence resource in the system file will override any more general setting in my local copy with lower precedence, in which case I must still deal with that particular setting for that particular application on a special basis. As I see it there are a few possible answers: 1) What I want to do is really not relevent, or arises from my incomplete understanding of the use of resources, or is not something that should be wanted by serious X heads (X:-). 2) Xt already provides a simple way to do what I want, but I just haven't found it yet. 3) Applications writers are not specifying the resources in their app-defaults files "correctly". 4) There currently is no provision to accomplish what I want. I wouldn't be at all suprised to find that case #1 or #2 is true, and if so, please post a reasonable explanation of why what I describe is really a non-problem. I (and perhaps others) would certainly appreciate the clarification. In the case of #3, is it possible that application writers should not specify the application class in the app-defaults file, but instead should wildcard the first componant? In the case of #4, then consider this a RFE for R5. I'd like to see an extension to the resource manager where the user can specify a "universal highest precedence wildcard match" sequence, so that I could put this sequence in my resource setting and it would act like a wildcard, but with higher precedence than the fully specified componant. I propose ".*", but the exact sequence doesn't matter really. This would modify my general resource settings described at the beginning of this article to look like this: .*Command.ShapeStyle: Oval .*Command.Foreground: Black .*Command.Background: Wheat .*Command.Font: helvetica.b.12 .*SimpleMenu.Foreground: Black .*SimpleMenu.Background: LightYellow .*SimpleMenu.Font: newcent.14 Now the .* in .*Command.ShapeStyle would match any number of componants but would match with a higher precedence and so my general setting would win. Anyway, does this sound like a reasonable wish, even if the real solution differs from what I suggest? A second Wish for R5 would be to extend the resource manager to understand escape sequences for special characters. -Barry NAME: Barry A. Warsaw USMAIL: National Institute of Standards TELE: (301) 975-3460 and Technology (formerly NBS) UUCP: uunet!cme.nist.gov!warsaw Rm. B-124, Bldg. 220 INET: warsaw@cme.nist.gov Gaithersburg, MD 20899
morreale@bierstadt.scd.ucar.edu (Peter Morreale) (06/29/90)
In article <WARSAW.90Jun28104603@rtg.cme.nist.gov>, warsaw@cme.nist.gov (Barry A. Warsaw) writes: |> |> I have some questions about using resources to specify the |> "personality" of my Athena based applications. If the answer to my [stuff deleted] |> xpostit as a special case. The only way to get xpostit to conform to |> my personal "Look" policy is to have this setting in my Xdefaults |> file: |> |> Xpostit*Command.Font: helvetica.b.12 |> |> For this limited example it may not seem like much, but it can get to |> be a big hassle with a large number of resources and/or applications, |> especially considering that I'm forced to check out each application's |> app-defaults file for those resource settings which might override my |> general ones. |> [stuff deleted] I alsos see this as a *huge* problem. And based on my understanding of setting resources (admittedly not complete) there isn't a *simple* way to overcome this either. Most of the users I consult with are more interested in getting their science done instead of learning a new "programming language" simply to obtain a more pleasant environment. There is a huge learning curve involved with X. The current resource setting scheme only adds to the learning curve. The end result is too often the user simply "putting up" with their current environment. My own .Xresources file contains 868 lines of "code". (And I have literally given up on several applications that I use *hourly*) The suggestion I offered (directly) to MIT was the construction of an interface to set resources for a particular client. I don't know if this is even feasible, but sumpthin which could "read" an X client and offer a graceful interface to the user for setting that client's resources. Perhaps it is time for an extension to resource handling. I suspect whatever is drawn up would impose limitations, but the "old" programmatic methodology could also exist... It seems like a logical progression to me. There seems to be a wide collection of useful clients (both MIT and contrib). It now seems like a prime time to provide a mechanism which allows *easy*, though perhaps limited, customization. Any thoughts X gurus? -PWM ------------------------------------------------------------------ Peter W. Morreale email: morreale@ncar.ucar.edu Nat'l Center for Atmos Research voice: (303) 497-1293 Scientific Computing Division Consulting Office ------------------------------------------------------------------
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (06/29/90)
3) Applications writers are not specifying the resources in their
app-defaults files "correctly".
This is probably also true, but.
4) There currently is no provision to accomplish what I want.
This is basically the real answer.
In the case of #4, then consider this a RFE for R5.
We've been considering solutions to this and several other important
resource manager problems, and we already have tentative solutions.rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (06/29/90)
the construction of an interface to set resources for a particular client Chris Peterson here at MIT has a working implementation of a general, dynamic resource editor, using an inter-client protocol. Protocol support is currently built into the Athena Widget Set, permitting any application using Xaw to have their resources edited dynamically. There is nothing widget-set specific about the protocol, nor even necessarily Xt specific. You get a graphical display of the widget hierarchy, with instance/class/widget identification available, you can obtain the set of resources supported for each widget, there's a nice dialog box with a graphical interface to selecting widgets and resources to update, you can log updates to a file, and probably other things I can't remember offhand. Yes, we would expect something like this to be in R5. No, you can't have it now. (Yes, Consortium members will probably get it pretty soon. :-)
asente@wrl.dec.com (Paul Asente) (06/29/90)
In article <WARSAW.90Jun28104603@rtg.cme.nist.gov> warsaw@cme.nist.gov (Barry A. Warsaw) writes: >The rub comes >when an application, in its app-defaults file, sets one of these >resources. The typical application will provide the application class >name as the first componant in the resources in the app-defaults file, >and such a setting will take precedence over my more general settings. Well, this problem is very complicated, but part of the answer is that the application writer isn't making things easy for you. There's never any reason for an app-defaults file to specify resources with an application class or name as the first component; the app-defaults file will only be used for this one application, so what's the point? And doing so makes things harder for you, the customizing user. -paul asente asente@decwrl.dec.com ...!decwrl!asente
stripes@eng.umd.edu (Joshua Osborne) (06/29/90)
In article <WARSAW.90Jun28104603@rtg.cme.nist.gov> warsaw@cme.nist.gov (Barry A. Warsaw) writes: [...] >In the case of #4, then consider this a RFE for R5. I'd like to see an >extension to the resource manager where the user can specify a >"universal highest precedence wildcard match" sequence, so that I >could put this sequence in my resource setting and it would act like a >wildcard, but with higher precedence than the fully specified >componant. I propose ".*", but the exact sequence doesn't matter >really. This would modify my general resource settings described at >the beginning of this article to look like this: > > .*Command.ShapeStyle: Oval > .*Command.Foreground: Black > .*Command.Background: Wheat > .*Command.Font: helvetica.b.12 > .*SimpleMenu.Foreground: Black > .*SimpleMenu.Background: LightYellow > .*SimpleMenu.Font: newcent.14 As long as the app-defaults can *still* override the user this is a good idea. If a system manager puts: .*Xlock.LogoutAfterTimeOut: jolt.eng.umd.edu,pepsi.eng.umd.edu,coke.eng.umd.edu .*Xlock.TimeOut: 15 It should be hard for the user to overide it (the program can unset enviroment vars before Xt can read them, so that's Ok. Nothing can stop users from getting source to publicaly avail software, so I'm ignoring that...). -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Mutitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "Don't try to change C into some nice, safe, portable programming language with all sharp edges removed, pick another language." - John Limpert
janssen@parc.xerox.com (Bill Janssen) (07/03/90)
In article <WARSAW.90Jun28104603@rtg.cme.nist.gov> warsaw@cme.nist.gov (Barry A. Warsaw) writes:
I want to be able to use resources to control the personality of the
applications running in my environment. The kinds of things I want to
do are:
1) Make all command buttons be oval shaped, with Black on Wheat
colors, using the helvetica.b.12 (*) font.
This brings up an interesting point. Quite often users want to
customize resources based not on the Widget used by the programmer in
implementing a feature, or on the name of the application, but by the
role that a particular widget-realized feature plays in their usage
pattern.
"Make all buttons that Save Files be octagonal"
"Make all quit operations ask for confirmation"
This can be done to some limited extent in Xt-based applications, by
using widgets appropriately sub-classed, crossed with an application
name. But the mechanism seems a bit strained, and the users are
forced to think about the implementation of the application, and are
at the mercy of the programmers who decide to use this or that widget.
--
Bill Janssen janssen.pa@xerox.com (415) 494-4763
Xerox Palo Alto Research Center
3333 Coyote Hill Road, Palo Alto, California 94304