QLabel kills our KMessageBoxes (and others)

[Lubos Lunak]

On čt 25. října 2007, Thomas Zander wrote:
> Lubos Lunak wrote:
> > On Friday 19 of October 2007, Thomas Zander wrote:
> > > Why is the rule to never query the client a hard rule?
> >
> >  It is not a hard rule. It's just not a very good idea to have the WM
> > blocked somewhere deep in the code waiting on a client that may take ages
> > to respond.
>
> Why would it be more blocking then 'normal' resizing?

 Because right now it's like this:
- Client (an app with a window) decides about its minimum size, sets a 
property (well, simply some data attached to the window, in this case a 
specifically named one) to this value.
- KWin detects the change, reads the property, saves it.
- Now, when the user tries to resize the window to some specific size, KWin 
does simply compares the requested size with the saved minimum size, i.e. 
something along the lines of "if (requested_size < minimum_size) 
bail_out();".

 If the client blocks and doesn't react to anything for a while, no problem - 
KWin knows the value of the minimum size. However, if it had to query, that 
minimum_size above would become minimum_size(), which would be a message 
roundtrip to the client. If the client doesn't respond, KWin is stuck.

> The solution that you can use is that the window manager sends a message to
> the client that supports width-for-height informing him about the new
> width. And keeps on sending such messages as long as the user resizes the
> window. All of this is completely asynchronous (and the way that X11
> already works, no change there).
> The difference is that the window can respond with a suggested height for
> the user-selected width after which the WM resizes the window.

 It's the window manager that does the resizing, and therefore a window 
responding after the resize is too late - KWin needs to know it at the time 
of the resize, otherwise there will be problems (size jumping back after KWin 
finds out it wasn't an allowed size, or even apps crashing because of "bad" 
size even though the wm spec actually allows the WM to set any size).

 Indeed, KWin could query in an asynchronous way and do the resize only after 
a reply comes back, but that's still a problem with completely stuck apps, 
not a very nice user experience with slowly responding apps, and cutting the 
KWin resizing code in two halves. I'm not saying it can't be done, but 
currently it doesn't seem to be worth the effort.

> >  Nothing is perfect, and the gain/effort ratio may put more weight on the
> > other scale. Trying something almost correct first seems like a better
> > option to me.
>
> Which is fair enough, you are the maintainer after all.
> I just want to be sure we both understand each other. And currently I'm
> thinking we don't since the perfect solution is actually completely
> possible without any disadvantages that I know of.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz