GNOME Bugzilla – Bug 127883
gnopernicus layers freezing desktop
Last modified: 2004-12-22 21:47:04 UTC
using a gnome-2.4 build from 25th Nov 2003. -launch gnopernicus -activate layer '8' -increase/decrease volume of speech repeatedly -increase/decrease pitch of speech repeatedly after a few tries, the desktop is frozen. It is easiest to determine when the freeze occurs when looking at a blinking cursor, as it will stop blinking. Gnopernicus' layers continue to function, but nothing else will. Killing the at-spi-registry daemon unfreezes the desktop.
This should be AP0.
I can reproduce it, BUT it is look that it is not a gnopernicus bug, it is at-spi bug. This happening every time when the layer are used under stress. The focus loseing is caused by the usage of SPI_ALL_WINDOWS flags with NUMLOCK modifier at keyevent listener in at-spi. It seem that it will be solved when the XEvIE will have for all platforms. Have I rigth Bill? This behavier is reported in some other bugs, like 124837 described by Adi. I will file an open in at-spi and I will do dependent this bug to this.
we disagree about this bug. gnopernicus should not be freezing the desktop no matter what at-spi is doing underneath. gnopernicus must be able to handle any at-spi issues with focus/activate event emission while using numpad controls gracefully.
Gnopernicus is not freezing, it doesn't receive events from at-spi. This bug is same as bug 124837. *** This bug has been marked as a duplicate of 124837 ***
I don't think this corresponds to the bug report above. David, you said the rest of the desktop was frozen, not gnopernicus, can you confirm that? IF so, then this is not a duplicate and this bug should be reopened.
As I said initially, gnopernicus' layers remain selectable and changeable. i.e. it's possible to change voice values etc but nothing else.
not a duplicate
David, I take it that you mean you cannot do anything else with the desktop, either with or without gnopernicus. Correct? (at least unless/until you kill gnopernicus)
correct. the only action I can take is to switch to a different layer and/or change layer properties e.g. volume up/volume down, rate increase/rate decrease. In reality of course this ability is useless on it's own.
I still believe that is bug is same as bug 124837. For every key from numeric key pad if the time to execute the associated command is long enough the same effect can be observed. Please read comments for bug 124837 for more details. *** This bug has been marked as a duplicate of 124837 ***
Remus, I have asked on several occasions that this bug not be closed as a dup without consultation.
this bug depends on 124837. It may or may not be a duplicate, but we should not close this bug until either a workaround is found in gnopernicus, or we have investigated 124837 and determined that clients such as gnopernicus cannot influence the behavior of the bug.
I think that what is happenning here is that gnopernicus is getting repeated key events while its callback is being processed. gnopernicus could work around this by ignoring the repeated keys while processing the callback; i.e. ignore duplicate keypresses while processing the "same" key event. I think we've identified the source of the repeated events however, so the symptom you see in gnopernicus should go away. However I still think that it might be important to make sure that gnopernicus callbacks don't "re-enter" if their triggering key gets pressed twice (either because of a key-repeat bug like 124837, or because the user has gotten tired of waiting and pressed the key more than once ;-)
remus and/or david, can you confirm that this problem is no longer visible? remus, what do you think about detecting re-enterancy of a key-event listener (i.e. re-enters while processing the 'same key' as the new event) ? It would mean that gnopernicus would process the events in-order if the user "held down" a gnopernicus control key, which could be useful (in other words gnopernicus would get the repeating events but process them only "as fast as it could" ) but not blocking or growing its stack unnecessarily.
On my current build gnopernicus fails to initialize speech so I can't verify this is fixed yet, perhaps remus can.
This bug cannot be reproduced anymore on my computer. So, I mark it as fixed.
Remus, what do you think of my suggestion that gnopernicus should detect when it re-enters a command? Holding down a repeating key could trigger this kind of problem even now that the at-spi bug is fixed.