On Thursday 24 January 2013 00:54:50 Slávek Banko wrote:
Hi all,
I have a problem to discuss:
Before long time I prepared a patch, which is included in the commit 9e3f8a7f. It was based on a completely broken patch for KDE4 - commit c24ea2b4. Our patch works correctly,
actually it doesn't as I figured out while working on the new patch: a remote libre office window is marked as local.
but contains one potential risk - is dependent on DNS => on the network delays.
First question is, how big is this risk, because we have a patch incorporated nearly a year ago and no problems observed. The fact is that if the user will have a problem with the network, probably will not even be able to open a remote window. However, this risk actually exists.
this is unrelated to remote windows. The problem would show itself also for local windows and that is in fact not such an unlikely situation. While coming from suspend my system takes about half a minute to minute to reconfigure the network. This would be the critical interval in which one is not allowed to open libre office.
Therefore, I have a question: What next? Martin designed a simple revert our patch seems to me inappropriate. The second option is to leave our patch unchanged and also a risk. Third, that someone remakes patch to not use QtConcurrent (it is beyond my abilities).
third option is IMHO impossible. The interaction of the newly designed classes was highly influenced by what is possible with QtConcurrent. It would need a complete different approach by using the async variant.
As written I suggest to revert the patch as the risk is too high. In KWin we have the requirement to have no blocking call. It's extremely nasty if the compositor is blocked - this means system is frozen. For just window manager it's not as bad. You can no longer interact with windows.
Cheers Martin