Re: frame size hints

[dominik vogt gmx de]

On Sat, Nov 30, 2002 at 09:14:23PM -0500, Havoc Pennington wrote:
> 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.

Well, maybe a big, fat "do not use this feature, it is utterly
broken" with a bit of an explanation would do to.

> > 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).

Yes, of course I have considered this too.  But I still have the
gut feeling that certain toolkits will just request it for all of
their windows because "you can never know".

> > 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

No, don't panic.  We can make fun of many different applications
broken in many different ways at the same time.  No problem ;-)

[snip]
  
> > 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?

Well, for example the problems you see with AWT.  And all the race
conditions between ConfigureRequests and changes in the
WM_NORMAL_HINTS.  And the "legacy vs. ICCCM compliant gravity
handling in ConfigureRequests" problem.

> 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.

Okay, that is really a point that should be considered very
carefully.  I see one advantage we have over the traditional
ConfigureRequest handling.  Without that advantage I would not
even consider such a client message:  we can write the
documentation from scratch and make it so clear that even an idiot
understands how it works.

I agree that the last draft is very complex and bears a lot of
possibilities for misunderstandings.  But if we can describe it in
a way that at least *window manager developers* understand it
correctly, application programmers can just figure it out by trial
and error and still be sure that it works the same on every window
manager.

> 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.

Hey, it was *you* who said "we have to do something because the
AWT folks are whining" and *me* who said "I don't care a bit". :-)

> You won't ever get adequate testing and bug-freeness on a complex
> solution to a rare problem anyway. Witness traditional
> ConfigureRequest handling. ;-)

Yes, because I witnessed it I make such proposals :-)

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, dominik vogt gmx de
Reply-To: dominik vogt gmx de