#98 Focus stealing prevention make example 14 hang for -dev xwin

closed-out-of-date
nobody
None
5
2011-09-16
2010-09-12
Alan W. Irwin
No

If I run x14c like

examples/c/x14c -dev whatever

on a KDE desktop that is set up with the high or extreme setting to prevent focus stealing (via System Settings ==> Window Behavior ==> Window Behavior ==> Focus Stealing Prevention Level), it works fine for -dev xcairo, -dev qtwidget, and even -dev tk (once I click on the window generated by x14c to give that window focus), but hangs (with top giving 100 per cent of the cpu to x14c indefinitely) for -dev xwin regardless of clicking on the window. If I use -debug, I get one expose event before attempting to click on the window, but then it hangs with two black screens (one with a vertical red line through it) until I hit ctrl-C.

Demo of multiple output streams via the xwin driver.
Running with the second stream as slave to the first.

ExposeEH: x = 92, y = 0, width = 408, height = 410, count = 0, pending
= 0
^C

If I set focus stealing prevention to none, low, or medium, all is well with -dev xwin.

In sum it appears with x14c (but no other example) that -dev xwin (but no other device including -dev tk) requires focus stealing (perhaps for the second window?) from the start or otherwise it hangs.

Discussion

  • Andrew Ross
    Andrew Ross
    2011-09-15

    Unable to reproduce this with kde 4.6.2 on Ubuntu.

     
  • Andrew Ross
    Andrew Ross
    2011-09-15

    • status: open --> open-works-for-me
     
  • Alan W. Irwin
    Alan W. Irwin
    2011-09-16

    • status: open-works-for-me --> closed-out-of-date
     
  • Alan W. Irwin
    Alan W. Irwin
    2011-09-16

    Even though I am still running a really dated KDE (4.4.5) I can no longer replicate this issue myself as well. So I assume there was a problem with my X stack when I reported this bug that has now been resolved. Therefore, I will close this as out of date.