Merge lp://qastaging/~unity-team/unity/lazy-places into lp://qastaging/unity

I'm worried about turning something asynchronous that late in the cycle, whereas it's been running synchronously for most of it.

The severity of that is considered "meidum/low" by the release team.

Is that code strictly equivalent to the previous mutter-based code?

> I'm worried about turning something asynchronous that late in the cycle,
> whereas it's been running synchronously for most of it.

Indeed. A few of us are testing it since my proposal and throughout tonight to make sure it's okay.

> The severity of that is considered "meidum/low" by the release team.

Indeed, it's a big win for login speed.

> Is that code strictly equivalent to the previous mutter-based code?

Yep, the Place*Remote was already ready for Connect () I just needed to hook it up in the right parts of the code. The code that re-establishes connection to a dead daemon just came about as I was in there but is obviously a very useful thing to have.

Nothing stood out from the diff in a quick review. I'll be test driving this branch until tomorrow and then do another review.

I think the code looks sane as such, the only problem I fear is some racy oddball edge case that relies on the old startup sequence. That said; I am not overly concerned by the nature of this patch; it is mainly about shuffling some existing logic around.

@neil: You could maybe sprinkle some comments in there explaining why you are doing the lazy setup?

With my less trained eyes in that area of code, it seems safe to me.

Just a few questions/remarks:
1.
210 + // In the worst case that the PlaceEntry wasn't connected and ready by the time we need to
211 + // show the menu
212 + if (_n_sections)
213 + {
214 + menu_item = dbusmenu_menuitem_new ();
215 + dbusmenu_menuitem_property_set (menu_item, DBUSMENU_MENUITEM_PROP_TYPE, DBUSMENU_CLIENT_TYPES_SEPARATOR);
216 + dbusmenu_menuitem_property_set_bool (menu_item, DBUSMENU_MENUITEM_PROP_ENABLED, true);
217 + dbusmenu_menuitem_property_set_bool (menu_item, DBUSMENU_MENUITEM_PROP_VISIBLE, true);
218 + _current_menu.push_back (menu_item);
219 + }

So basically, if it's the case (we are not connected), the first click will show nothing, but the second will show the place entries section, isn't it? Would be nice for Oneiric to add a FIXME so that we update the Quicklist as soon as it's connected (more generally, we need dynamic Quicklist to be more "dynamic" and react when even remote application are updating an opened Quicklist).

2.
427 + _home_button_hover = ubus_server_register_interest (ubus, UBUS_HOME_BUTTON_BFB_UPDATE,
428 + (UBusCallback)&PlacesView::ConnectPlaces,
429 + this);
This isn't the only way to show the launcher.
Ok, you Connect() the places in the other case by hovering (MouseEnter) the LauncherIcon which takes the case by revealing the launcher by pressing super or on edge activation. However, I think we can easily send an ubus signal in the launcher when Hidden turns to False (just need to check it's really False at the very beginning of the session and doesn't run to False to not emit the signal at session startup which will void your effort :-). Are you interested in this?

Other than that, unity is working fine here with your branch, will have a look again running it tomorrow as well :)

> @neil: You could maybe sprinkle some comments in there explaining why you are
> doing the lazy setup?

Yep, done. Also added some comments about why/when we're using Connect().

> So basically, if it's the case (we are not connected), the first click will
> show nothing, but the second will show the place entries section, isn't it?
> Would be nice for Oneiric to add a FIXME so that we update the Quicklist as
> soon as it's connected (more generally, we need dynamic Quicklist to be more
> "dynamic" and react when even remote application are updating an opened
> Quicklist).

Indeed, FIXME added.

> This isn't the only way to show the launcher.
> Ok, you Connect() the places in the other case by hovering (MouseEnter) the
> LauncherIcon which takes the case by revealing the launcher by pressing super
> or on edge activation.

This isn't to know when we show the launcher it's to know when the user _could_ be about to show the places (they'd need to hover->click, for instance), so we try and be clever and load the daemons while the user is still deciding what to do :)

ok, no issue from what I see, places start when they are supposed to start. Suspend/Resume works as well
Empiric tests with a cold cache for each on my laptop (desktop logging time only):
- with trunk: 31s
- with lazy load: 19s

And it has a French fix, how can I dismiss it? :-)

Still works well for me and with latest fixes I am a happy camper. So - awesome work Neil! And awesome with the timings didrocks!

https://twitter.com/kamstrup/statuses/58515212906672130