Merge lp://qastaging/~bratsche/appmenu-gtk/almost-rewrite into lp://qastaging/appmenu-gtk/0.4

Proposed by Cody Russell
Status: Merged
Merged at revision: 21
Proposed branch: lp://qastaging/~bratsche/appmenu-gtk/almost-rewrite
Merge into: lp://qastaging/appmenu-gtk/0.4
Diff against target: 702 lines (+432/-162)
1 file modified
src/bridge.c (+432/-162)
To merge this branch: bzr merge lp://qastaging/~bratsche/appmenu-gtk/almost-rewrite
Reviewer Review Type Date Requested Status
David Barth (community) Approve
Jason Smith (community) Approve
Review via email: mp+27638@code.qastaging.launchpad.net

Description of the change

So in the process of trying to store root and server per-window, I ended up rewriting almost the entire appmenu-gtk.

To post a comment you must log in.
Revision history for this message
Jason Smith (jassmith) wrote :

Looks good. Could use a couple comments explaining what happens in fail conditions here and there (like if your proxy is null) but nothing blocking a merge.

+1

review: Approve
Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

Forgive me if I don't know exactly how libappmenu is going to be used - it's not mentioned anywhere in any of the distributed files ;-) From the looks I'd say it was the gtk module that we load into all apps to export the menu on the bus? My comments are based on that at least :-)

I am a bit worried about the NameOwnerChanged signal around line 100... The way you listen for it the process will wake up each time anyone joins or leaves the bus, or any time anyone changes anything with the naming on the bus. So if this is done by all apps linking to gtk it may be a problem.

It's not like these event are very frequent, but they do happen every now and then. The times where we have then en masse is on shutdown and startup. But still just for a regularly running desktop it may have an impact on app startup time - I'm not sure how much though.

Sadly there is no easy fix though. There is a laborious fix :-) That would be manually installing a filter func in libdbus and then adding a MatchRule (with org.freedesktop.DBus.AddMatch) like :

  type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged'arg0='WATCHED_NAME',arg2=''

which matches only when WATCHED_NAME drops off. For an example of playing around with samething like this see http://bazaar.launchpad.net/~unity-team/dee/trunk/annotate/head:/dee/dee-peer.c#L693

Revision history for this message
Ted Gould (ted) wrote :

Mikkel,

I thought that there was an easy way to get the specific name change in GDBus. I figured we'd pick up that optimization when we ported from dbus-glib to GDBus.

Ted

Revision history for this message
David Barth (dbarth) wrote :

I'd recommend landing that branch, with the next step being to add the matchrule, as explained by Mikkel. The previous experience with gdbus was not successful, so i'd rather have one bird in the hand asap.

review: Approve
Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

Ted: Yeah name watching is integrated nicely in gdbus as far as I can see

Revision history for this message
Cody Russell (bratsche) wrote :

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches