25 Jan
2013
25 Jan
'13
7:34 a.m.
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