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

[Teika Kazura <teika lavabit com>]

On Sun, 13 Dec 2009 13:35:46 -0600, Jeremy Hankins wrote:
>  ---
> | A |
>  ---
>         -------
>        |   B   |
>         -------
>  ->
>  --------------
> |      A       |
> |              |
>  --------------|
>        |   B   |
>         -------
> Or:
>  ------
> |      |
> |  A   |
> |      |-------
> |      |   B   |
>  --------------

True. There's no natural way to choose which. So, if you want the
latter case, the the buttom border of *un* max'd window A has to be
well below.

If the patch brings what Chris wants, then in fact it forces the
latter, and bans the former case, so it's not the fix.

On Sat, 12 Dec 2009 07:46:59 +0100, Christopher Roy Bratusek wrote:
> MAX_HORZ + MAX_VERT != MAX

I don't agree with this logic that it solves the Chris' problem. If A
is *not* max'd horiz, then A does not bump to B:
 _
| |
|A|  -----
| | |  B  |
 -   -----

So what Chris really needs must be both horiz and vert max, isn't it?

But again:
> MAX_HORZ + MAX_VERT != MAX
the patch submitter in bugzilla says the above inequality is
correct in ewmh, and Sawfish is wrong, so we have to consider it.
(I failed to understand the related ewmh part. ;)

Anyway, if what Chris wants can be done correctly if it's done
interactively (= by human operation, with clicking max button or
pressing a key), and not by matcher or history code, then there're two
separate problems; matcher/history part needs rework.

Chris refers to toggle variants. My impression is that:
* max-vert/horiz are functions, and maybe adding "#:key strict" solves.
  If strict is non-nil, then horiz/vert are exclusive to each other.
  wm-spec functions will be able exploit it.
* There're also commands, max-vert/horiz. But user can expect both,
  so we need max-vert/horiz-strict. Distinguish by name.
* Toggles are commands by nature. So distinction by name like above
  solves.

I'm not sure. It's a mere starting point of the discussion.

One thing I care is that there seem to be too many max'n funcs /
commands. At least functions whose only raison d'être is the command
backend can be made obsolete, moved to compat.jl. (Read command
section in info how to do it.)

There're other glitches in max'n. I came across with:

On Tue, 17 Nov 2009 09:44:41 +0100, Janek Kozicki wrote:
> On positive side [of error-handler deletion], after sawfish restart
> a vertically maximized window does not overlap rox-panel *most of
> the time*. I wonder how those two might be connected? I mean - it
> happened once per 10 tries or such.

On Tue, 17 Nov 2009 07:56:53 -0600, Jeremy Hankins wrote:
> Could it have to do with system load or something?  On my tests I
> noticed that my maximized emacs windows were much less likely to overlap
> the panel than maximized xterms.

Jeremy asks:
> What determines the order by which windows are taken up by sawfish?

Rule lacks, and that's the very problem. Furthermore, matcher sets
rules for one by one window. But when maximization is involved, then
first it should set "avoided" property for all windows, and
maximization have to succeed that. I don't know the case of
window-history, but I guess it's similar to matcher.

Regards,
Teika (Teika kazura)