ndd@romeo.cs.duke.edu (Ned D. Danieley) (04/21/89)
X11R3, patches 1-8, gcc 1.33, twm 1.2, Sun 3/280, SunOs 3.5 I have an application which starts off like: XtToolkitInitialize(); context = XtCreateApplicationContext(); dpy = XtOpenDisplay(context, NULL, "test", "Test", NULL, 0, argc, argv); toplevel = XtAppCreateShell(NULL, NULL, applicationShellWidgetClass, dpy, NULL, NULL); I then set the dimensions of toplevel using XtSetValues, create a Form widget whose parent is toplevel, and add some buttons to that form (call it TopForm). Now what I want to do is click on one of the buttons in TopForm, and create another form widget. The problem I'm having is that this second form, which I make a child of toplevel, always comes up right on top of TopForm, and is clipped by TopForm. It turns out that these secondary forms need to be a good bit bigger than TopForm, so this causes problems. Am I really restricted to the size (and location) of toplevel when I create its children? Ned Danieley (ndd@sunbar.mc.duke.edu) Basic Arrhythmia Laboratory Box 3140, Duke University Medical Center Durham, NC 27710 (919) 684-6807 or 684-6942
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (04/25/89)
[ "Ned D. Danieley" <romeo!ndd@cs.duke.edu> writes: ] > Now what I want to do is click on one of the buttons > in TopForm, and create another form widget. The problem I'm having is > that this second form, which I make a child of toplevel... Shell Widgets can only have one child, if you want to have more than one child in a Shell you need to put another widget layer in the application. from this: child shell -> topForm -> child -> other form to this: child shell -> composite widgete -> topForm -> child -> other form Chris D. Peterson MIT X Consortium
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (04/25/89)
I am Posting this to xpert, bacause I think it may be of general interest. > Well, I tried what you suggested (or what I think you suggested), and > it doesn't seem to help. > What I really want is: > -------- > | ------ | > || || > || || > || || > || || > || || > || || > || || > | ------ | > -------- > ------------------- > | | > | | > | | > | | > | NextForm | > | | > ------------------- > or some such. Oh, sorry to give you the wrong advice, I was confused. Since your nextForm widget will not be clipped by the original Shell widget its window will need to be a child of the root window of the display. The only widgets that can be children of the root window are Shell widgets. Thes widgets know how to interact with the window manager. What you need to do is use XtCreatePopupShell() using applicationShellWidgetClass. I would use the Shell returned by XtInitialize() as the parent of this popup. This will give you resource specs of: top.form.Command.label: foo and top.nextShell.nextForm.Command.label: bar Since nextShell would be a direct decendant of top. To make this form visable use: XtPopup(nextShell, XtGrabNone); or XtRealizeWidget(); XtMapWidget(); /* popup shells may not get explicitly mapped at realize time, this is done so you can realize menus at creation time, event though you are not ready to map them yet. */ For more info in the Intrinsics manual read: Chapter 4 Shell Widgets Chapter 5 Popup Widgets For example code take a look at xman from the R3 tape (it is best if you have patches 1-8 applied since xman got major changes). Xman pops up multiple children of the root (each new manpage). The code that does this is called CreateManpage() and is in buttons.c. Xman uses the strategy of never realizing the widget returned by XtInitialize. This allows all manual pages to be equal. > I've tried looking at other code, but almost everything is still using > XtInitialize, XtInitialize() will probabally be move back into the main specification in R4 as it is a useful convience routine, don't spend a lot of time converting unless you have need that require it. I have gone to using XtInitialize() combined with XtWidgetToApplicationContext() to get my appcontext so that I can use XtAppMainLoop() and the other XtApp*() functions. > Basically, I'd like to be able to place widgets at arbitrary screen locations, > without my users having to point and click. But how do you know where is a good place to put the window? It seems to me that the only person who really knows where to put a window is the user, and if he doesn't like to point and click then he/she can put a geometry specification in his/her resource file. Chris D. Peterson MIT X Consortium