klute@tommy.informatik.uni-dortmund.de (Rainer Klute) (03/19/91)
As every X toolkit programmer knows Xt offers a nice way to retrieve
application resources: XtVaGetApplicationResources. The "normal" way to use
this function is something like this:
XtToolkitInitialize ();
applicationContext = XtCreateApplicationContext ();
display = XtOpenDisplay (applicationContext, (char *) 0, "name",
"Class", options, XtNumber (options), &argc,
argv);
shellWidget = XtVaAppCreateShell ("name", "Class",
applicationShellWidgetClass, display,
NULL);
XtVaGetApplicationResources (shellWidget, &applicationOptions,
resources, XtNumber (resources), NULL);
However, this stuff will only work if you already have a connection to an X
server, because you have to pass a widget (hence a display connection) as
parameter to XtVaGetApplicationResources. Now, what can I do if I don't have
one? Before opening any display connection and creating any widgets my
application *first* wants to read its resources - using
XtVaGetApplicationResources - and only then open a display connection *upon the
values of the retrieved resources*.
Well, this can of course be done with the Xlib resource manager functions - but
Xt really should be able to do it. I don't see any reason why
XtVaGetApplicationResources would need the widget parameter except for
retrieving the application's name and class which could also be given as
Strings. So my conclusion is that this must be a design problem which should be
fixed in a future Xt version, perhaps like this:
XtToolkitInitialize ();
applicationContext = XtCreateApplicationContext ();
/* proposed new Xt function: */
XtVaInitApplicationResources (applicationContext, "name", "Class", options,
XtNumber (options), &argc, argv, NULL);
XtVaGetApplicationResources (applicationContext, &applicationOptions,
resources, XtNumber (resources), NULL);
Comments anyone?
--
Dipl.-Inform. Rainer Klute klute@irb.informatik.uni-dortmund.de
Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet
Postfach 500500 |)|/ Tel.: +49 231 755-4663
D-4600 Dortmund 50 |\|\ Fax : +49 231 755-2386asente@adobe.com (Paul Asente) (03/19/91)
In article <3108@laura.UUCP> klute@tommy.informatik.uni-dortmund.de (Rainer Klute) writes: >However, this stuff will only work if you already have a connection to an X >server, because you have to pass a widget (hence a display connection) as >parameter to XtVaGetApplicationResources. Now, what can I do if I don't have >one? Before opening any display connection and creating any widgets my >application *first* wants to read its resources - using >XtVaGetApplicationResources - and only then open a display connection *upon the >values of the retrieved resources*. In Xt, you can't fetch database resources before opening a display because there is no database to fetch the resources from until after you open a display. You could add a new routine that fetched resources from the display's database before creating any widgets on the display, but it wouldn't solve your problem. What database would you expect the resources to be fetched from without the context of the display? You're probably thinking the .Xdefaults file, but Xt normally gets the contents of the .Xdefaults file from the display, not from the file itself. -paul asente asente@adobe.com ...decwrl!adobe!asente Ratz put a bucket of liquid in front of me. "I wanted a glass of docs, Ratz. What the hell is this?" I barked. "Motif don't fit in a glass anymore," he barked back. I looked at the liquid. It was totally opaque to me.
pd@x.co.uk (Paul Davey) (03/19/91)
>>>>> On 18 Mar 91 16:45:46 GMT, klute@tommy.informatik.uni-dortmund.de (Rainer Klute) said:
-> As every X toolkit programmer knows Xt offers a nice way to retrieve
-> application resources: XtVaGetApplicationResources. The "normal" way to use
-> this function is something like this:
...
-> However, this stuff will only work if you already have a connection to an X
-> server, because you have to pass a widget (hence a display connection) as
-> parameter to XtVaGetApplicationResources. Now, what can I do if I don't have
-> one? Before opening any display connection and creating any widgets my
-> application *first* wants to read its resources - using
-> XtVaGetApplicationResources - and only then open a display connection *upon the
-> values of the retrieved resources*.
...
-> Comments anyone?
How can you check *all* your application resources when they may be
held in the RESOURCE_MANAGER property on the root window? You have to
open the display first. You`ve still got $DISPLAY and -display to
tailor the server connection with.
--
Regards, pd@x.co.uk IXI Limited
Paul Davey pd@ixi.uucp 62-74 Burleigh St.
...!uunet!ixi!pd Cambridge U.K.
"These are interesting times" +44 223 462 131 CB1 1OJ
USA: 1 800 XDESK 57klute@tommy.informatik.uni-dortmund.de (Rainer Klute) (03/20/91)
In article <12721@adobe.UUCP>, asente@adobe.com (Paul Asente) writes: |> In Xt, you can't fetch database resources before opening a display because |> there is no database to fetch the resources from until after you open a |> display. You could add a new routine that fetched resources from |> the display's database before creating any widgets on the display, but it |> wouldn't solve your problem. |> |> What database would you expect the resources to be fetched from without the |> context of the display? You're probably thinking the .Xdefaults file, |> but Xt |> normally gets the contents of the .Xdefaults file from the display, not |> from |> the file itself. Who says that a database has to have something to do with a display? Sure, the server's database is the one which is most frequently referenced. But first of all a database is a data structure on the client side. Entries can be made from various sources: from the command line, from files, from strings - where an example of such a string might be the server's RESOURCE_MANAGER property. I hope I have made clear that from a database's point of view there is no inherent relation between the database and an X server. Xt should not oblige such a relation, forcing the user to use the Xrm primitives. Ok? -- Dipl.-Inform. Rainer Klute klute@irb.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ Tel.: +49 231 755-4663 D-4600 Dortmund 50 |\|\ Fax : +49 231 755-2386
marbru@attc.UUCP (Martin Brunecky) (03/20/91)
In article <3114@laura.UUCP> klute@tommy.informatik.uni-dortmund.de (Rainer Klute) writes: > >I hope I have made clear that from a database's point of view there is no >inherent relation between the database and an X server. Xt should not >oblige such a relation, forcing the user to use the Xrm primitives. Ok? > Xrm is an independent (but very special) database. No doubt it can be used completely independently from Xt, and then there truly is no relation between the database and an X server. However. Xt decided to use the Xrm database for a very specific purpose: defining application resource with respect to several important "environment" features. Therefore, Xt defines a hierarchy of (Xrm file) sources for it's database. It automatically wants to take in account (in no particular order here): - application preferences - server (display) preferences and features (such as monochrome/color) - user preferences (either resource files or command line options) - localle/language Note that many of those features are display specific. For example, my application outputs to two displays, one monochrome 15'' and another one color 19''. Sure I want to use different resources for each display. Therefore, the Xt Xrm database is attached to the display, and it may contain display(server) dependent data. Of course, if your application wants to use Xrm database for some other purpose, go ahead and create your own one. But please, don't impose your needs (such as display independency) upon the X toolkit. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
jordan@tcs.COM (Jordan Hayes) (03/21/91)
This is a good point. I write applications all the time that have several top-level "objects" that could all use access to an AppDefaults file, but don't get one becuase the file only gets loaded when you open the display, and you can't merge them in because it would affect (adversly) any resource fetching done later on. My solution so far has been to open a new Display connection so I have a fresh database. That can get old really quick ... /jordan
chuck@Morgan.COM (Chuck Ocheret) (04/02/91)
> This is a good point. I write applications all the time that have > several top-level "objects" that could all use access to an AppDefaults > file, but don't get one becuase the file only gets loaded when you open > the display, and you can't merge them in because it would affect > (adversly) any resource fetching done later on. My solution so far has > been to open a new Display connection so I have a fresh database. That > can get old really quick ... And if you're using Motif, you can't open a new connection once you've closed one because their gc caching code is screwed up. ~chuck -- +--------------------+ Chuck Ocheret +---------------+ |chuck@fid.Morgan.COM| Morgan Stanley & Co., Inc. |(212) 703-4474 | | Duty now ... |19th Floor, 1251 Avenue of the Americas|for the future.| +--------------------+ New York, N.Y. 10020 USA +---------------+
nazgul@alphalpha.com (Kee Hinckley) (04/03/91)
In article <2950@s5.Morgan.COM> chuck@Morgan.COM (Chuck Ocheret) writes: >> This is a good point. I write applications all the time that have >> several top-level "objects" that could all use access to an AppDefaults >> file, but don't get one becuase the file only gets loaded when you open Do they really need separate files, or can't you just qualify the resources by the name of the toplevel window? -- Alfalfa Software, Inc. | Poste: The EMail for Unix nazgul@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@alfalfa.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.