Conference bulova::decw_jan-89_to_nov-90

    Border_width is ignored when the window manager is running because
    the border is considered part of the window manager's decoration
    and thus is not within the client's domain to specify it. 
    
    I don't know about the other questions.

>  Is it a  "design feature" that the  DEC Window Manager  ignores program
>  requests for operations on top-level windows that the program has created
>  or is it a problem within the DWM ?

Yes, it is a design feature and not a problem.  The window manager establishes
a common policy for handling application windows.  This includes things like
borders, placement, and so on.

>    i) XCreateSimpleWindow ignores the border_width argument ;

The value supplied is a `hint' and is used if a value wouldn't otherwise be
supplied.  Commonly, the window manager sets this based on user preferences.

>   ii) XGetWindowAttributes returns  zero for X & Y position if the window
       is mapped but returns the correct values if the window is unmapped.

Some window managers create parent windows to hold the window and the decoration.
The position will be relative to the parent window, not the root window.  I'm
not sure about what is going on when the window is unmapped; is this before the
window is mapped the first time?

Since the window manager places the windows for the user, the application
shouldn't care where the window really is.

However, the application can, and should provide `hints' to the window manager.
One set of window manager hints are the window geometry.

  iii) XResizeWindow doesn't.

Again, it is the window manager that determines what size windows are based on
the user requests and the policy.

> Why does DWM ignore program ?

It doesn't ignore the program, but it may be overriding the program because of
the policy decisions implemented for the user.  You can view the window manager
as a bureaucrat; no matter how reasonable your request, it persists in doing
things according to a set of rules.  Further aggravating things, you probably
are using the right `forms' to make your requests to the window manager.  Some
of them will take action only if you use the proper form, ie., a window manager
hint.

What are you trying to do?

Remember, the application controls placement and size of only the child windows
of the main application window.  The user controls the placement, visibility,
and size of the application window thru the window manager.

 Thanks .1 and .2

 Re : .2

 > I'm not sure about what is going on when the window is unmapped; is this
 > before the window is mapped the first time?

 No.  If you explicitly map the window using XMapWindow, the values returned
 are zero for X and Y. If you explicitly unmap the window using XUnmapWindow,
 the values are correct for the position the window actually occupies [when
 mapped].  If this is the wrong method to find out the position of a mapped
 window, please point me back in the right direction.  Although I agree with
 your comment that "since the window manager places the windows for the user,
 the application shouldn't care where the window really is", it happens that
 to perform the correct operation, he requires the position of the top left
 corner. ( Again, this works fine on other ["straight"] X11 implementations,
 it works fine if you're talking about sub-windows and it works fine if you've
 created "real" top-level windows, without the DWM ).

 Your comment about the WM creating parent windows seems pretty fair but how
 can you find out the position of the parent window w.r.t. the root screen ?
 Would this be a matter of XGetWindowAttributes on the pseudo-root that DWM
 inserts ? [ I'll give it a try but is there a better way ? ]

 Thanks again for the information (both of you).

 Frank

    RE: -1
    
    I have used XGetGeometry to find the position of a mapped
    window and it works.  It wasn't necessary to unmap
    the window.  

    Re : .4
    
    I've tried XGetGeometry with the same results as XGetWindowAttributes.
    [ I suspect the latter calls the former anyway ...]

    If you can find anything wrong with the code that follows the <FF>
    [ other than the total lack of style :-) ] please say so ! I really
    would like to get to the bottom of this.

    Frank

/*
 * Attributes returned incorrectly when window is mapped
 */

#include  <decw$include/x.h>
#include  <decw$include/xlib.h>

Display   *dp = 0 ;

main()
{
  Window    wd ;
  int       i ;
  float     delay = 5.0 ;

  dp = XOpenDisplay("0::0,0") ;
  wd = XCreateSimpleWindow (dp, RootWindow(dp, DefaultScreen(dp)),
               100, 100, 300, 200, 0, 1, 0) ;
  Xsync(dp, 0) ;
  printf("---------------------- Window Created ----------------------\n") ;
  for (i=0 ; i<100 ; ++i)
  {
    prtpos(wd) ;
    lib$wait(&delay) ;
    if (i & 1)
    {
      XUnmapWindow(dp, wd) ;
      printf("---------------------- Window Unmapped ---------------------\n") ;
    }
    else
    {
      XMapWindow(dp, wd) ;
      printf("----------------------- Window Mapped ----------------------\n") ;
    }
    Xsync(dp, 0) ;
  }
  return(1) ;
}

     
int prtpos(wxp)
Window wxp ;
{
  XWindowAttributes  wa ;
  int                x, y ;
  Window             wir ;
  unsigned int       status, wid, hgt, brd, dpt ;

  wa.x = -1 ; wa.y = -1 ;

  XGetWindowAttributes(dp, wxp,  &wa) ;
  printf("GetWindowAttributes : x = %d, y = %d, wd = %d, ht = %d\n",
         wa.x, wa.y, wa.width, wa.height) ;

  status = XGetGeometry(dp, wxp, &wir, &x, &y, &wid, &hgt, &brd, &dpt) ;
  printf("Geometry            : x = %d, y = %d, wd = %d, ht = %d\n",
           x, y, wid, hgt) ;

  return ;
}

    Nothing wrong with your code.
    
    XGetGeometry and XGetWindowAttributes return x and y
    coordinates relative to the parent window.  The window
    that gets mapped is under control of the window manager,
    who has created a parent for your window.  Its your
    window's parent who would return the correct x,y
    coordinates.
    
    When you unmap a window,  window manager destroys the
    parent it had created for your window.   That is why
    you are able to get the correct x,y coordinates after
    the window is unmapped.
    
    I think the best way to get the coordinates,  would
    not be to map and unmap the window,  but to get the
    coordinate's of your window's parent.   I believe
    the toolkit has a way to do this.. XtParent.
    
    Nancy

What you want is the TranslateCoordinates request.  Strangely enough, it is not
documented in the DecPress book, but in the VMS Doc Set, it is.  It translates
coordinates in one window relative to another window.

Burns

    Re : .6, .7
    
    Thanks for the responses.  I'm currently testing if the window is
    unmapped :  if so  then use the X/Y position returned by the call
    to GetWindowAttributes,  otherwise call  TranslateCoordinates and
    use the returned X/Y values.  [ I would have used TranslateCoords
    all the time except for the snag that when the window *is* mapped
    both the X and Y values are doubled ! Hmmm ... I suppose that can
    wait ... ]
    
    Thanks again for your help,
    Frank

    If you use XtParent(your_window), as the window - instead of
    just your_window,  GetGeometry and GetWindowAttributes will
    return X/Y whether you are mapped or unmapped.  No problem
    there with X/Y being doubled. 

    Re : .9
    
    Thanks, I *did* read your reply but haven't had much success with
    trying to use XtParent(window) : either get an X error (not a valid
    window id) or an access violation (with the VA looking like a window
    id) depending on how I pass the window argument. According to my (FT)
    docs, XtParent is expecting a widget id as an argument ... is the above
    still valid ? It appears to be implemented as a macro which is defined
    as ((w)->core.parent) ...

    Expect I'm doing something odd so it's back to the editor ! :-)
    
    Frank

    Thats what I get for not checking calling sequence...
    You need to have created a widget... don't know
    what you are doing so you may or may not want to
    do it that way.
    
    Also XQueryTree returns a parent (of a window not a widget)
    but Im not sure it will return the window you are looking for.
    XQueryTree's are s-l-o-w so it probably isn't any
    better than doing Unmaps and Maps. (if you dont care that
    the window becomes invisible)