[comp.windows.x] ICCCM, window manager frames, random walks

moraes@cs.toronto.edu (Mark Moraes) (02/02/90)

toml@ninja.Solbourne.COM (Tom LaStrange) writes:
>I haven't tried XPostit but I think I know what's going on.  XPostit is 
>saving the location of its windows.  That's fine except when the whole mess
>restarts, twm is going to place its decoration at the locations saved
>by XPostit, hence moving the windows by the titlebar height.  This is 
>exactly what the ICCCM says that the window manager should do.

This ICCCM rule means that when poor old xplaces prints out the
position of windows, it also gets second guessed by the window
manager.  So after working its way down the window tree to find the
top level window, is xplaces now supposed to assume that the frame is
the root-window child that is the root of the subtree in which the
toplevel window is?  Or is the operative phrase "tough luck"?

Our users consider to be the obvious behaviour to be "I put that
window there -- the window manager should darn well leave it there")
Ever tried "But ICCCM says that's how it should be" on an annoyed user
(well, syshack actually) who has spent fifteen minutes iterating with
twm and xplaces to get the same position of his windows that he had in
R3?  Worse, you change the font or titlebar height, and your windows
move again.

I'm sure there's a good reason for this ICCCM rule.  Anyone care to
enlighten us what that reason is?  What problems does a rule like
"don't move the users windows around unless the user moves them" have?

Thanks.
	Mark