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