Re: Initial window placement

[Sasha_Vasko osca state mo us]

> Am 16.08.01, 16:08:18, schrieb <Sasha_Vasko osca state mo us> zum Thema
Re:
> Initial window placement:
>
> > I see wto problem with that approach is:
>
> > 1) Window is likely to get its decorations finalized only after some
time
> > after its initial mapping. For example many applications set its title
> > to be blank initially, and then change it to something usefull right
> away.
> > AS the result, window manager may decorate window in some generic way
at
> > first, and then when title changes, it may recall some presaved
settings,
> > specific for that title, and redecorate the window. As the result,
window
> > will be placed in requested position at first, and then slightly moved,
> > thus defying the purpose.
>
> That is bad practice anyway because it leads to flickering. But even

Bad or not bad, but that is how MOST applications behave. That includes
xterm and all its flavors, all the web browsers, most text editors, etc.
Extremely nasty when it comes to window manager trying to handle initial
mapping gracefully :(

> though: why should the window manager not still value the same frame
> geometry setting ? It could change the client window geometry according

Such update usually happen some time ( maybe very short time ) after
initial
mapping, and is handled same way as regular move/resize/change requests.
So lets say if initially client was assigned a titlebar 20 pixels high,
and frame geometry was requested to be 100x200+10+20, client will be sized
to 100x180 and placed at +10+30. Now client changes its title, and window
managers recognizes this new title to match one of the preset look configs,
that demands to show client without titlebar. So accordigly, window manager
goes about removing titlebar, and since client had gravity of NorthWest it
moves everything to keep upper-left corner of the frame in the same place.
AS the result you get client window at : 100x180+10+20, and overall frame
geometry of 100x180+10+20, which is clearly different from requested.
In that case, if you were to align second window at the bottom of the first
one, and you would get 20 pixels gap inbetween.
 Now window manager updates property and your client triggers the change.
At that moment it has to move second window 20 pixels upwards. But there
are
no way to move window into exact location on the screen.

IN fact that hole thing directly contradicts ICCCM in the way that it
requires window manager to do exactly as client says. Since Window Managers
are rogue warriors and tend to kick clients to its liking, this whole
scheme
will never work. Consider window managers that simply tile all the windows
on screen, without allowing freehand movement, or those that assign them
tabs in a notebook type fashion. You can't just go about telling window
manager what to do. All that you can do is hint it, like "Hey, man, please
align me with this other window of mine, would you please ?" and let
window manager make decisions about how it translates into its policies
and philosophy.

> to the new decoration (again it would be possible to change the frame
> geometry if min/max-width/height did not allow for that.
>
> > 2) If window has been placed according to that property, does window
> > manager has to keep this placement  during the entire lifetime of the
> > window? How should subsequent requests for move/resize be treated?
> > How should changes in theme/look that affect size of the frame
> decorations
> > be treated? How should changes in window gravity be treated ?
>
> > As per (1) if you don't force that placement to entire lifetime of the
> > window, you will not get anything usefull, but if you do so - you run
> > into huge pile of other challenges described in (2).
>
> The initial placement need not be forever, that is why the window manager
> should update the property if it was set (e.g. if the user drags the
> window somewhere else). Move/Size requests could still be treated
> according to ICCCM (including gravity), just the property would be
> updated according to the new frame geometry.
>
> This new property would make a difference from previous behaviour only
> one case: initial placement when mapping the window. After that it is an
> additional source of information for the client.
>
> Your concern seems to be what happens, if the client changes this
> property after it is mapped. First it is debatable whether that should be

No, not this property. My concern is that client will change some other
property that affects frame size shortly after initial mapping.

> allowed. If it were (it is like a move/size request) then again i see no
> real problem: the window manager can easily recalculate the coordinates
> to a normal move/resize request including gravity since he is the one who
> has all information necessary to do so.
>
> Regards, Philipp

Cheers
Sasha