Revision 1bc4d7f1a38917e6d2bf837a660f5f498a29ea0c

[Ethan Blanton]

Sean Egan spake unto us the following wisdom:
> > I am a firm believer, as I'm sure Ethan and Luke are as well, that the
> > remembering of window positions and the placement of windows at those positions
> > is the responsibility of the window manager.  This is a view that Pidgin, as a
> > project, has held for as long as I can remember.
> 
> I just did this because I needed to re-factor the conversation sizing
> code, and it was easy enough to implement this widely and long
> requested feature. This is another feature request that doesn't affect
> me either way, implemented because it was asked for so much, and will
> now defend to my death ;).
> 
> Questions:
> - Where are the "responsibilities of the window manager" specified?

I don't think this is an issue of standards, but reasonable division
of labor.  It's stupid to implement window management code in every
application, when there is a dedicated piece of software which does
just this, and nothing else.

> - Why is it ok to save and restore the position of the buddy list but
> not the conversations?

If this is seriously a show-stopper, I would come down saying that
it's not OK to save either one, and we should remove the buddy list
position code.  That said, I do in fact believe that the buddy list is
more reasonable -- because a) there is only one buddy list, and b) it
is not transient, as are conversations.

> - Why is it ok to save and restore window dimensions?

Because, in this case, the application -really does- know more about
the situation than the window manager does.  This is really what the
whole argument comes down to -- it's very hard (unreasonable, really)
for the application to make an intelligent decision about window
management, because it doesn't know about the state of the other
windows on the display.  The window manager does, however, and can
thus do something more reasonable with the window which is being newly
mapped.  In the case of size, the argument is opposite; the window
manager doesn't know anything about what's going to go in the window,
so how could it size it reasonably?  It seems to me that the very best
situation is for the application to inform the window manager of the
desired window size, so that the wm might place it intelligently
taking this into consideration, and the window manager then places the
window in a reasonable configuration with respect to other windows on
the display.

> - If positioning the window is the responsibility of the window
> manager, why does ICCCM even *allow* you to request a position?

Because there are rare instances where it actually matters.  Pidgin is
not one of them.  Session restoration is one such instance.  There may
be other instances where application-requested positions make sense,
but I can't think of any off the top of my head. The most common abuse
I can think of is splash screens, and if one allows that splash
screens are reasonable at all, I guess they're a good reason.
Personally, I just find them annoying.

> - If your window manager is so smart, why doesn't it just ignore the
> request to position?

This is, of course, simple to do:

Style Pidgin !UsePPosition

However, this is really a stupid solution; one should not have to turn
an established mechanism with one or more reasonable use-cases
(e.g., session restoration) off because an
application abuses it.  Similarly, the fact that it *can* be turned
off should not be used in logic defending the application's abuse.

> > Remembering the position of the window and requesting it again tramples over any
> > window manager that actually does its job (Read: fvwm and similar, which
> > actually *manage* windows).  It also tramples over intelligent window management
> > schemes by making a new window be created at a position that is no longer
> > relevant in the placement scheme.
> 
> It doesn't 'trample' over anything. All we're doing is *hinting* at
> the window manager "this might be a good place to put us." Window
> managers that "actually do their job" are free to ignore this, and in
> fact the documentation for gtk_window_move in fact states that most
> window managers will:

This is false logic, for the above reasons.  The window manager has no
way of knowing why you hinted it; the specification is not that
explicit.  (The standard does allow for "user specified" position,
where the answer is obvious -- if the user asked for it, allow it.)
It is reasonable of the window manager to expect that, if the
application is asking for it, it must know something important by way
of some mechanism *other* than the disposition of windows on the
display.

Applications doing stupid things (like this) with the placement hint
basically make it useless for any situations where it *would* be
appropriate.  _That_ is the fundamental reason that I oppose this
behavior.

>   "Window managers are free to ignore this; most window managers
>    ignore requests for initial window positions (instead using a
>    user-defined placement algorithm) and honor requests after the
>    window has already been shown."
> 
> You're correct that this feature caters to naive, un-configurable
> window managers (you know, like the ones 99% of Pidgin users are using
> ;) ), but those who *are* using using super-configurable, scriptable,
> high-end window managers are the same people who can easily override
> it.

We SHOULD NOT allow broken logic like this to dictate our development
decisions.  There are two kinds of "stupid users" arguments which I
find odious, this is one of the two:

  1) "<X> is too hard for stupid users, even though clueful users
     may want it.  We should remove <X>."
  2) "<X> is convenient for stupid users, and even though it's
     obviously wrong, clueful users can work around it in some way.
     We should support <X>."

In the former case, the correct solution is to either obviate the
problem (something I feel we have had some moderate success in doing,
in Pidgin, with you (Sean) at the forefront) or simply recognize that
stpuid users are going to be confused, if that cannot be done.  For
the second, the correct solution is to go with the technically and
logically correct alternative, and encourage users or the application
which *should* be responsible (in this case, the window manager) to do
the right thing.

I recognize that Windows is sort of a special case in this argument,
because Windows users have no *choice* of using a capable and correct
environment; perhaps Windows should have placement code.  There won't
be any clueful users complaining there, anyway.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20070903/5a8ec02c/attachment.sig>