jones@kings.wharton.upenn.edu (Christopher V. Jones) (06/11/90)
I am using VMS 5.3, DecWindows version 2. I have tried everything that I can think of to be able to move a toplevelshell widget from within program control. In particular, I have tried: 1. Setting the XtNx and XtNy resources of the widget. 2. Calling XtMoveWidget 3. Calling XtMakeGeometry Request. Is it possible to move a TopLevelShell widget from within program control? Thanks Chris Jones University of Pennsylvania jones@wharton.upenn.edu
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (06/12/90)
> I am using VMS 5.3, DecWindows version 2. I have tried everything that > I can think of to be able to move a toplevelshell widget from within > program control. In particular, I have tried: > 1. Setting the XtNx and XtNy resources of the widget. > 2. Calling XtMoveWidget > 3. Calling XtMakeGeometry Request. > Is it possible to move a TopLevelShell widget from within program control? > Thanks Method 1 is the correct way to for an application to change the location of any widget. As with moving any widget the ultimate decision on whether or not to allow to move it up to the parent of the widget in question. Since Toplevel widgets have no parent the decision usually falls to the window manager. In this case it sounds like your window manager is not allowing the program to modify the location of the clients. This is acceptable (although anti-social) behavior. You may want to try another window manager such as the R4 version of twm or possibly uwm (sudder :-), I believe that both of these allow program control of the client window location. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
marbru@auto-trol.UUCP (Martin Brunecky) (06/12/90)
In article <9006111729.AA21104@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes: > >> I am using VMS 5.3, DecWindows version 2. I have tried everything that >> I can think of to be able to move a toplevelshell widget from within >> program control. In particular, I have tried: > >> 1. Setting the XtNx and XtNy resources of the widget. >> 2. Calling XtMoveWidget >> 3. Calling XtMakeGeometry Request. > >Method 1 is the correct way to for an application to change the location of any >widget.... Unfortunately, some window managers are not only anti-social (ignoring such requests), but also buggy. I have a little test program which moves a shell around (resize/position), and results are very often surprizing: - some wm's ignore SOME, some wm's ignore ALL position requests, though most wm's do honor resize request. In two instances, some geometry requests took "for ever" to complete, for example mwm 1.0 took about 30 sec. to move shell to 0,0 with resize to a particular size. - some wm's properly notify the shell about the actual position (and size), but sveral don't bother, making XtTranslateCoords a useless call. Note wm's often honor the request in "allmost" manner, i.e. rounding to some wm's preferred position, adding decorations etc. (again, mwm example: your x,y are used as an origin of the mwm decorations, not your shell). - another mystery is when the (synthesized) ConfigureNotify event arrives. In some instances (DECwindows shell & DECwindows wm), the shell performs complete handshaking with the wm and won't return until configuration is complete. In other instances, the shell x,y resources have been updated "sometimes later", and in some cases shell's x,y remained unchanged. So, in summary, it is not very realistic to write an application that DEPENDS on shell positioning from the application. Even though (as ICCCM matures) things are getting better. Until X Consortium distrubutes what I would call "ICCCM Compliancy Test Suite", we are all left on window manager writer's mercy (or ability to read and correctly intrepret the ICCCM wording), and how good "field test" a particular wm receives before it hits the user. In addition, even todays ICCCM revision does not include eny provision to query wm for things like positioning policy, decoration types and geometry etc., making the application shell positioning a random game. On the "Compliancy Test Suite" issue. More than one for ICCCM, I see a need for the X protocol one. So far, most servers I dealt with used to be derivatives of MIT sample server - fairly consistent in what bugs and features you could expect. Today, more and more vendors are trying to improve performance with totally new server approaches, and such servers ususally introduce a new set of subtle differences in dealing with X protocol - either bugs or different interpretation of protocol spec reading - often resulting in application missbehavior. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
daver@dg.dg.com (David Rudolph) (06/13/90)
In article <1212@auto-trol.UUCP> marbru@auto-trol.UUCP (Martin Brunecky) writes: >In article <9006111729.AA21104@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes: >> >>> I am using VMS 5.3, DecWindows version 2. I have tried everything that >>> I can think of to be able to move a toplevelshell widget from within >>> program control. In particular, I have tried: >> >>> 1. Setting the XtNx and XtNy resources of the widget. I have found that under Motif and mwm, I was not able to do a move by setting XmNx and XmNy before the widget is managed, but if I do it immediately following an XtManageChild() call, then it works. ---------------------------------------------------------------------------- David Rudolph | phone: (508) 870-6914 Data General Corporation | email: daver@dg.dg.com | or daver%dg.dg.com@dg-rtp.dg.com ----------------------------------------------------------------------------
west@gsrc.dec.com (Jim West) (06/15/90)
In article <25891@netnews.upenn.edu>, jones@kings.wharton.upenn.edu (Christopher V. Jones) writes... >I am using VMS 5.3, DecWindows version 2. I have tried everything that >I can think of to be able to move a toplevelshell widget from within >program control. In particular, I have tried: > >1. Setting the XtNx and XtNy resources of the widget. >2. Calling XtMoveWidget >3. Calling XtMakeGeometry Request. > >Is it possible to move a TopLevelShell widget from within program control? >Thanks Is this just a one time thing or do you want to keep moving it? First thing to do is XSetValues on the widget returned from XtInitialize before the XtRealize, this will set your initial position. The quick (and dirty) way to move this widget is to get the window id, unmap the window, do an XChangeWindowAttributes, and remap the window. Or you can do anything that is equivilent. The trick is to 'unmap' the window first, change X and Y (or anything else) and then 'remap' the window. I've done this with success. ---------------------------------------------------------------------- Jim West | The Schainker Converse west@gsrc.dec.com | to Hoare's Law : | These are my opinions. | Inside every small problem Digital has no idea | is a larger problem struggling what I'm saying. | to get out. ----------------------------------------------------------------------