Re: Various comments, mostly on Implementation Notes

[Owen Taylor <otaylor redhat com>]

Matthias Ettrich <ettrich@trolltech.com> writes:

> > >and section 4.1.2.3 is pretty explicit in saying that X,Y should only
> > >be the upper left hand corner of the window when win_gravity is
> > >static.
> > 
> > Yep, you are absolutely right. With the default NorthWest gravity
> > client's position will be x+left_border_width, y+top_border_width.
> > 
> > Unfortunately many Window Managers, even thou they claim to be ICCCM
> > compliant, neglect to obey this. (Which is understandable, since its
> > much harder to implement then it looks like).
> 
> Many? Not  *single* one of the popular wms does it. I tried mwm, fvwm,
> afterstep, blackbox.
> 
> I did that once in kwm or kwin, but people complained. 
> 
> Oven, are there any WMs that do this according to ICCCM? If I make Qt behave
> right, it's broken on 99% of the platforms people are using Qt on.... same is
> true with GTK+.
> 
> I don't know what to do.

It's not at all an easy question. You are right that most window 
managers don't follow the ICCCM in this regard (in fact, in a quick 
test twm was the only one that did.)

But I don't think just standardizing the current defacto behavior
is a good idea. If we leave aside the fact that the it is not
compatible with a strict reading of the ICCCM, it is also is
not a particularly sensible behavior.

I'd much rather not expose to the application programmer the fact
that that positioning a window before showing it has different
effects from positioning the window afterwords. 

One possible way to make sure that we have defined behavior moving
forward is to define:

 - Some way of windowd managers to recognize applications 
   that expect whatever positioning behavior we define.

   (E.g., add an extra property, or piggy-back it onto one of
   the existing properies.)

 - Some way for applications to recognize window managers that
   honor the new positioning behavior.

Then applications and window managers would have the freedom
to pick whatever behavior they thought works best when dealing
with legacy apps or window managers.

Regards,
                                        Owen


(Perhaps we should also think about the fact that the ICCCM does not
expose any way of determining what the current location of a window
is in a way that could be saved and then later used for a newly
mapped window to restore the same position. 

The way that GTK+ does this now is to crawl up window hierarchy to one
window before the (pseudo-)root window and assume that that window
corresponds to the window manager decorations. Which may be
somewhat less than robust.)