Re: move/resize handling again



On Fri, 2002-11-15 at 11:43, Dominik Vogt wrote:
> 
> The description looks good.  I am a bit unhappy that it seems to
> suggest it is a good idea to change the win_gravity often.  The
> ICCCM says that the "last" win_gravity is used, but this suffers
> from the same problem as with the size inc hints we discussed a
> while ago.  The WM only gets a message that is has changed, but
> has to look up the value itself.  The hint can already have
> changed again when the WM gets around looking it up.  E.g.
> 
>   - set NW gravity
>   - moveresize to 100x100+0+0
>   - set SE gravity
>   - resize to 50x50
> 
> may be read by the WM as
> 
>   - set SE gravity
>   - moveresize to 100x100+0+0
>   - set SE gravity
>   - resize to 50x50
> 

Would adding a note explaining the race condition help ? Like so:


		<listitem><para>
Applications are free to change their win_gravity setting at any time.
		</para>
		<para>
If an Application changes its win_gravity then the Window Manager should
adjust the reference point, so that the client window will not move as
the result. For example if the Application's win_gravity was
NorthWestGravity and reference point was at the top-left corner of the
frame window, then after change of win_gravity to SouthEastGravity the
reference point should be adjusted to point to the lower-right corner of
the frame.
		</para>
                <note>
                <para> 
Changing the win_gravity for a single configure request and back
afterwards is unlikely to work as intended, due to a race condition. The
window manager sees a property notify for WM_NORMAL_HINTS, followed by
the configure request, followed by another property notify for
WM_NORMAL_HINTS. By the time the window manager gets around to request
the changed WM_NORMAL_HINTS in response to the first property notify,
the server may have already processed the second property change.  
                </para>
                <para>
If the window manager supports it, applications should use 
_NET_MOVERESIZE_WINDOW with a specified gravity to avoid this problem.
                </para>
                </note>
                </listitem>







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]