Re: Initial window placement

[Havoc Pennington <hp redhat com>]

Philipp Lohmann <Philipp Lohmann Sun COM> writes:
> Am 16.08.01, 18:16:26, schrieb Havoc Pennington <hp redhat com> zum Thema 
> Re: Initial window placement:
> 
> > Because if clients manage windows, you get different window management
> > for each client. If the window manager manages windows, you get
> > coherent, consistent window management.
> 
> Sorry, that's theory only. In reality the WM will place windows anywhere. 
> Maybe where there is space, maybe random and some even put the task of 
> initial placement on the user.

Well yes, that's the point. The WM can decide to have a policy such as
first-fit, random, or manual placement. If the client starts trying to
specify, then you can't have the WM choose that. What I mean by
"coherent, consistent" is "within a single WM" - if you want coherent,
consistent across multiple machines, the simple solution is to
standardize on a single WM.

Also, there are interactions between clients and various
placement/contraint policies. For example, if I have a certain policy
for docks (say, keep on top, or raise on mouseover), then that impacts
how I want to treat the doc for e.g. maximization or window resizing
constraints.

So the client simply can't know what kind of positioning makes sense.

> If the user tries to arrange his windows 
> by e.g. using a -geometry parameter he will not get what he wants if he 
> switches to another WM or in some case not at all. And some user  have to 
> use different window managers simply because they have to use multiple 
> workstations. This geometry problem could  be solved easily by having a 
> hint where to put the frame instead of the window.

I don't understand what problem you mean? What is the issue?
 
I don't see how different WM's behaving differently is a problem, that
is the purpose of allowing different WM's. If you don't want different
WM's, then don't use them. ;-)

> The window management IS partly on client side, else we wouldn't need to 
> bother with WM hints at all. Whether the result is a big mess remains to 
> be argued :-). But this is not the point. As i said a 
> _NET_WM_FRAME_GEOMETRY would be a hint; the window manager still could 
> adjust it if e.g. the window would be positioned under a taskbar or such. 
> But it should at least try to do what the client asks.

The point is that some things are not known to the client, and the
client can't provide reasonable hints for that reason. A client can
reasonably provide a semantic hint - "this is a toolbar" - because
that is a hint the client has best knowledge of.

A client does not have good knowledge of the appropriate size of
window + frame. The client knows:

 - min size
 - max size
 - base size
 - resize increments
 - a "nice default size"

The client has no special information to give the WM about window +
frame size. The WM has the nice default size, the min size, the max
size; if it wants to compute a nice window + frame size from that, it
can do just as well as the client.

I believe even the current PPosition hint from the ICCCM is wrong, and
my WM ignores it; I don't think clients have any business specifying
their position, they have no basis for doing so. (With the exception
of -geometry, handled by USPosition.)

Anyhow - let's make this discussion more concrete. What is the use
case where you want to do this? And what special client-side knowledge
does your app have that results in better usability by providing the
window + frame size from the client side?

Havoc