Bug 471465
Summary: | gnome-applet-timer never stops pulsing | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Will Woods <wwoods> |
Component: | gnome-applet-timer | Assignee: | Christoph Wickert <christoph.wickert> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 10 | CC: | bugs.michael, christoph.wickert, mclasen, me, piergiorgio.sartor, stickster, zing |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-01-15 03:10:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Sorry I did not respond erlier, I was busy with ambassadors action and Xfce. I will look into the patch later this week I promise. What exactly is your patch supposed to do? For me (still on F9) the applet stops pulsing when I click it once it's finished and I don't see this a change in it's behavior with your patch applied. This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I just upgraded to fc10 from fc9 and I do see the behaviour noted in the bug report. The problem is exactly that in fc10, once the timer finishes and starts pulsing, it doesn't stop pulsing when you click on it. You have to basically remove from panel and re-add it. I really have no idea beyond this why it happens or who's at fault, etc., but I've locally applied the attached patch and it works for me. Update: although the patch allows you to stop the pulsing, the timer is then left in a weird state (blue circle here). Any further timer countdowns that are set don't trigger a notification or sound. Now that I have upgraded to F10 I reproduce the bug. The applet never stops pulsing, even when clicked. Two observations: 1) Clicking the flashing status icon of a "Finished" timer run works around the problem. Don't click away the notification dialog. 2) Modifying controllers/TimerApplet.py to remove the [pynotify related] self._notifier begin() and end() calls makes the problem disappear, too. Yup, something pynotify related here, since the following error occurs on the pynotify.Notification object 'closed' signal: TypeError: _on_notification_closed() takes exactly 3 arguments (4 given) If you choose option 1 from comment #7, you'll need to be quick -- once the notification disappears, you're stuck. It would be super if a smarter PyGTK person looked into this. bug 471496 (libnotify) is what I've run into. Building it without the patch fixes this bug. Alternatively, one needs to "fix" _on_notification_closed to match the changed API. Created attachment 327818 [details]
Patch to fix notify problem
This patch takes care of the pulsing problem and properly resets the timer. But there still seems to be a problem with the notification update, which is supposed to reappear every 60 seconds if the timer's not acknowledged.
I'm not sure whether we can expect a libnotify change, so I'm including the patch here for review and further work.
Created attachment 327819 [details]
Patch that fixes notify problem, and timer recurrence
Ah, I figured out this time what Michael had clearly pointed out. This new patch actually makes everything work swimmingly here. Maybe we can get the maintainer to accept, issue a new package, and work with upstream to get this accepted there?
Comment on attachment 327819 [details]
Patch that fixes notify problem, and timer recurrence
My testing was faulty, so I apologize for spamming this bug. Neither of these patches fully fixes the problem.
Yes, adding the extra "reason" arg to the callback function is not enough. I've tried that, too, but then other tracebacks happen in several places [in glib close(), in pulsebutton] - all that is not reproducible with libnotify reverted to the old API. libnotify upstream has reverted the patch (comment 9) anyway and wrapped it into a new function [notify_notification_get_closed_reason()]. Created attachment 327821 [details]
Patch that *really* fixes notify problem, and timer recurrence (I hope)
OK, at the risk of becoming the most laughed-at FPL in Fedora history (or did that already happen?), I'm sending one more patch. I think I got the testing right. By way of explanation:
* Added a parameter to the _on_notification_closed() function to capture the new "reason" int that's in the patched libnotify, since there's no telling if/when that will be fixed in F-10
* Only clear _hander_id if it still exists
* Only close the notification if it still exists (i.e. if the user ignores the notification bubble while visible and clicks the timer instead)
I'm now running a patched RPM here and everything seems to work as it should. I tested these uses:
* Clicking the notification, then the timer to reset
* Clicking the notification, wait to ensure the new reminder notification appears in 60 sec
* Wait for the notification to disappear, wait to ensure the reminder notification appears in 60 sec
* Click the timer to reset, ignoring the notification
All seems to work as intended here, with libnotify-0.4.4-12.fc10. Sorry for the earlier spam and I hope this patch is acceptable or at least helpful to someone.
You could "import glib" and "except glib.GError" instead of catching and ignoring all exceptions. Good enough as a work-around. libnotify 0.4.5 will change it again. ;) Thanks for all the hints. I will look at this this weekend on my F10 box. (In reply to comment #15) > You could "import glib" and "except glib.GError" instead of catching and > ignoring all exceptions. That's what I did in gnome-applet-timer-2.0.1-7.fc10. gnome-applet-timer-2.0.1-7.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gnome-applet-timer-2.0.1-7.fc10 gnome-applet-timer-2.0.1-8.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gnome-applet-timer-2.0.1-8.fc10 Uh, the package from comment #18 crashed upon login, so I build gnome-applet-timer-2.0.1-8.fc10 wit Paul's patch. Works fine here, please test. My comment 15 referred to Paul's patch in comment 14, which could be improved in its first try...except block. Nowhere did I mean that you could do what you've tried in -8.fc10 (In reply to comment #21) > My comment 15 referred to Paul's patch in comment 14, which could be improved > in its first try...except block. Thanks for the clarification. > Nowhere did I mean that you could do what you've tried in -8.fc10 You mean -7.fc10, right? gnome-applet-timer-2.0.1-9.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/gnome-applet-timer-2.0.1-9.fc10 gnome-applet-timer-2.0.1-9.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gnome-applet-timer'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0228 gnome-applet-timer-2.0.1-9.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. |
Created attachment 323497 [details] timer-applet-2.0.1-stop-pulsing.patch The gnome timer applet never stops pulsing after a timer completes successfully. This is pretty annoying. It seems like the state-change signal is not being fired/caught properly, but I'm not sure why. The attached patch fixes the bug by doing _stop_pulsing_button() when the applet is clicked in a FINISHED state.