Re: Initial window placement

[Philipp Lohmann <Philipp Lohmann Sun COM>]

Am 16.08.01, 19:53:13, schrieb Havoc Pennington <hp redhat com> zum Thema 
Re: Initial window placement:

> 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:

> 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.

But this is true only for top level windows. A client could very well 
decide where it wants its dialogues if it knows about where its top level 
window is.

> > 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?

That -geometry never does what i want it to: place a window where i want 
it. It could if it would set a hint to the window manager about the frame 
geometry. For the user there is no frame and client window, there is just 
a decorated window.

> 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. ;-)

Tell that your favorite IT department. They will pretty much install what 
they want, not what you want.

> 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?

I like concrete :-). The problem is this: a document is open. User wants 
a search/replace dialogue to open. Ideally this dialogue should not hide 
any portion of the document when mapped (if the sizes allow for that, 
that is). So to have it at a nice starting position i'd like to put it 
adjacent to the document window and because that would look nice the 
decorations should not overlap.

If the size of the document does not allow for the dialogue to be next to 
it (which is likely, people tend to maximize  the documents they edit or 
at least make them large), then the dialogue should at least not hide the 
cursor positition and a region around it as large as possible.

After that the user will do search operations repeatedly - the document 
scrolls to the new position. But this position should be visible, so the 
dialogue must be avoided. For that to work you need to know where exactly 
the dialogue is INCLUDING the decorations (else the decoration may hide 
the cursor position). This all gets more tedious since the user may want 
to place the dialogue where he wants and moving the dialogue as far away 
as possible is not an option (especially if you think of XINERAMA :-), it 
might end up on another screen).

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.

Regards, Philipp