Re: Initial window placement

[Havoc Pennington <hp redhat com>]

Hi,

I like your concrete example of the search and replace dialog.  In
fact Mozilla annoys me by always centering the search dialog over the
browser window, then centering the found word, resulting in never
being able to see the found word. ;-)

<long digression>

The problem is that if we simply let clients specify the position,
then there's no way to implement the 99%-of-the-time-correct option,
which is that the WM e.g. have a consistent policy of
center-dialog-on-parent or center-dialog-on-screen or the like. 

For example, my WM puts the dialog right under the titlebar of the
parent, along the lines of MacOS X. If a client requests a position
(as most do), I have no way of knowing whether that position is just
"centering the dialog in some slightly different, inconsistent way"
(which I'd like to ignore) or the position genuinely reflects
something useful (e.g. your search and replace dialog).

As the only user of my WM, my preference is to have the 99% of apps
whipped into line, rather than to have the slightly nicer behavior for
search-and-replace in one app.  However, I'd ideally get the
special-casing of search and replace, but also be able to ignore
stupid positioning by clients.

Short answer, a client simply specifying a position does not give the
WM any information about whether it should or should not honor that
position hint. All it does is brute-force assert "as a client, I
believe I know better what the position should be." And I have to
decide in the WM to globally trust or not trust clients on this
point. Empirically, the vast majority of clients are lying about it
and so I ignore them.

To me the solution to this is to transfer the "do not cover the
following area" knowledge from the client to the WM, so the WM can
make a considering-all-information global decision about positioning
the dialog, using the more semantic information that "some area of the
transient parent should not be covered by this dialog." i.e. we need
to collect all relevant info in one place, and then let the WM make a
decision.

I can understand that providing a "do not cover" region for a
particular parent-transient pair sounds a bit complicated. I'm not
sure it's worth the complexity; at the same time, I'm pretty sure that
the price of less complexity will be either inconsistent placement of
99% of everyday dialogs, or disallowing the "do not cover" behavior
for the search dialog.

I guess what the ICCCM authors envisioned was the clients would only
use PPosition appropriately, so that WMs could always honor it; this
was a simple solution that in practice turned out to be wishful
thinking. That's what motivates much of the semantic-hint emphasis of
the current WM spec.

I hope you see the dilemma. Anyhow, in short I think PPosition is kind
of a mistake, and adding the ability to handle the frame in
sizing/positioning fixes one small reason why clients can't do
client-side positioning/sizing correctly, but doesn't really fix the
larger problem.

We have to simply specify who gets to do what, some options are:

 a) client does all sizing/positioning, WM just draws borders, 
    WM might set hints for the client
 b) WM does all sizing/positioning, client must provide relevant
    info for that to the WM via hints
 c) client does all sizing/positioning, subject to constraints
    imposed by the WM such as "you must be onscreen" or whatever

To some extent the status quo situation is to punt this issue and hope
things work, and sometimes they do, but they work 90%, the last 10%
will require a firm decision. Your search-and-replace dialog, or my
attempt to center all dialogs horizontally and snap them to parent
titlebar vertically, are examples of last-10% niceness that can only
be achieved by carefully specifying who will do what when and how.  As
long as we remain agnostic on a/b/c then either your last-10% feature
or mine will not be achievable, and 100% is impossible.

I think b) is sort of the X Window System tradition and the closest to
the intent of the ICCCM and EWMH. I believe we should go with it. So
to correct errors in sizing/positioning, such as your search dialog,
the correct method is to provide additional info to the WM via
additional hints, and let the WM make a global decision.

</long digression>

Anyhow, that's the big-picture global view of what size/position hints
should be about, and I think we do need to keep them coherent in terms
of choosing a), b), c) and sticking to it, or the last-10% will never
be made to work under X.

> So the least i would like to have to implement this is information about 
> the real frame geometry. It would be even better if i could place the 
> dialogue out of the way in the beginning.

I don't have any objection to a hint set by the WM on the client
window containing the current bounding box of the frame. It's
occasionally useful to have, while not really allowing clients to try
to do window management.

Havoc