Re: [PATCH] maximize-horizontally/vertically behaviour change + fix

[Jeremy Hankins <nowan nowan org>]

Christopher Roy Bratusek <zanghar freenet de> writes:
> Am Sat, 12 Dec 2009 14:43:32 +0900 (JST)
> schrieb Teika Kazura <teika lavabit com>:
>> On Tue, 8 Dec 2009 15:47:50 +0100, Christopher Roy Bratusek wrote:
>> > Am Tue, 08 Dec 2009 13:55:03 +0900 (JST)
>> > schrieb Teika Kazura <teika lavabit com>:
>> >
>> >> The change is done in commit 6071da, by Jeremy. Let's wait for
>> >> him. (Well, he seems to be busy. ;)
>> >
>> > Hmm... nope, the problem exists for years now, see:
>> >
>> > https://bugzilla.gnome.org/show_bug.cgi?id=104591> 
>> Oops, sorry Jeremy.

No prob.  ;)

> By restart, that's why altering wm-spec.jl is necessary, plus: the hunk
> is fully correct if you ask me.

Hmm...  If I understand what your patch does (and I'm not positive I do,
and I haven't yet tried applying your patch) this may not be a complete
fix.  The normal maximize func decides the maximized state by comparing
the area of the resulting window.  So starting with:

 ---
| A |
 ---
        -------
       |   B   |
        -------

Where A and B are in corners and B is ignored.  When A is maximized that
could become:

 --------------
|      A       |
|              |
 --------------|
       |   B   |
        -------

Or:

 ------
|      |
|  A   |
|      |-------
|      |   B   |
 --------------

Which is chosen depends on whether the area of A is greater for option
#1 or option #2.

But if you maximize vertically and then horizontally you're explicitly
choosing option #2, whether or not that option maximizes the area of A.
So in cases where option #1 maximizes A I'd expect that you wouldn't get
the behavior that you're looking for.

But as I said, I haven't tested it (and wont be able to today), so I may
be missing something.

-- 
Jeremy Hankins <nowan nowan org>