[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RP] the end to all resize-loop problems
From: |
Shawn |
Subject: |
Re: [RP] the end to all resize-loop problems |
Date: |
Fri Jan 25 02:05:01 2002 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
Jonathan Walther <address@hidden> writes:
> On Thu, Jan 24, 2002 at 07:12:19PM -0800, Shawn wrote:
> >Actually, we would still need the "special case" handling for
> >transient windows because they ARE a special case. If we didn't
> >recognize them, then the first time ratpoison maximized them, they
> >would take up the whole screen.
>
> Good point. I stand corrected.
>
> >Its not my problem if someone else's software is junk. It IS my
> >problem if ratpoison busts, though. A program might behave abnormally
>
> So you need to build in a resize-loop detector. You have to store every
> windows last two resize requests, and if they are the same, kill it?
Ryan and I thought about this for a while. There doesn't seem to be
any way to reliably detect it that isn't hacky. You'd have to store
the last 2 plus a time stamp since it could issue 1 at time, t, then
after the user frobbed the program it could issue another one at time,
t+x. There's no reliable way to destinguish it. The ICCCM explicitly
says programs should not try to resize themselves after the WM lays
down the law:
,----
| The response of the client to being resized should be to accept the
| size it has been given and to do its best with it. Clients must not
| respond to being resized by attempting to resize themselves to a
| better size. If the size is impossible to work with, clients are free
| to request to change to the Iconic state.
`----
I don't want to put hacky heuristics to detect infinite resize
looping. Its not the responsibility if Junk Software X sucks. Software
that resizes itself infinitely obviously don't share the philosophy of
ratpoison and should be avoided lest one becomes corrupted.