Re: Various comments, mostly on Implementation Notes

[Sasha_Vasko osca state mo us]

>Sasha_Vasko@osca.state.mo.us writes:
>|Windows in question are those that need to use different gravity.
>|You can't really force all GTK clients to use Static gravity, and at
>|the same time, most of them will want to save their position for later
use.
>
>Thanks, I see the problem now.
>
>Wouldn't it be possible to initially map the window with Static
>gravity, then change to whatever is required after the first map-notify
>event has arrived?

AFAIK you cannot change your gravity unless you unmap your window, change
hints
and then map it back. And that does not really do you any good.

>But I'm not sure why applications need to do this, isn't it better to
>let the window manager handle _all_ window placement?

Yes, that is how it is supposed to be, and it is explicitely stated in
ICCCM
that clients cannot choose a location - they can only hint WM about
location.
But with all this MSWindowish trends around, ppl started writing apps that
try to do what they should not - try to manage its exact location.
As the result all kinds of bad things happen - like windows slide down over
time
since they don't take into consideration or miscalculate frame size.
It does happen under some WMs and never under others. As the result users
become very confused, and as a general rule - start blaming WM developers.

The most frustrating thing about it is that there has always been away to
have app start in some preset position:  -g or -geometry command line
option.
But all this new cool apps tend to ignore this standard completely and
simply
do not support this option, and try to save their position in config files.
As the result WM looses control over initial placement completely, since it
cannot brutally disregard initial placement completely, since it will
damage
"good" apps, and it is not able to restore window location by itself since
window's own initial placement will override it. If ppl could at least use
PPosition when trying to restore placement saved from last session - that
would be much more easier.

>The only reason given for this so far is so that applications can place
>themselves at their most recent position. The window manager
>could/should be responsible for this (at the direction of the user).

>I've tried to implement something like this in sawfish, but it's
>limited by the lack of a reliable way to identify which windows are the
>`same' as previously opened windows. Maybe if we addressed this issue
>in the wm-spec, then it would not be necessary for applications to care
>about saving and restoring their position..?

Yeah like force everybody to use -g|-geometry option, or specify
PPosition otherwise (if placement is restored from last saved session).

>|
>|rxvt -g -100-100
>|and then change font size in it: Shift+Gray+, Shift+Gray-

>I can't work out how to get it to change size, what's Shift+Gray+ ?

Hold 'Shift' key and press '+'(or'-') on the NumPad (repeatedly).
right-bottom corner should stay put. ( you may need to toggle NumLock
first).

(both eterm and aterm should work like that as well, but of course it all
depends on your terminfo and other keyboard config garbage.)

That will test if you honor gravity after initial placement.

To see if you actually place it correctly try:
rxvt -g -0-0 ; rxvt -g -0+0 ; rxvt -g +0-0 ; rxvt -g +0+0
in all the cases your entire frame should be visible and be placed next to
the screen edges.

( Of course that will be a reall test only if aswfish allows you to place
windows
off-screen )

>    John

Sasha Vasko