Re: Initial window placement

[Sasha_Vasko osca state mo us]

> Hi,
>
> Rather than specifying a way to tell the WM what frame dimensions to
> use, what if we just allow clients to _find out_ the current frame
> dimensions of a window - then, you can align two windows using the
> standard win gravity and configure request stuff.
>
> i.e. if I have window A and want window B to be tiled to the right of
> it, I would get the dimensions of A, set NorthWest gravity on B, then
> XMoveWindow() B such that it would be to snapped to A's frame, and the
> WM would align the frame of B next to the frame of A.
>
> The missing piece in the current ICCCM/EWMH is simply that you can't
> find out where the edges of A's frame are.
>
> This does make it hard to map a bunch of tiled windows at once, I
> guess (you have to wait for A to be decorated and mapped before you
> can map B).
>
> I don't know - this is certainly something app programmers
> occasionally want to do, but I'm not sure it's something we can sanely
> allow them to do.
>
> We should probably make a list of acceptable use-cases - the only one
> I can think of is for toolbar/menu kind of windows, maybe the app
> knows better than the WM where to place those.
>
> The other use case we came up with when reworking the GTK window
> sizing/positioning API was what we called "Java IDE," because I think
> Forte from Sun tries to tile its own windows with pretty questionable
> results. In the end, we didn't really add support for this to GTK; we
> couldn't figure out a good way to implement it, and weren't sure Forte
> should be doing that anyhow.
>
> Perhaps we could think about some kind of richer semantic hints to
> cover the reasons people want to position windows this way - I'm not
> sure what those would be. Perhaps hints that specified an
> interpretation for the TRANSIENT_FOR hint?

We could add _NET_WM_ALLIGN_TO , or perhaps _NET_WM_SLAVE_FOR, hint
with window ID of the master window to align to and relationship
specification - West, North, East, South.
Any window that has this property set will have its move requests
ignored by Window Manager, and instead will be moved according to change
in position of its master.

The other valid reason why client should know about its frame's position
is to save it, and be able to restore its position next time it starts.
But since providing client with raw data will make it prone to errors
in the way client translates it into actuall position, we better provide
client with ready to use data - exact position, size and border width
of the client, that has to be set by application in order to appear in
exact same place after all the window manager adjustments:

_NET_WM_SAVE_GEOMETRY <client_x><client_y><client_width><client_height>
<client_bw><gravity>

All the client has to do is save this somewhere, and when it restarts,
supply this exact data to XCreateWindow and WM_NORMAL_HINTS. Window
Manager will have to update this property each time window is moved.
Sort of making it as foolproof as possible.



Cheers
Sasha.

>
> Havoc