lanzo@wgate.wgate.com (Mark Lanzo) (05/31/91)
First, background info before I pose my question:
Hardware: HP9000/370
OS: HP-UX 7.0B
S/W: X11R3, Motif 1.0
The question:
What is the correct way to get all of the Motif resource type
converters registered when my application starts up?
I want to use XtGetApplicationResources() to fetch a bunch of
parameters. It turns out that none of the Motif type converters
are available (such as String to FontList).
Now, I found that there was an undocumented function
XmRegisterConverters() which does the trick, so I have code which
looks like:
RootWidget = XtInitialize(...);
XmRegisterConverters();
XtGetApplicationResources(...);
This works fine; however, I am uncomfortable using a function which
I would never know existed had I not looked for it in the source code
for the Motif toolkit.
So: is there a more "proper" way to do this?
Thanks,
Markklee@wsl.dec.com (Ken Lee) (06/03/91)
In article <188@atesysv.UUCP>, lanzo@wgate.wgate.com (Mark Lanzo) writes: |> What is the correct way to get all of the Motif resource type |> converters registered when my application starts up? Widget set resource converters are usually registered when the vendor shell widget class for that widget set is created. This is true of both the Athena and Motif widget sets. Normally, the first widget you would create is a vendor shell. Is there some reason you are not? -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
aw@BAE.BELLCORE.COM (Andrew Wason) (06/04/91)
pa.dec.com!wsl.dec.com!klee@decwrl.dec.com (Ken Lee) writes: > In article <188@atesysv.UUCP>, lanzo@wgate.wgate.com (Mark Lanzo) writes: > |> What is the correct way to get all of the Motif resource type > |> converters registered when my application starts up? > > Widget set resource converters are usually registered when the vendor > shell widget class for that widget set is created. This is true of > both the Athena and Motif widget sets. Normally, the first widget you > would create is a vendor shell. Is there some reason you are not? If there is some reason you are not, you could call XtInitializeWidgetClass on the VendorShell class (or any subclass of XmPrimitive or XmManager). These widgets call XmRegisterConverters in their class_initialize methods. One reason you might want to do this is so you can use the XtVaTypedArg stuff when you create your first toplevel widget. Andrew _______________________________________________________________________________ Andrew Wason Bell Communications Research aw@bae.bellcore.com Piscataway, NJ bellcore!bae!aw
mayer@hplabs.hpl.hp.com (Niels Mayer) (06/04/91)
In article <188@atesysv.UUCP> lanzo@wgate.wgate.com (Mark Lanzo) writes: > What is the correct way to get all of the Motif resource type > converters registered when my application starts up? I do it this way: ... /* * Initialize the toolkit */ XtToolkitInitialize(); /* * Initialize Resource converters: normally, these functions are called * from XtCreateWidget(), XtCreateManagedWidget(), XtCreatePopupShell(), and * XtAppCreateShell(); they only get called the first time you create a * widget of class Primitive or Manager because they're called from the * ClassInitialize() procedure. With the way WINTERP's automatic resource * converters work, you can end up asking for a resource conversion to occur * before any ClassInitialize() procs are called, and that would cause errors * like "X Toolkit Warning: No type converter registered for 'String' to ..." */ XmRegisterConverters(); /* from Xm/ResConvert.c -- used in Manager, Primitive and Vendor ClassInitialize() */ _XmRegisterPixmapConverters(); /* from Xm/Visual.c -- used in Manager and Primitive */ ... XtMainLoop(); /* or equivalent event loop */ This works on Motif 1.0 (at least on HPUX 7.0) and works on every vendor's Motif 1.1 other than Motif 1.1 for Ultrix (see below). Thus, I ask the following side-question for those in-the-know at DEC: I just received a problem report from someone using DEC's version of Motif 1.1 on a DEC Station. (I didn't even know DEC had released Motif 1.1 yet, but that's another story). This person claims that _XmRegisterPixmapConverters() isn't defined in his version of Motif 1.1, and the lack of external definition results in a link-time error. I know that _XmRegisterPixmapConverters() is defined in the Motif 1.1.0 and 1.1.1 sources from OSF, so I'm wondering whether DEC altered the compiled Motif libs distributed with Ultrix in order to prevent access to such internal functions??? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Someone from DEC please answer this!!! You may question the need for calling the aforementioned initialization functions, but some applications may actually need to invoke a resource converter before the first primitive widget is created. Creating a primitive widget invokes the ClassInitialize() proc which in turn invokes XmRegisterConverters() and _XmRegisterPixmapConverters(). NOT invoking those procedures can leave you open to obscure bugs which will only occur the first time a widget is created. The workaround, of course, is to force the creation of a primitive widget before invoking a resource converter: create a shell widget and put a primitive widget inside that shell (e.g. a pushbutton), then XtUnmap() the shell so that the user doesn't have to see it... Disgusting? I know, but I've had to hack around stupider limitations in the past, so I'm used to it. >This works fine; however, I am uncomfortable using a function which >I would never know existed had I not looked for it in the source code >for the Motif toolkit. It works fine, however, if you try to port your code to platforms where gratuitous and uncecessary changes to the Motif source have been made by the vendor supplying the library, then you're hosed. In my experiences in making a portable Motif package (WINTERP), IBM has been the worst culprit at doing this with Motif 1.0. It looks like DEC is following in their footsteps. At least the Motif 1.1 released by HP has an API that seems consistent with OSF's Motif 1.1 API, despite major differences/improvements in implementation. >So: is there a more "proper" way to do this? I'd like to hear about a proper way to do this. Better yet, I'd like to propose that (1) XmRegisterConverters() and _XmRegisterPixmapConverters() become part of Motif's AES, such that vendors can no longer take liberties with the source.... or... (2) That XmRegisterConverters() and _XmRegisterPixmapConverters() and perhaps even _XmInitializeExtensions() become available in a procedure (e.g. XmInitilize()) which is part of the Motif AES. ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com (... I work for, but don't speak for ...) Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
pete@IRIS49.BIOSYM.COM (Pete Ware) (06/04/91)
>The workaround, of course, is to force the creation of a primitive widget >before invoking a resource converter: create a shell widget and put a >primitive widget inside that shell (e.g. a pushbutton), then XtUnmap() the >shell so that the user doesn't have to see it... Disgusting? I know, but >I've had to hack around stupider limitations in the past, so I'm used to it. Use XtInitializeWidgetClass (an R4 addition) as a cleaner alternative. --pete Pete Ware / Biosym / San Diego CA / (619) 546-5532 email: pete@biosym.com
lanzo@wgate.UUCP (Mark Lanzo) (06/05/91)
In a prior article klee@wsl.dec.com wrote:
] In article <188@atesysv.UUCP>, lanzo@wgate.wgate.com (Mark Lanzo) writes:
] |> What is the correct way to get all of the Motif resource type
] |> converters registered when my application starts up?
]
] Widget set resource converters are usually registered when the vendor
] shell widget class for that widget set is created. This is true of
] both the Athena and Motif widget sets. Normally, the first widget you
] would create is a vendor shell. Is there some reason you are not?
No there isn't. As my prior article showed, I call XtInitialize() to
create my first widget. XtInitialize supposedly creates an ApplicationShell,
which is subclass of VendorShell.
Part of the point of my prior posting was that I thought it was odd
that I needed to call XmRegisterConverters(); I had expected it to
be implicit with the XtInitialize call (as you have also implied).
This does leave me with a question though: how does the Intrinsics
function XtInitialize determine that it should be creating the
(supposedly) libXm-defined widget ApplicationShell? The documentation
I have for the Intrinsics lib states that XtInitialize() creates a
TopLevelShell, but all of the documentation I have on Motif indicates
that XtInitialize returns an ApplicationShell instead. I checked libXm.a;
it does not redefine the function XtInitialize().
Actually, if I do symbol dumps on the libraries, I find that
applicationShellWidgetClass is defined in libXt.a rather than libXm.a.
Is this the way it is supposed to be? This means either (a) the
documentation I have is wrong; applicationShells are part of the
Xt Intrinsics, or (b) libXt.a has been tweaked for the benefit of Motif.
If the latter is true, then I would have expected the other functions
to also have been tweaked to correctly do all the extra initialization
required by the Motif library.
Is there (or should there be) some Motif function that takes the place
of XtInitialize? Motif apparently doesn't supply an analogous routine
to XtInitialize, e.g. XmInitialize.
Perhaps I should go program in MS-Windows instead :-)
--Mark--