lp:~ted/indicator-appmenu/destruction-will-happen-in-time

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:indicator-appmenu/0.3 at revision 113

Neil J. Patel (community): Approve on 2011-04-06

Diff: 217 lines (+90/-51)

1 file modified

src/indicator-appmenu.c (+90/-51)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Bug #718926: Some apps don't integrate to appmenu after having their windows closed

Undecided

Fix Released

Link a bug report

Related blueprints

122. By Ted Gould on 2011-04-06

Attaching bug

121. By Ted Gould on 2011-04-06

We don't need to check BAMF to see if it's a desktop menu, let's let the hashtable do that for us.

120. By Ted Gould on 2011-04-06

Make sure that if a registration comes in with the same XID we rebuild the menus otherwise we could end up in states of denying the new window sets.

119. By Ted Gould on 2011-04-06

If we get unregister or register traffic, let's handle that as meaning we shouldn't destroy the data later.

118. By Ted Gould on 2011-04-06

Get things out of the DB incase we still want them. Trash diggers we are.

117. By Ted Gould on 2011-04-06

Putting the timer in the DB. Okay, now we're live.

116. By Ted Gould on 2011-04-06

Fleshing out the destroying of the window and removal of the source

115. By Ted Gould on 2011-04-06

Oh, goody. I didn't think we had enough explosive stuff going on at delayed times making it harder to debug.

114. By Ted Gould on 2011-04-06

Took the meat of old_window and put it in unregister. That'll become our immediate function.

113. By Ted Gould on 2011-04-06

Setup the structure for the timeout destruction