smartin@Canada.lsil.com (Stephen Martin) (06/25/91)
Does anyone know if it is possible to register fallback resources with an appication using Olit 2.5. What i want to do is the the default values for a bunch of resources such as you can using the XtAppInitialize() routine or XtAppSetFallbackResource() but i don't know if OlInitialize() creates an Application Context and if so, how do get it? I know i can do basically the same thing using an app-default file but i would like it better if the information was compiled into the program where it can't be lost or modified. -- Stephen Martin ------- LSI Logic Corporation of Canada, Inc. Phone: (416) 620-7400 LSI|LOGIC| Suite 1110, 401 The West Mall, Fax: (416) 620-5005 | | Etobicoke, Ontario, Canada. Email: smartin@lsican.uucp ------- M9C 5J5 or smartin@Canada.lsil.com
unknown@Unify.Com (06/27/91)
> [is it] possible to register fallback resources with an > appication using Olit 2.5? ... I don't know if OlInitialize() > creates an Application Context and if so, how do get it? No, sorry, it is not possible to (usefully) register fallback resources. This is an example of a more generic problem that "we" intend to fix. (I speak for more than just USL when I say "we".) OlInitialize must go, XtAppInitialize (or its constituant parts) must prevail. One can get the application context handle as follows: top_leval = OlInitialize(...); ac = XtWidgetToApplicationContext(top_level); But after calling OlInitialize--which calls XtOpenDisplay--it is too late to (effectively) register any fallback resources. > I know i can do basically the same thing using an app-default > file but i would like it better if the information was > compiled into the program where it can't be lost ... Sorry, I don't understand the concern people have when they fear an app-defaults file may be "lost". I usually retort, as I'm doing here, that one is just about as likely to lose the a.out (application) itself as an app-defaults file. Certainly losing the application (or the app-defaults file) is a bummer, but what is the likelihood? I think this is a non-issue, in practice, but I can't argue with the fact that people do worry. > ... or modified. Yes, this is a problem--or a benefit. Consider that the app-defaults file is a nifty way to allow someone to localize (make language- and custom-specific) the client. Consider also that the app-defaults file is a great template for the user who wishes to create a private, customized version, via the $XAPPLRESDIR path. Yet you are right: A messed up app-defaults file typically causes the client to behave strangely, so modification of an app-defaults file should not be taken lightly. On the other hand, accidental modification of the file is, similar to losing the file, just about as likely as accidental modification of the a.out. Steve Humphrey UNIX System Laboratories
tom@elan.Elan.COM (Thomas Smith) (06/29/91)
About the virtues/limitations of application-default files... From article <2rasb54@openlook.Unify.Com>, by unknown@Unify.Com: > From someone who's identity was omitted from the last posting: >> I know i can do basically the same thing using an app-default >> file but i would like it better if the information was >> compiled into the program where it can't be lost ... > > Sorry, I don't understand the concern people have when they > fear an app-defaults file may be "lost". I usually retort, > as I'm doing here, that one is just about as likely to lose the > a.out (application) itself as an app-defaults file. Certainly > losing the application (or the app-defaults file) is a bummer, > but what is the likelihood? I think this is a non-issue, in > practice, but I can't argue with the fact that people do > worry. When a user desides "I want to copy this application to another place," he or she usually thinks "...and the application is the thing that runs when I type 'doit'." There is no obvious connection between the executable 'doit' and the app-defaults file "/usr/lib/X11/app-defaults/Doit", unless the the user in question happens to be an X programmer. Thus, the user types "rcp doit othermachine:~/doit" and the app-defaults file is "lost". Not only easy to do, but a non-developer is not going to figure out what the problem is without getting on the phone. Not only does it make your product lower-quality, but support people are too expensive to have them fielding calls on such a trivial problem. This could have been avoided with an adequately-designed interface architecture. Those of us developing commercial applications that are designed to be easy to maintain and support, as well as easy to use, require tighter control over the installation and configuration. The Xt premise of "make it user-configurable unless the programmer bends over backwards to limit it" just gives us headaches - removing even the option to "bend over backwards" costs us money, and forces us to turn elsewhere for interface solutions. Thomas Smith Elan Computer Group, Inc. (415) 964-2200 tom@elan.com, ...!{ames, uunet, hplabs}!elan!tom