Opened 13 years ago
Last modified 9 years ago
#2570 assigned defect
gdk window obscured events don't always happen
Reported by: | dsd | Owned by: | erikos |
---|---|---|---|
Priority: | Normal | Milestone: | Unspecified |
Component: | Sugar | Version: | 0.92.x |
Severity: | Unspecified | Keywords: | 11.3.0, olpc-test |
Cc: | manuq | Distribution/OS: | Unspecified |
Bug Status: | Unconfirmed |
Description
Somewhere after Sugar-0.84 (currently reproduced on 0.90.3), activities stopped receiving gtk.gdk.VISIBILITY_FULLY_OBSCURED events on their Activity objects when another activity is switched to or when the user changes to home/group/neighbourhood view.
test case is something like:
self.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK) self.connect("visibility-notify-event", self._visibility_changed) def _visibility_changed(self, widget, event): print "VISIBILITY", event.state
On 0.84, you got a VISIBILITY_FULLY_OBSCURED event when switching to another view or activity. On 0.90, nothing.
Record needs this to switch off the camera/microphone when the activity is no longer active.
Attachments (2)
Change History (17)
comment:1 Changed 12 years ago by dsd
- Keywords 11.2.0 added
comment:2 Changed 12 years ago by erikos
- Owner set to erikos
- Status changed from new to assigned
comment:3 follow-up: ↓ 5 Changed 12 years ago by manuq
comment:4 Changed 12 years ago by erikos
- Keywords 11.3.0 added; 11.2.0 removed
Interesting, those signals seem to be buffered. No idea why, though :/ Would be great to figure out.
comment:5 in reply to: ↑ 3 Changed 12 years ago by sascha_silbe
Replying to manuq:
1309389746.771466 DEBUG root: Quitting the activity process. 1309389746.775499 DEBUG root: _cleanup_temp_files VISIBILITY <enum GDK_VISIBILITY_PARTIAL of type GdkVisibilityState>
You seem to be mixing logging output and print statements. There's a good chance this is causing your perceived delay (stdout vs. stderr and / or different buffers that get flushed at different times). Try using logging.debug() instead of print for your debug output.
comment:6 follow-up: ↓ 7 Changed 12 years ago by dsd
- Cc manuq added
Manu, would be great if you could spend a few minutes rechecking this with Sascha's suggestion above.
comment:7 in reply to: ↑ 6 Changed 12 years ago by erikos
Replying to dsd:
Manu, would be great if you could spend a few minutes rechecking this with Sascha's suggestion above.
Ufff, who did this testcase....:) Of course it works when we use debug.
comment:8 Changed 12 years ago by erikos
Manu can you quickly do a test as well if the issue is gone when using the logger instead of the print. If it works for you, we can close this ticket and Record has no excuse anymore to hold on the devices ;p
comment:9 Changed 12 years ago by dsd
- Summary changed from gdk window obscured events no longer happen to gdk window obscured events don't always happen
- Version changed from 0.90.x to 0.92.x
OK, so I was being stupid all along. Confirmed. But there is still a regression here. Test case:
Modify record as follows:
self.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK) self.connect("visibility-notify-event", self._visibility_changed) def _visibility_changed(self, widget, event): logging.warn("VISIBILITY %r", event.state)
Launch terminal
Launch Record - it launches with UNOBSCURED visibility - great.
Press F1 to change to neighborhood view. Record gets no event.
Open frame, switch to Terminal activity. Record still gets no event.
comment:10 Changed 12 years ago by manuq
Finally, I added the logging line and did the tests, first I did a simpler one for comparison:
- I started new Record, and closed it - I have the following visibilities: UNOBSCURED, PARTIAL, UNOBSCURED (this is because of the activity's description screen on close)
- I did as Daniel's test above - I've got the following visibilities: UNOBSCURED, PARTIAL, UNOBSCURED, PARTIAL, UNOBSCURED. Between the first two, I went to the neighborhood and to terminal, the next "partial" is because of the frame while switching to Record again, and the last visibilities are the same as the first test above, produced by the description screen on close.
Changed 12 years ago by manuq
Changed 12 years ago by manuq
comment:11 Changed 12 years ago by manuq
- Keywords olpc-test added
comment:12 Changed 12 years ago by erikos
Manu, this does mean we can get the code back that released the camera/mic when we switch to another activity? If simple, maybe you can create a patch and we can test with this.
comment:13 Changed 12 years ago by dsd
I already "fixed" Record. But Sugar is still somewhat broken as per my comment above (which Manu has just confirmed).
Also, my Record fix doesn't work right, because Sugar doesn't wait for the old process to finish releasing resources before activating the new one (and there's no way of signalling this). Not sure how this is supposed to work, or how it worked before.
comment:14 Changed 12 years ago by manuq
Simon, as Daniel said, I just confirmed the test case of the failure, there is no gtk.gdk.VISIBILITY_FULLY_OBSCURED event in my logs.
Record should get the gtk.gdk.VISIBILITY_FULLY_OBSCURED event if going to neighborhood view or switching to another activity.
comment:15 Changed 9 years ago by walter
- Priority changed from Unspecified by Maintainer to Normal
I tested the callback code above in the HelloWorld activity.
It seems that the callback is not called until the activity is closed. Watching the log of the activity, print is not called while changing activities. After closing the, all the prints are at the bottom of the log.
I got the following prints in the log: GDK_VISIBILITY_PARTIAL when the frame got visible, GDK_VISIBILITY_FULLY_OBSCURED when another activity got selected, and GDK_VISIBILITY_UNOBSCURED when the helloworld activity got selected back.