steve@acorn.co.uk (Steve "Daffy" Hunt) (05/17/89)
In article <8905151402.AA06843@THANATOS.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph R. Swick) writes: >> Date: 14 May 89 13:23:24 GMT >> From: mcvax!ukc!acorn!steve@uunet.uu.net (Steve "Daffy" Hunt) >> >> The XClipboard client seems to rely on undocumented behaviour >> of the Form widget. > >No, it doesn't. But it _does_ rely on it's app-defaults >(XClipboard.ad) file being correctly installed in the >appropriate place(s). No code patches are needed/appropriate. So, that's where the missing information was... I have to question the wisdom of *relying* on a resource file which can so easily become separated from the program proper. Just one example of a situation when this policy can backfire is when Fred gives Sue a disk with a program on, which fails to work for Sue because Fred did not realise that this app-defaults file was needed. Surely the default "I-can't-find-my-.ad-file" behaviour should be something usable, or else just a message saying "can't find required resources". Quietly failing to be usable is asking for trouble. I shan't be removing my patch. Unless there is a convincing counter-argument, of course. Steve Hunt PS: is it really important? Hell, yes; think of the amount of hand-holding the support people could be saved :-)
erik@sravd.sra.JUNET (Erik M. van der Poel) (05/19/89)
In article <773@acorn.co.uk> steve@acorn.UUCP (Steve "Daffy" Hunt) writes: >In article <8905151402.AA06843@THANATOS.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph R. Swick) writes: >>... But it _does_ rely on it's app-defaults >>(XClipboard.ad) file being correctly installed in the >>appropriate place(s). >... >I have to question the wisdom of *relying* on a resource file which can >so easily become separated from the program proper. I agree. I propose adding a function to Xt that would allow specifying the app-defaults in a string in the program instead of in a separate file. This would have to be called before calling XtInitialize(). void XtAppDefaults(defaults) String defaults; If this function is called, Xt ignores the app-defaults file. Now I'll sit back and wait for one of the Xt people to say "Yes, we've already done this. It'll be in R4." :-)
erik@srava.sra.JUNET (Erik M. van der Poel) (05/22/89)
In article <1041@sragwa.sra.JUNET> erik%sra.junet@uunet.uu.net (Erik M. van der Poel) writes: >... I propose adding a function to Xt that would allow specifying the >app-defaults in a string in the program instead of in a separate file. >... > void XtAppDefaults(defaults) > String defaults; After writing the above, I decided to try to implement the new function. While re-reading the Xt sources and documentation, I realized that the above proposal would probably not be adequate since the application class name is not specified. I was also reminded of something I bumped into before while writing an application, namely, the fact that Xt allows you to have an app-defaults file for the shell created by XtInitialize(), but not for other shells created later by XtAppCreateShell(). Another thing I bumped into while reading the documentation, is that the word "application" seems to be used in several contexts (oops :-), i.e. to mean something different each time. For example, in the description for XtCreateApplicationContext() (emphasis mine): Every APPLICATION must have at least one application context. Here, the "application" probably refers to a program. Another example, in 2.1: The major component of an application context is a list of X Display pointers for that APPLICATION. Here, the "application" probably refers to an application context. And another, in the description for XtAppCreateShell(): Specifies the class name of this APPLICATION. Here, the "application" probably refers to the new shell. IMHO, more care should be taken with the terminology. Sorry about the flames, I'm just trying to provide constructive criticism. Well, all you Xt'ers out there, any comments? -- Erik M. van der Poel erik@sra.junet (Japan) SRA, 1-1-1 Hirakawa-cho, Chiyoda-ku erik%sra.junet@uunet.uu.net (USA) Tokyo 102 Japan. TEL +81-3-234-2692 erik%sra.junet@mcvax.uucp (Europe)
jlf@earth.cray.COM (John Freeman) (05/22/89)
> I have to question the wisdom of *relying* on a resource file which can > so easily become separated from the program proper. I have a big problem with this too. I have been told that the resources file is considered 'part of the the program'. I think that the program should provided reasonable behavior and defaults which can be overridden by the user, but not required by the user. I ran into this with a client whose buttons didn't do anything without a translation table was specified in the user's .Xdefaults.
rlh2@ukc.ac.uk (Richard Hesketh) (05/23/89)
There is a confusion in the documentation as to the purpose of application contexts. This I believe is being changed in R4 8-). App-defaults files are very useful and should be used by all non-trivial X Toolkit applications, if only in the development stage. I agree that a program is not well designed if it *demands* the user to have defaults set in his user defaults file(s). Any required resource values should be placed in an app-defaults file held in a common place .. /usr/lib/X11/app-defaults and in places explicitly specified by the user. The resource mechanism was designed to allow local customizations to be made to programs without having to recompile them. You must remember that by setting resource values in an application using XtSetArg() lists that you are removing the ability to change these resources in app-defaults files, user defaults files AND via the -xrm command line option. Do you really want that?? What about allowing simple things like changing colours or fonts? I don't see that the one-file-per-application argument holds. There are a lot of applications which rely on special files being in the right place and if the program comes with an installation script or at the very least a manual page I don't see a great problem. It is certainly not an argument for dropping the use of resource files. What you need .. is a method for allowing programmers to specify a defaults file within the application program .. possibly in a statically initialized structure. These would be operationally equivalent to the app-defaults file and would be merged into the resource database created whenever a new application shell is created. This would still allow the external app-defaults files to override these values but would also provide suitable defaults if the file was missing. Also any resource values set using the XtSetArg/Values method would still be hard-wired in so that resources the programmer doesn't want the user to ever change can be set. In this way those who feel that every application should be only one binary and no trailing files, and those who wish to make their applications customizable by users would be catered for. I personally don't think the change is necessary, unless I am missing something very important here? I am afraid I have to disagree with Erik van der Poel, you *can* have separate app-defaults files for each new XtAppCreateShell(), as well as the one specified in XtInitialize() and they do work. Richard Richard Hesketh : rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: (0227) 764000 ext. 3682
dheller@cory.Berkeley.EDU (Dan Heller) (05/24/89)
In article <8905221532.AA24930@thelake.cray.com> jlf@earth.cray.COM (John Freeman) writes: > > I have to question the wisdom of *relying* on a resource file which can > > so easily become separated from the program proper. On the same token, it would also be nice to run a program and give it an argument to -ignore- the app-defaults file. Dan Heller <island!argv@sun.com>
erik@sravd.sra.JUNET (Erik M. van der Poel) (05/24/89)
In article <1242@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes: >There is a confusion in the documentation as to the purpose of application >contexts. This I believe is being changed in R4 8-). In what way is it being changed? >I don't see that the one-file-per-application argument holds. ... It is >certainly not an argument for dropping the use of resource files. I don't want to drop resource files, I just want to add resource strings. (Just to avoid confusion, by "resource strings" I definitely am NOT referring to XtSet{Arg,Values} hard-wiring. The resource string is simply an alternative if the resource file is not present.) >What you need .. is a method for allowing programmers to specify a >defaults file within the application program .. possibly in a statically >initialized structure. ... This is identical to what I proposed. I'm very sorry if I didn't make that clear. >In this way those who feel that every application should be only one binary >and no trailing files, and those who wish to make their applications >customizable by users would be catered for. I personally don't think the >change is necessary, unless I am missing something very important here? I personally think the change is necessary and important. As it says in the documentation, "To the extent possible, the X Toolkit is policy free." So Xt should provide the *mechanism* to make it *possible* for the programmer to implement an app-defaults *policy* to his/her own liking. (Xt implementors, are you catching this?) >I am afraid I have to disagree with Erik van der Poel, you *can* have >separate app-defaults files for each new XtAppCreateShell(), as well as >the one specified in XtInitialize() and they do work. Oh, how embarassing! :-( But they don't seem to work for me, using the R3 Xt with fixes 1 to 10. Are you using a souped-up almost-R4 version of Xt? Thank you, Richard Hesketh, for following up. The days of dead silence after my posting made me think I had touched on a subject that was either taboo or irrelevant. :-)
chaim@cbnewsj.ATT.COM (chaim.m.ackerman) (05/24/89)
It's an apparantly unpopular stand, but in defense of app-defaults... app-defaults files are good for "isolating" server dependent code. Ideally, the executable should just contain the "logic" If the application is very simple or portable across all servers or your application users are X literate, then you probably don't need the app-defaults. To go further out on a limb: app-defaults separate "programming illustrations" from "program products". Chaim Ackerman
grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (05/25/89)
app-defaults aren't server-specific, they're host-specific. e.g., if I fire up texx2 from a Sun-3 with a -display on an Apple, texx2 reads the app-defaults from the sun, giving me a window that's too big. Of course, I can over-ride all that in my .xresources file. -- Dirk Grunwald Univ. of Illinois grunwald@flute.cs.uiuc.edu
geb@amber.Rational.COM (Gary E. Barnes) (05/25/89)
What you want to do with resource defaults is very reasonable. I have
the same bone to pick with the X toolkits. I don't believe in
"normal" applications that fail to function just because some
parameter file is not in place. It is very nice (even vital) to be
able to change virtually any behavior of a program but the author of a
program should have the option of creating a totally self contained
application.
Something like Emacs may be somewhat silly without several (hundreds?)
of separate files but many other utilites (like xclock) would be silly
if they required app-defaults files in order to function properly.
If nothing else an application should be able to fail "gracefully" if
a required file or a set of required parameterizations are not
present. The toolkit gives you no way of knowing whether your
app-defaults file existed (and was readable/useable/complete).
Below is a very-stripped-down piece of code that I use when I have some
resources that I want to set up within the program. My default values
are used "first" but any and all of them can be overridden by an
appropriately named app-defaults file, a .Xdefaults file entry, or the
command line; just like in any other X application.
There are two ways to accomplish what you want with the current
toolkit intrinsics.
The first scenario is this:
1) do XtInitialize - this reads in all of the normal resource sources
2) do XtGetApplicationResources - this gets you either a) your internal-to-the-
program default values or else the system/user/cmd-line-supplied values
3) destroy the top level widget that XtInitialize gave you; it isn't usable
because it was not created with your default values in mind
4) use XtSetArg with the resources we got in step 2 to create an ArgList and
then do an XtCreateApplicationShell(toplevelShellWidgetClass) to get a
shell with the same name and class as we got from XtInitialize but which has
your/the-system's/the-user's/the-cmd-line's resource values in it
An alternative scenario that works just as well is:
1) do toplevel = XtInitialize - this reads the normal resources and gets you
a toplevel widget
2) do XrmPutLineResource call(s) to create a database called my_db which then
contains only your internal-to-the-program default resource values
3) reach into XtDisplay(toplevel)->db to get the database created by the
toolkit and do XrmMergeDatabase(XtDisplay(toplevel)->db,my_db) to
merge the toolkit's database into your database (thus overriding your
internal defaults with the system/user/command-line values) and then
put your merged database into XtDisplay(toplevel)->db = my_db.
This step is of course "bad form" because it uses "knowledge" about the
Display structure; ie. the code "knows" that there is a db field that
contains the database.
4) destroy the toplevel widget you got from XtInitialize
5) use XtCreateApplicationShell(topLevelShellWidgetClass) to get the "real"
top level shell for your application.
Here is the very-stripped-down sample code for the first scenario:
-------------------------------------------------------------------------
typedef struct _Dragon_Resources_Rec{
Boolean Input; /* A random resource */
} Dragon_Resources_Rec, *Dragon_Resources_Ptr;
static XtResource dragon_resources[] = {
{XtNinput, XtCInput, XtRBoolean, sizeof(Boolean),
XtOffset(Dragon_Resources_Ptr, Input), XtRBoolean,
(caddr_t)"off"}
};
static XrmOptionDescRec command_line_options[] = {
{"-input", ".input", XrmoptionNoArg, (caddr_t)"on" },
};
int main (argc, argv)
int argc;
String *argv;
{
Arg args[40];
int argi = 0;
#define SETARG(name,value) \
XtSetArg( args[argi], name, (XtArgVal)value ); ++argi;
/*--Start up the toolkit. This creates a shell widget. Unfortunately the
* only way the toolkit allows you to specify default application resources
* is by having a /usr/lib/X11/app-defaults/Application resouce file. I'm
* not interested in doing this. If some site wants to create one in order
* to customize the program then that is fine. However, I want my program
* to be "standalone"; ie. if you have the binary executable then you have
* all you *must-have*. So, I will Destroy this widget shortly. */
Program_Name = argv[0];
Dragon =
XtInitialize ( "dragon", "Dragon",
command_line_options, XtNumber(command_line_options),
&argc, argv );
/*--Now get the application resources. */
XtGetApplicationResources( Dragon, (caddr_t)&Dragon_Resources,
dragon_resources, XtNumber(dragon_resources),
(ArgList)NULL, (Cardinal)0 );
/*--Now we set up our "real" application shell. */
XtDestroyWidget( Dragon );
/*--Set up various other controls on our top level widget that we require.
* Especially note that we are using *topLevelShellWidgetClass*. This is
* the only shell class that will use our main "Dragon" class name when
* looking up resources in the database! */
SETARG( XtNinput, Dragon_Resources.Input );
Dragon = XtCreateApplicationShell( "dragon",
topLevelShellWidgetClass,
args, (Cardinal)argi );
/*--Other stuff and eventually we do... */
XtMainLoop();
} /* main */steve@acorn.co.uk (Steve "Daffy" Hunt) (05/25/89)
In article <1045@sragwa.sra.JUNET> erik%sra.junet@uunet.uu.net (Erik M. van der Poel) writes: >In article <1242@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes: >>I don't see that the one-file-per-application argument holds. ... It is >>certainly not an argument for dropping the use of resource files. > >I don't want to drop resource files, I just want to add resource strings. (Just >to avoid confusion, by "resource strings" I definitely am NOT referring to >XtSet{Arg,Values} hard-wiring. The resource string is simply an alternative if >the resource file is not present.) A good suggestion. This would allow the customisability offered by avoiding XtSetArgs without a proliferation of app-defaults files. I would use the resource string for values that you NEED (like form constraints) and the app-defaults file for the frippery. To Richard Hesketh: the one-file-per-program argument might not be valid in a world of gargantuan applications, but is that where we are heading? In a tool-based world, one file per program *is* a good idea. Imagine the potential chaos if sed, grep, awk, head, etc all demanded configuration files, and failed in subtle and silent ways when those files were absent. Steve Hunt
dayoung@hplabsz.HPL.HP.COM (Doug A. Young) (05/26/89)
In article <1041@sragwa.sra.JUNET> erik%sra.junet@uunet.uu.net (Erik M. van der Poel) writes: >I agree. I propose adding a function to Xt that would allow specifying the >app-defaults in a string in the program instead of in a separate file. This >would have to be called before calling XtInitialize(). This is an interesting co-incidence. I had the same idea, which I implemented a few days ago. I called my function XtRegisterApplicationDefaults(). The enclosed shar file contains a patch file for the R3 Intrinsics and a simple dummy example, to show how it can be used. It has been very useful so far, and I would certainly like to see this or something like it in the standard. Doug Young # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by Doug Young <dayoung@hplday> on Fri May 26 08:45:19 1989 # # This archive contains: # patches draw.c # LANG=""; export LANG PATH=/bin:/usr/bin:$PATH; export PATH echo x - patches cat >patches <<'@EOF' *** Initialize.orig Thu May 25 22:37:18 1989 --- Initialize.c Thu May 25 22:37:26 1989 *************** *** 122,127 *buf = '\0'; return buf; } static XrmDatabase GetAppSystemDefaults(classname) char *classname; --- 122,137 ----- *buf = '\0'; return buf; } + #define PROG_APP_DEFS + #ifdef PROG_APP_DEFS + /* + * This is a hack to allow the programmer to specify *default* resources. Because + * the resources are loaded into the resource database first, the user's resource files + * override them. This essentially give the programmer the option of compiling the app-defaults + * file into the application. + */ + static char **app_def; + static int n_app_defaults; XtRegisterApplicationDefaults(defs, n_defs) char *defs[]; *************** *** 123,128 return buf; } static XrmDatabase GetAppSystemDefaults(classname) char *classname; { --- 133,158 ----- static char **app_def; static int n_app_defaults; + XtRegisterApplicationDefaults(defs, n_defs) + char *defs[]; + int n_defs; + { + app_def = defs; + n_app_defaults = n_defs; + } + + static XrmDatabase GetProgramDefaults(def_res, n_res) + char *def_res[]; + int n_res; + { + int i; + XrmDatabase rdb = NULL; + for(i=0;i<n_res;i++) + XrmPutLineResource(&rdb, def_res[i]); + return rdb; + } + #endif + static XrmDatabase GetAppSystemDefaults(classname) char *classname; { *************** *** 207,212 dpy->db = NULL; rdb = GetAppSystemDefaults(classname); if (rdb != NULL) XrmMergeDatabases(rdb, &(dpy->db)); --- 237,246 ----- dpy->db = NULL; + #ifdef PROG_APP_DEFS + rdb = GetProgramDefaults(app_def, n_app_defaults); + if (rdb != NULL) XrmMergeDatabases(rdb, &(dpy->db)); + #endif rdb = GetAppSystemDefaults(classname); if (rdb != NULL) XrmMergeDatabases(rdb, &(dpy->db)); @EOF chmod 666 patches echo x - draw.c cat >draw.c <<'@EOF' /* * Example using the program-compiled resource mechanism * provided by the function: * XtRegisterApplicationDefaults(); * To use, just create an array of strings, just like any X resource file, * Then call XtRegisterApplicationDefaults(resources, n_resources) * The specified resources will be entered into the resource data base * before any other resources, allowing the programmer to specify * reasonable defaults for applications without disallowing users * to override the chioces. */ #include <X11/StringDefs.h> #include <X11/Intrinsic.h> #include <Xw/Xw.h> #include <Xw/WorkSpace.h> #include <Xw/Form.h> #include <Xw/RCManager.h> #include <Xw/PButton.h> static char * app_defaults[] = { "Draw*mode: one_of_many", "Draw*commands*PushButton*translations: <Btn1Down>: select() ", "Draw*options*PushButton*translations: <Btn1Down>: select() ", "Draw*commands.layoutType: maximum_columns", "Draw*commands*singleRow: True", "Draw*yResizable: True", "Draw*xResizable: True", "Draw*canvas.xRefName: options", "Draw*canvas.xAddWidth: True", "Draw*canvas.xAttachRight: True", "Draw*canvas.xAttachLeft: True", "Draw*canvas.yAttachBottom: True", "Draw*canvas.yAttachTop: True", "Draw*canvas.yRefName: commands", "Draw*canvas.yAddHeight: True", "Draw*commands.xRefName: options", "Draw*commands*xAddWidth: True", "Draw*commands.xAttachRight: True", "Draw*options.yAttachBottom: True", "*button1.label: dash", "*button2.label: dot-dash", "*options*button3.label: solid", "*commands*button1*label: Line", "*commands*button2*label: Circle", "*commands*button3*label: Square", }; main(argc, argv) int argc; char **argv; { Widget toplevel, canvas, panel, commands, options; XtRegisterApplicationDefaults(app_defaults, XtNumber(app_defaults)); toplevel = XtInitialize(argv[0], "Draw", NULL, 0, &argc, argv); panel = XtCreateManagedWidget("panel", XwformWidgetClass, toplevel, NULL, 0); options = XtCreateManagedWidget("options", XwrowColWidgetClass, panel, NULL, 0); commands = XtCreateManagedWidget("commands", XwrowColWidgetClass, panel, NULL, 0); canvas = XtCreateManagedWidget("canvas", XwworkSpaceWidgetClass, panel, NULL, 0); XtCreateManagedWidget("button1", XwpushButtonWidgetClass, commands, NULL, 0); XtCreateManagedWidget("button2", XwpushButtonWidgetClass, commands, NULL, 0); XtCreateManagedWidget("button3", XwpushButtonWidgetClass, commands, NULL, 0); XtCreateManagedWidget("button1", XwpushButtonWidgetClass, options, NULL, 0); XtCreateManagedWidget("button2", XwpushButtonWidgetClass, options, NULL, 0); XtCreateManagedWidget("button3", XwpushButtonWidgetClass, options, NULL, 0); XtRealizeWidget(toplevel); XtMainLoop(); } @EOF chmod 666 draw.c exit 0
rws@EXPO.LCS.MIT.EDU (05/26/89)
Independent of whether or not this is an important issue, it's very unlikely (given present commitments) that this issue will be addressed in the next version of the Intrinsics. Here's one thing it seems like you can do. Put a magic resource in your app-defaults file. Have your application check to see if it exists in the resource database (right after calling XtDisplayInitialize). If it doesn't, get the database (with XtDatabase) and merge in whatever resources you care to (using Xlib routines). This won't give you exactly the same semantics, but it should allow you to cope with a missing app-defaults file. One bug with this approach is that, in R3, XtDatabase apparently can return NULL if no resources at all were found. Fixed in next release.
rlh2@ukc.ac.uk (Richard Hesketh) (05/27/89)
In article <3401@hplabsz.HPL.HP.COM> dayoung@hplabsz.UUCP (Doug A. Young) writes: [ describes and includes the following function ] >XtRegisterApplicationDefaults(). The enclosed shar file contains a patch >file for the R3 Intrinsics and a simple dummy example, [ deleted ]. >Doug Young As Bob said this probably won't be included in R4 so having patches to the source ain't a good thing ... however because the idea is so simple (WDITOT 8-) it can be made into a small utility routine that could be part of Xmu or in the source of your own program: <---<---<--- #include <X11/Intrinsic.h> XmuRegisterApplicationDefaults(dpy, defs, n_defs) Display *dpy; char *defs[]; int n_defs; { XrmDatabase rdb = NULL; int i; for (i = 0; i < n_defs; i++) XrmPutLineResource(&rdb, defs[i]); if (rdb != NULL) { XrmMergeDatabases(dpy->db, &rdb); dpy->db = rdb; /* original dpy->db has been destroyed */ } } --->--->---> Note this takes the display of a widget to find the database .. so it must be used either AFTER XtInitialize has been called or .. as really should the case .. AFTER an XtOpenDisplay call. In fact it can be called anytime using ... XmuRegisterApplicationDefaults(XtDisplay(w), defs, XtNumber(defs)) etc. Richard Richard Hesketh : rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: (0227) 764000 ext. 3682
dayoung@hplabsz.HPL.HP.COM (Doug A. Young) (05/30/89)
In article <1305@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes: > >As Bob said this probably won't be included in R4 so having patches to >the source ain't a good thing ... however because the idea is so simple >(WDITOT 8-) it can be made into a small utility routine that could >be part of Xmu or in the source of your own program: The standalone library is a good idea of course. In fact this is how I've been using this myself. I have a libXtrm.a that I link in to my programs before libXt. Unfortunately, (as you pointed out) because your standalone function requires a display, it doesn't work quite as intended unless the library redefines some of the Intrinsics intialization functions. By the time you have opened the display, Xt has already loaded the user's resource files. Now you are in the position of overriding the users choices, not specifying defaults, which is exactly what I was trying to avoid with my version. I tried to see how this could be implemented to provide the needed functionality, without depending on patches to the Intrinsics, but couldn't find a way. If you like this capability, I think the best approach is to lobby for its inclusion at some point (R5?). Doug Young
rlh2@ukc.ac.uk (Richard Hesketh) (05/31/89)
In article <3408@hplabsz.HPL.HP.COM> dayoung@hplabsz.UUCP (Doug A. Young) writes: >[talking about a "RegisterAppDefaults" function - deleted]. >Unfortunately, (as you pointed out) because >your standalone function requires a display, it doesn't work quite >as intended unless the library redefines some of the Intrinsics intialization >functions. By the time you have opened the display, >Xt has already loaded the user's resource files. Now you are in the >position of overriding the users choices, not specifying defaults, which >is exactly what I was trying to avoid with my version. [ deleted ] Umm, well it *does* really work as required. The function actually creates a new database using the registered defaults *then* merges in the database, created by the Intrinsics when the display is opened. Therefore the application registered resources *are* defaults because they are overridden by any resources set in app-defaults files or via xrdb or the -xrm command line option. There is no real problem here (I was just covering myself 8-) its just that you must have opened a Display before you create any widgets ... which is not possible with XtInitialize() because it creates a shell immediately after it has opened the Display. Whereas XtOpenDisplay() can be used then XmuRegister..() then XtCreate..() to give you the correct functionality. Maybe I didn't make this clear enough. (The code wasn't obvious 8-() >Doug Young Richard Richard Hesketh : rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: (0227) 764000 ext. 3682
dayoung@hplabsz.HPL.HP.COM (Doug A. Young) (06/01/89)
In article <1305@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes: >In article <3401@hplabsz.HPL.HP.COM> dayoung@hplabsz.UUCP (Doug A. Young) writes: > [ describes and includes the following function ] >>XtRegisterApplicationDefaults(). The enclosed shar file contains a patch >>file for the R3 Intrinsics and a simple dummy example, [ deleted ]. > >the source ain't a good thing ... however because the idea is so simple >(WDITOT 8-) it can be made into a small utility routine that could >be part of Xmu or in the source of your own program: oops, I didn't look at Richard's function close enough to see which way he was merging the databases. Contrary to my prevous objection this function DOES work, and is equivalent to the patches I posted. Since it does so without without modifying the Intrinsics, this is obviously the way to go. That's what I get for reading news first thing in the morning before the caffeine has kicked in... Doug Young
dayoung@hplabsz.HPL.HP.COM (Doug A. Young) (06/02/89)
In article <1333@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes: >In article <3408@hplabsz.HPL.HP.COM> dayoung@hplabsz.UUCP (Doug A. Young) writes: > >Umm, well it *does* really work as required. The function actually creates Yes, it does. I posted a retraction of my objections, but it just bounced back to me today. I'll try again. This is a nice solution, and I've been using it ever since I took a second look at it. Sorry for missing the point before I responded. Doug