Re: frame size hints
- From: Havoc Pennington <hp redhat com>
- To: wm-spec-list gnome org
- Subject: Re: frame size hints
- Date: Sat, 30 Nov 2002 21:14:23 -0500
On Sat, Nov 30, 2002 at 11:59:53PM +0100, dominik vogt gmx de wrote:
> Yes, I thought of PropertyNotify too. But I would like to make it
> as inconvenient as possible to discourage using that feature.
It just means people are going to screw it up, and it's just going to
cause us headaches because we'll get the bug reports. I say KISS.
> The client should have to ask every time and not dump the workload
> on the window manager. I find it stupid to provide a broken
> property on tons of windows just to make a few broken applications
> happy. That would only encourage other people using it.
We could say that the property is only updated if you request it
(e.g. by mapping the window with the property already present).
> Hm, in fvwm we ignore configure requests on shaded windows
> because it would lead to a ConfigureNotify on the client window.
> Some apps (for example xemacs), look at the size of their frame
> window and answer with a ConfigureRequest with a huge height in
> response (height of 1 pixel - menubar height - toolbar height etc.
> = -something which is cast to an unsigned short).
Now *that* is broken - we can't make fun of Java anymore. ;-) I
thought GNU Emacs was bad with its "send a new configure request every
time it gets configure notify" junk.
In any case, I would consider what to do with configure request on a
shaded window to be a quality-of-implementation question, not a
> Well, this problem can be solved with an enhancement of the custom
> move/resize message:
What current bugs in real apps/toolkits does this proposal fix?
I'm pretty cautious about this proposal, because people already don't
understand how configure requests and gravity and all that work, and
nearly all WMs have historically gotten it wrong.
It's like the "why X is not our ideal window system" paper - not sure
some of the criticisms in there are even valid, because some bugs are
best left unfixed when the solution is complicated, the problem rarely
happens in practice, and the problem is low-impact when it happens.
You won't ever get adequate testing and bug-freeness on a complex
solution to a rare problem anyway. Witness traditional
ConfigureRequest handling. ;-)
] [Thread Prev