Merge lp:~ted/indicator-appmenu/destruction-will-happen-in-time into lp:indicator-appmenu/0.3
Status: | Merged |
---|---|
Merged at revision: | 113 |
Proposed branch: | lp:~ted/indicator-appmenu/destruction-will-happen-in-time |
Merge into: | lp:indicator-appmenu/0.3 |
Diff against target: |
217 lines (+90/-51) 1 file modified
src/indicator-appmenu.c (+90/-51) |
To merge this branch: | bzr merge lp:~ted/indicator-appmenu/destruction-will-happen-in-time |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Neil J. Patel (community) | Approve | ||
Review via email: mp+56641@code.launchpad.net |
Description of the change
So there's a glitch in the information coming from BAMF. It's a small glitch, but we were responding to it harshly. Destroying everything when it told us to. But, now we know we can't trust it. So this branch removes that trust.
It solves it the same way that you'd solve audio glitches, with a low pass filter. Basically a timeout for the computer scientists. We're averaging the signals. Which means we're only freeing the menus after we're told, *and* there's been enough time we're sure that BAMF has it's head on straight. If BAMF changes it's mind in that time, we assume it's a glitch.
Unfortunately this has a set of reprocussions. One of those is that we can get registrations for menus that we already "have" as we're still waiting to see if BAMF changed it's mind. To handle that we're allowing reregistration and destroying the previous menus. This shouldn't happen regularly, so it's not going to be that expensive.
guint xid = bamf_window_ get_xid( window) needs to be guint32 but that's it really, nice work. Approving to avoid another review cycle.