Revision 1bc4d7f1a38917e6d2bf837a660f5f498a29ea0c

Luke Schierer lschiere at pidgin.im
Sun Sep 2 23:52:06 EDT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 2, 2007, at 23:10 EDT, John Bailey wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> khc at pidgin.im wrote:
>> -----------------------------------------------------------------
>> Revision: 1bc4d7f1a38917e6d2bf837a660f5f498a29ea0c
>> Ancestor: cccc7902a8993aaa6b6ef10c1fb9480763055463
>> Author: khc at pidgin.im
>> Date: 2007-09-03T02:19:10
>> Branch: im.pidgin.pidgin
>>
>> Modified files:
>>         pidgin/gtkconv.c
>>
>> ChangeLog:
>>
>> Fixes #2340, remember size/position separately for more places
>
> I'm not meaning to single Ka-Hing out here, as he is not the only  
> developer who
> has committed code to Pidgin that does this.  I apologize in  
> advance for the
> appearance that I am singling out any specific person, as this is  
> not my intent.
>
> My intent here is to ask the following:  What is going on with the  
> recent trend
> of committing code that tramples over the responsibilities of the  
> window manager?
>
> 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.
>
> 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.
>
> I've said it before, and I'll say it again--remembering position is  
> the window
> manager's job, not the application's.  I humbly suggest that if  
> we're going to
> become a window manager in addition to being an IM client, then we  
> should drop
> support for GTK+ and X11 entirely and rewrite Pidgin for Windows  
> only by using
> MFC, where the broken concept of making the application manage  
> windows always
> has been and probably always will be the case.  Catering to  
> criminally braindead
> window managers is not something we should ever consider doing, no  
> matter how
> many people use said braindead window management software.
>
> Again, I apologize for the appearance of singling any developer  
> out, as this was
> not my intention.  I also apologize if this message comes across as  
> overly
> condescending or hostile, but I feel that changes like these, those  
> that trample
> over the responsibility of other software which is supposed to  
> explicitly
> fulfill a specific function, are inherently bad and should never  
> happen.
>
> John

I spoke against this when it was first implemented (the most recent  
time, and I think every time it has been brought up but not  
implemented in the past as well).  My reasoning was simple:  It  
annoys me, and my window manager (fvwm) does a better job of doing  
what I want (even with no special casing for Pidgin, which I could do  
to make it behave even better), than anything we could (reasonably) do.

Remember where the last window was optimizes for 2 use cases.  One,  
apparently very common in Windows, is to have multiple screens, with  
the 0,0 position either being entirely invisible or on the lesser  
used screen.  The other is the case of a single window with Last  
Window placement.  If you use *any other* desktop setup (case #1) or  
*any other* window placement option (case #2) remembering the last  
placement is almost certainly  one of the *worst* behaviors we could  
have.

On top of this, I second everything John wrote.  And like him, I  
would never even *dream* of trying to single out khc.  Lord knows  
I've backed my own share of (in retrospect) crazy ideas.

luke



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iD8DBQFG24TnUsDanPbyGdkRAn5oAJ9K3bn2tZe8mB4fNriCbwHqISUEzQCgqYqL
sgd6D5dJ5/44y166x9ctBTs=
=L2wY
-----END PGP SIGNATURE-----




More information about the Devel mailing list