Re: Various comments, mostly on Implementation Notes

[Sasha_Vasko osca state mo us]

>> > >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.
>> >
<snip>
>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.)

<snip>
>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.)

This is very bad approach, since most of the WMs that don't follow
ICCCM's specs in this aspect are actually convinced that they ARE
following specs. So if you add some sort of a property to define
the behavior - it does not really gurantees you that WM really does
what it says. In fact it will fool most ppl into the false sense of
security. Only run time tests for actual behaviour can give you
any garantees.

In regards of that it might be a good idea to define a set of tests
that can show if WM is compliant or not, so that anybody could verify
that WM really is  what it says it is ( including developers ).

>
> - 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.)

Yes, but you only have to do it once ( when saving position ).
On the other hand maintaining a property defining the actuall size of
the decorations will be a pain in the butt, since it will be on
per-window basis and possibly dynamically changing with high frequency.
Besides it will be a perfect waste of resources, since wast majority of
clients will never be using it.

Cheers
Sasha Vasko