hill@nicmad.UUCP (Ray Hill) (07/26/88)
Another Xtk Problem or Limitation: ---------------------------------- 1. Is there anyway to find the size the Athena "form" widget will become before it is realized? 2. Is there anyway to move a "transient shell" widget after it has been realized? (or popped up once?) It seems impossible to center a "transient shell" widget on the screen with the existing widgets. My "transient shell" widget has a "form" widget as a child. I can't get the size of a "form" widget until after its realized and I can't position the "transient shell" widget after its realized. So how can an arbitrary "transient shell" widget be centered on the screen or over a particular widget? Thanks. Ray Hill hill@nicmad
diamant@hpfclp.SDE.HP.COM (John Diamant) (07/28/88)
> 1. Is there anyway to find the size the Athena "form" widget will become > before it is realized? Not that I know of. I don't think even the widget knows its eventual size until it is realized. > 2. Is there anyway to move a "transient shell" widget after it has been > realized? (or popped up once?) Yes, there should be. You should be able to use XtMoveWidget. What window manager are you using? If it is a reparenting window manager, the problem is most likely a change in the conventions having to do with changing hints versus configure. The problem is that if the window is reparented, it now has coordinates relative to the window manager window (maybe 0,0) so a move doesn't do what you want unless the window manager is careful to follow the lastest conventions (and the Toolkit has to be following them too). In my case, what happens under a window manager which is paying attention to the hints, is that it keeps seeing the 0,0 and puts the window there, instead of the location requested by the actual configure (but the 0,0 it uses is root-relative -- not quite what you want). I'll bet it works under a non- reparenting window manager, and it should work fine under a reparenting one once the conventions are consistent in both the Toolkit and the window manager. If you want to prove this is what is happening, see what happens when you try to move an overrideShell window instead (don't leave the dialog box that way, but test it out). John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
hill@nicmad.UUCP (Ray Hill) (08/02/88)
In article <9740044@hpfclp.SDE.HP.COM>, diamant@hpfclp.SDE.HP.COM (John Diamant) writes: > > 2. Is there anyway to move a "transient shell" widget after it has been > > realized? (or popped up once?) > > Yes, there should be. You should be able to use XtMoveWidget. The X Toolkit Intrinsics Documentation for X11.2 on page 69 seems to be saying that XtMoveWidget should only be called by the parent of the widget. It also says that "Clients that wish to change the geometry of a widget should call XtSetValues ..." Using XtSetValues has no affect after the transient widget has been mapped once. > What window manager are you using? X11.2 release of "uwm". > If it is a reparenting window manager, the problem is > most likely a change in the conventions having to do with changing hints > versus configure. I don't think so. > If you want to prove this is what is happening, see what happens when you > try to move an overrideShell window instead (don't leave the dialog box that > way, but test it out). This change made no difference. > John Diamant > Software Development Environments > Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com > Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant Well, even though the docs told me not to, I called XtMoveWidget. And guess what, it works. However, one must not to call "XtMoveWidget" in place of XtSetValues in all cases. Thanks for the help John. I'm posting this to see if there is a more correct way. Or is this the right way the docs are wrong (or I'm reading them wrong). I'd hate to have to re-write my code after a switch to X11.3 or a different platform. Ray Hill hill@nicmad
asente@WSL.DEC.COM (08/02/88)
Regarding calling XtMoveWidget vs. doing an XtSetValues: The "proper" way for client (i.e.non-parent) code to get a widget moved is always XtSetValues. There are some bugs in early releases that keep this from working with shells; it's fixed in the next release (sorry). -paul asente
swick@ATHENA.MIT.EDU (Ralph R. Swick) (08/03/88)
Date: 26 Jul 88 14:56:19 GMT
From: astroatc!nicmad!hill@speedy.cs.wisc.edu (Ray Hill)
1. Is there anyway to find the size the Athena "form" widget will become
before it is realized?
No, not in the general case. XtQueryGeometry will tell you what geometry
a widget would prefer to have (not implemented in R2/Xaw/Form), but the
parent has the final say. This propagates all the way up the widget tree
until you reach a Shell, which attempts to conform to the child's
preferred geometry. You could XtSetMappedWhenManaged(,False) on
the shell, realize the sub-tree, examine the geometry and map later.
If you are simply attempting to position a dialog box, this would be
the best approach. However, the final authority is the window manager
(under the user's direction) which doesn't assume control until the
window is mapped, so you really can't be sure of your geometry until then.
2. Is there anyway to move a "transient shell" widget after it has been
realized? (or popped up once?)
Yes, use XtSetValues. You have to have allowShellResize==True or the
shell will discard the request. [Note: XtMoveWidget is not the proper
procedure, as suggested in another message. It is reserved to the
parent of the widget being moved.]
It seems impossible to center a "transient shell" widget on the screen
with the existing widgets. My "transient shell" widget has a "form" widget as a
child. I can't get the size of a "form" widget until after its realized and I
can't position the "transient shell" widget after its realized. So how can an
arbitrary "transient shell" widget be centered on the screen or over a
particular widget?
Given a moderately co-operative window manager, changing set_mapped_when_
managed as suggested above is the most convenient method.diamant@hpfclp.SDE.HP.COM (John Diamant) (08/06/88)
> Regarding calling XtMoveWidget vs. doing an XtSetValues: > > The "proper" way for client (i.e.non-parent) code to get a widget moved is > always XtSetValues. There are some bugs in early releases that keep this > from working with shells; it's fixed in the next release (sorry). Sorry for the misinformation earlier, and thanks for the clarification. As soon as XtSetValues works for the realized shell, I'll be perfectly happy to switch to using it. By the way, I started using XtMoveWidget because I looked at the R2 xmh code, and that's what it did (probably because of the bug). John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant