Re: resizing with gravity

[Russell Shaw <rjshaw netspace net au>]

Sasha Vasko wrote:
> Dan Winship wrote:
>
> > Yes, that's why I suggested the text about "Clients SHOULD always
> > include x and y in this case", because then it works regardless of how
> > the WM behaves. IOW, we declare the disputed functionality to be
> > deprecated and essentially undefined, since as you note, it is unlikely
> > that we will ever reach a state where all WMs implement it the same.
>
> That is a HORRIBLE!!! idea. Applications should never ever try to fiddle 
> with its position after initial placement. Position of the window on 
> screen is entirely responcibility of the window manager. There is no 
> reliable way for clients to ever figure out how exactly configure 
> requests are handled by window managers as window managers may employ 
> all kinds of custom placement policies, such as tiling, tabbing, avoid 
> cover, screen area restrictions and so forth.

An X app might open a grid of top-level windows, and rearrange them
as more windows are added or removed.

Such apps may exist primarily for embedded systems without a window
manager, but it is still useful to be able to use those apps where
a WM is running. In that case, the WM must have a policy setting that
allows the app to run as designed, or in a semi-managed way.

> In fact I suggest that we explicitely state the opposite: "Clients MUST 
> NEVER EVER include x and y in ConfigureRequests" Although most smart and 
> responsibly implemented clients already know that, and those who suffer 
> from delusion of grandeur, will always ignore such statements anyways, 
> so really there is no point in amending specs.
>
> Clients should only be able to change size of the top level windows and 
> then let window managers reposition them in accordance to its policies. 
> Which is were gravity comes into play ( from WM_NORMAL_HINTS ). And 
> again, this gravity should be choosen by clients based on user request 
> of initial geometry, and should not be mangled by the client itself.

Window managers have no place in dictating how an application manages
its top-level windows.

Window managers exist solely for the purpose of the *user* to specify
how top-level windows should be managed.

If a user wants to disable automatic window management for one app, then
so be it. A WM that doesn't allow this is broken.

> Simple example: a terminal application.
> You start it like so: xterm -geometry 100x25-0-0
>
> Terminal then gets placed at the bottom-right corner of the screen. Now 
> what would happen if user decided to change font size in it ? Do you 
> really want xterm to try and calculate what its x and y should be for 
> ConfigureRequest??? I don't. And I doubt that xterm developers differ 
> with me on that one.

If an application was designed with the assumption that a WM is always
running, then the offset calculation isn't required.

If the app was designed assuming a WM may not be present for a significant
time, then i *would* expect the app to do the offset calculation.

> You may want to go back in time (around 2000/2001) and re-read ML 
> archives on this particular topic.

On some GUI lists, the developers object to patches because they say
"most users don't need it" or "most users don't do it that way" etc.

If each feature of a toolkit satisfied 90% of users (and dissatisfied
10% of users), then after 21 features, 90% of users would object to some
feature.

This is why users and developers doing non-trivial stuff find GUI on linux
crap compared to some proprietory systems.

The proper way to do this stuff is to have it easy to understand (adequate
documentation and help systems), and have every parameter easily configurable
by all users.