montnaro@spyder.crd.ge.com (Skip Montanaro) (04/04/91)
I am using a number of FormDialog widgets as independent windows in an application (Motif 1.1, OpenWindows, mwm). When the application starts, the application main window is placed interactively (it's attached to the cursor), since mwm*interactivePlacement is true. Unfortunately, all dialog pop-ups come up initially smack dab in the middle of the main window. I've read through the mwm and FormDialog (and superclasses) man pages and can't find any resource that seems to control this behavior. Where am I going wrong? Another problem I'm having is trying to ever get the application's main window to stack above the various pop-ups that are visible. Is there a way to do it? Perhaps there's a different top-level widget I should be using than a FormDialog? Thanks, -- Skip (montanaro@crdgw1.ge.com)
koff@hpfcbig.SDE.HP.COM (Caroline Koff) (04/09/91)
Skip Montanaro (montnaro@spyder.crd.ge.com) writes: > Unfortunately, all dialog pop-ups come up initially smack dab in the middle > of the main window. I've read through the mwm and FormDialog (and > superclasses) man pages and can't find any resource that seems to control > this behavior. Where am I going wrong? Try setting the XmNdefaultPosition to False when you create the dialog boxes, as in XtSetArg(args[i], XmNdefaultPosition, False). Then to position your dialog boxes on your own, use XtMoveWidget call. --Caroline Koff
montnaro@spyder.crd.ge.com (Skip Montanaro) (04/09/91)
In article <MONTNARO.91Apr4074149@spyder.crd.ge.com> I wrote:
I am using a number of FormDialog widgets as independent windows in an
application (Motif 1.1, OpenWindows, mwm). When the application starts, the
application main window is placed interactively (it's attached to the
cursor), since mwm*interactivePlacement is true.
Unfortunately, all dialog pop-ups come up initially smack dab in the middle
of the main window. I've read through the mwm and FormDialog (and
superclasses) man pages and can't find any resource that seems to control
this behavior. Where am I going wrong?
Several people responded to my posting, all referring me to the
defaultPosition resource. When set to false, the window manager is supposed
to obey the x and y resource settings. That is, in fact, what happens.
Thanks to all who replied.
In rereading my original posting though, I realize I did not describe
clearly the desired behavior. I want to interactively place the pop-ups the
first time they are realized. That is, I'd like the pop-up's initial
placement to be interactive (attached to the cursor), just like the main
application window. Is there not some way to do this?
None of the dialogs I'm referring to are modal. I expect the user to keep
them popped up for an extended period of time, which was why I asked the
second question:
Another problem I'm having is trying to ever get the application's main
window to stack above the various pop-ups that are visible. Is there a way
to do it? Perhaps there's a different top-level widget I should be using
than a FormDialog?
I realize that windows can get lost in the stacking order if they are
completely independent. I do like the behavior that all the application's
windows pop to the top of the stack when one is raised. Is there some reason
the main application window is constrained to always be below the popups,
other than the fact that it is contrary to the Motif Style Guide? It seems
peculiar, given the fact that just about everything else about Motif can be
customized. (BTW, that's the main reason I initially liked mwm better than
olwm. I could make mwm "feel" more like SunView than olwm :-).
Thanks,
--
Skip (montanaro@crdgw1.ge.com)gdmr@cs.ed.ac.uk (George Ross) (04/11/91)
In article <12110005@hpfcbig.SDE.HP.COM>, koff@hpfcbig.SDE.HP.COM (Caroline Koff) writes: > Try setting the XmNdefaultPosition to False when you create the dialog > boxes, as in XtSetArg(args[i], XmNdefaultPosition, False). Then to > position your dialog boxes on your own, use XtMoveWidget call. > From Asente & Swick chapter 4, page 204 (at the "warning hand"): "The only way for an application to request a geometry change for a widget is to issue an XtSetValues call setting some of the geometry resources. This is very important to remember. Other methods of changing geometry exist in the toolkit, but they are for use either by parents to change the geometry of their children or for a widget instance to request a change in its own geometry. Unfortunately, the Intrinsics cannot enforce this. If you ever find yourself using anything other than XtSetValues to control a widget's geometry from within an application, you have made a programming error, and the widgets are likely to become corrupted." -- George D M Ross, Department of Computer Science, University of Edinburgh Kings Buildings, Mayfield Road, Edinburgh, Scotland, EH9 3JZ Tel: 031-650 5147 Internet: gdmr@cs.ed.ac.uk JANET: gdmr@uk.ac.ed.cs
montnaro@spyder.crd.ge.com (Skip Montanaro) (04/11/91)
In article <MONTNARO.91Apr8223953@spyder.crd.ge.com> I asked again about
interactive placement of popups, more clearly than the first time. I
received a perfect answer from a fellow at Bellcore (thanks Andrew, you get
an 'A').
To summarize, dialog widgets are subclassed from TransientShell which sets
the WM_TRANSIENT_FOR hint. Mwm sees this and responds accordingly, generally
doing useful things if the popup is short-lived. To get interactive popup
placement, and other more independent behavior appropriate to long-term
popups, use a TopLevelShell as the parent of the widget you're interested in
displaying. Use XtPopup/XtPopdown to turn it on and off.
--
Skip (montanaro@crdgw1.ge.com)rudolph@sparc20.hri.com (David Rudolph) (04/16/91)
In article <12110005@hpfcbig.SDE.HP.COM>, koff@hpfcbig.SDE.HP.COM (Caroline Koff) writes: > Skip Montanaro (montnaro@spyder.crd.ge.com) writes: > > Unfortunately, all dialog pop-ups come up initially smack dab in the middle > > of the main window. I've read through the mwm and FormDialog (and > > superclasses) man pages and can't find any resource that seems to control > > this behavior. Where am I going wrong? > > Try setting the XmNdefaultPosition to False when you create the dialog > boxes, as in XtSetArg(args[i], XmNdefaultPosition, False). Then to > position your dialog boxes on your own, use XtMoveWidget call. > > --Caroline Koff When I tried setting XmNdefaultPosition to false, the window came up at (0,0). Since I have interactivePlacement set to True, I expected that I would be able to position the window with the mouse. Any ideas why this wasn't the case? ---------------------------------------------------------------------------- David Rudolph | phone: (617) 466-8370 Horizon Research, Inc. | email: rudolph@hri.com ----------------------------------------------------------------------------
slh@gibdo.engr.washington.edu () (04/19/91)
In article <1991Apr16.131440.16590@hri.com> rudolph@sparc20.hri.com (David Rudolph) writes: [stuff] |When I tried setting XmNdefaultPosition to false, the window came up at |(0,0). Since I have interactivePlacement set to True, I expected that I |would be able to position the window with the mouse. Any ideas why this |wasn't the case? | R3/Motif 1.somethingorother on AIX3.1.5/IBM RS/6000-530: I'm not using interactive placement and setting XmNdefaultPosition to False doesn't give the results desired either. I've tried all sorts of combinations, even tried unmapping the window, managing, setting the position and mapping, still sucks. If the dialog is up and I try invoking it again (with the button that activates it) it finally goes where it should, not satisfactory. Hmmm, maybe if you unmap it, manage it twice... Also so since I'm whining, I've never been able to get rid of decorations on a toplevel at execute time. (using mwm* resources in .Xdefaults doesn't count for this) This has also been discussed a lot and I think I've tried all the suggestions. I suppose most likely both of these things are broken...
slh@gibdo.engr.washington.edu (04/19/91)
In article <1991Apr19.110554.13933@gibdo.engr.washington.edu> slh@gibdo.engr.washington.edu (PUT YOUR NAME HERE) writes: [stuff] | R3/Motif 1.somethingorother on AIX3.1.5/IBM RS/6000-530: | oops, for those who care that should have been 1.0.somethingorother I also like that Organization line and name field you get when nothing is set.
ik@snoopy.bellcore.com (Ik Su Yoo) (04/19/91)
In article <1991Apr19.110554.13933@gibdo.engr.washington.edu>, slh@gibdo.engr.washington.edu writes: > In article <1991Apr16.131440.16590@hri.com> rudolph@sparc20.hri.com (David Rudolph) writes: > [stuff] > |When I tried setting XmNdefaultPosition to false, the window came up at > |(0,0). Since I have interactivePlacement set to True, I expected that I > |would be able to position the window with the mouse. Any ideas why this > |wasn't the case? > | > R3/Motif 1.somethingorother on AIX3.1.5/IBM RS/6000-530: > > I'm not using interactive placement and setting > XmNdefaultPosition to False doesn't give the results desired either. > I've tried all sorts of combinations, > even tried unmapping the window, managing, setting the position > and mapping, still sucks. > If the dialog is up and I try invoking it again > (with the button that activates it) it finally goes where it should, > not satisfactory. > Hmmm, maybe if you unmap it, manage it twice... > > Also so since I'm whining, I've never been able to get rid > of decorations on a toplevel at execute time. > (using mwm* resources in .Xdefaults doesn't count for this) > This has also been discussed a lot and I think I've tried > all the suggestions. > > I suppose most likely both of these things are broken... Try unmapping it and managing it twice while doing a hand stand :-) Seriously, though, I got the "right thing" to happen by not realizing the dialog's parent widget and setting XmNdefaultPosition to false. In most cases, you'd want to realize your parent widget, especially if it is the top level widget containing your main window. If this is the case, try creating a dummy application shell, never realizing it, and creating pop-up dialogs as its children. Of course, you can try other variations, too. This may be highly implementation dependent, I don't know. Ik Su Yoo RRC 1H-229, (908) 699-5764 ik@ctt.bellcore.com
nazgul@alfalfa.com (Information Junkie) (04/19/91)
> I'm not using interactive placement and setting > XmNdefaultPosition to False doesn't give the results desired either. I've posted code to do this before, if anyone wants it again just let me know. It's in C++, but it's not that big a deal to rewrite, and it not only handles turning off the defaultPosition, but allows you to set a new position relative to the parent (e.g. top left, bottom right, etc). 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.
nazgul@alfalfa.com (Information Junkie) (04/19/91)
> In article <1991Apr16.131440.16590@hri.com> rudolph@sparc20.hri.com (David Rudolph) writes: > [stuff] > |When I tried setting XmNdefaultPosition to false, the window came up at > |(0,0). Since I have interactivePlacement set to True, I expected that I > |would be able to position the window with the mouse. Any ideas why this > |wasn't the case? Oh yes. As for this, it's because interactivePlacement isn't meant to affect dialogs. If you don't like it you'll probably have to use a shell that doesn't set transientFor. Personally I think a dialog that required me to place it everytime would be real annoying. 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.