Merge lp://qastaging/~charlesk/indicator-sync/initial-impl into lp://qastaging/indicator-sync/12.10

Some minor comments:

* app-menu-item:
  - app_menu_item_new: having initialization in _new makes it very hard for
    bindings (which typically only call g_object_new); a better place to
    initialize would be _init or _constructed
  - no need for g_return_if_fail in non-public gobject methods (there's enough
    type checking in gobject and the type casts)

* indicator-sync:
  - the hard-coded red error color can probably be solved by setting a class on
    the label which is then colored in the css (talk to Cimi)
  - afaict, calculate_prog_menuitem_preferred_width() does the same as
    gtk_label_set_width_chars()

* sync-client
  - there's no need to keep the GBindings around, they will be deleted
    automatically when one of the objects is freed
  - usually, the setter functions are called in set_property (this is the other
    way around)
  - sync client is meant to be used by applications? It probably shouldn't
    block the main loop then (for example: g_bus_get_sync in sync_client_init)
  - header file has private stuff in it (menuitem types)

* sync-enum:
  - interesting docstring on SyncState ;)

* sync-service:
  - why emit_exists when clients can just listen for a unique name to appear

* python bindings: why don't you use gobject-introspection? pygtk is deprecated

Some higher level comments:

* why have "exsists" signals on servers and clients when you could just watch for name_vanished
* is the indendation hack in indicator-sync.c (on_app_widget_shown) responsible for the wrong menu highlight on non-application menu items?
* build examples by default
* `make distcheck` doesn't work

> app_menu_item_new: having initialization in _new makes it very hard for
> bindings (which typically only call g_object_new); a better place to
> initialize would be _init or _constructed

That would be nice-to-have but this a single-use class, IMO it's not worth refactoring that before FF

> to need for g_return_if_fail in non-public gobject methods (there's enough
> type checking in gobject and the type casts)

Done, r13

> the hard-coded red error color can probably be solved by setting a class on
> the label which is then colored in the css (talk to Cimi)

Will do.

> afaict, calculate_prog_menuitem_preferred_width() does the same as
> gtk_label_set_width_chars()

Doesn't exist for progressbar

> * sync-client
> - there's no need to keep the GBindings around, they will be deleted
> automatically when one of the objects is freed
> - usually, the setter functions are called in set_property (this is the other
> way around)

Fixed r14

> - sync client is meant to be used by applications? It probably shouldn't
> block the main loop then (for example: g_bus_get_sync in sync_client_init)

Fixed r15

> - header file has private stuff in it (menuitem types)

That's public -- it's needed for setting the percent done property on the client menuitems

> * sync-enum:
> - interesting docstring on SyncState ;)

LOL! Fixed r16

> * sync-service:
> - why emit_exists when clients can just listen for a unique name to appear

Fixed r17

> * python bindings: why don't you use gobject-introspection? pygtk is deprecated

Great point!!

Fixed r18

> * sync-client
> - there's no need to keep the GBindings around, they will be deleted
> automatically when one of the objects is freed

Actually, we need to explicitly clear the menu_binding... we don't create the menu object that's being bound, so we don't know what its lifespan will be. Reverted in r19 for menu_binding only.

> - usually, the setter functions are called in set_property (this is the other
> way around)

Fixed r19

> Doesn't exist for progressbar

Ah, right. /me needs to read more careful.

The fixes look great, thanks!