Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!ncar!ico!auto-trol!marbru
From: marbru@auto-trol.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: Repositioning TopLevelShell Widgets
Message-ID: <1212@auto-trol.UUCP>
Date: 12 Jun 90 16:28:58 GMT
References: <25891@netnews.upenn.edu> <9006111729.AA21104@expo.lcs.mit.edu>
Reply-To: marbru@auto-trol.UUCP (Martin Brunecky)
Organization: Auto-trol Technology, Denver
Lines: 63

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