Re: Initial window placement

[Havoc Pennington <hp redhat com>]

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?

Havoc