Merge lp://staging/~xnox/ubuntu/raring/liferea/messaging-menu into lp://staging/~xnox/ubuntu/raring/liferea/original

Seems to work, but have no idea if this is roughly correct or not.
Also package branches are out of date, hence this crazy merge-proposal, if it looks ok I'll just upload it into raring.

https://bazaar.launchpad.net/~xnox/ubuntu/raring/liferea/messaging-menu/revision/2#src/ui/ui_indicator.c

"the meat portion of this mess" =)

It is roughly correct, but only very roughly ;)

You don't get a callback when the user clicks the application name any more. Instead, the app is launched again through its desktop file. This means that all applications that support the messaging menu must be single instance (which liferea is). Thus, on_indicator_server_clicked can be removed.

I recommend against hooking on_indicator_clicked up to the detailed signals only to pass the node as user data (if you're doing it like that, you would also need to disconnect the signals in the handler). Instead, hook the function up once, and lookup the node through its id in on_indicator_clicked.

The arguments to on_indicator_clicked are wrong, they should be

  static void
  on_indicator_clicked (MessagingMenuApp *mmapp, const gchar *source_id, gpointer user_data)

What did you intend to do here:

  messaging_menu_app_remove_source (indicator_priv->server, (char *)(indicator));

Casting the MessagingMenuApp pointer to a string?! You probably want 'source_id' in there.

> It is roughly correct, but only very roughly ;)
>
> You don't get a callback when the user clicks the application name any more.
> Instead, the app is launched again through its desktop file. This means that
> all applications that support the messaging menu must be single instance
> (which liferea is). Thus, on_indicator_server_clicked can be removed.
>

Dead code -> gone! thanks.

> I recommend against hooking on_indicator_clicked up to the detailed signals
> only to pass the node as user data (if you're doing it like that, you would
> also need to disconnect the signals in the handler). Instead, hook the
> function up once, and lookup the node through its id in on_indicator_clicked.
>

I see, makes sense. Will switch to using one handler to rule them all.

> The arguments to on_indicator_clicked are wrong, they should be
>
> static void
> on_indicator_clicked (MessagingMenuApp *mmapp, const gchar *source_id,
> gpointer user_data)
>

Missing const added.

> What did you intend to do here:
>
> messaging_menu_app_remove_source (indicator_priv->server, (char
> *)(indicator));
>
> Casting the MessagingMenuApp pointer to a string?! You probably want
> 'source_id' in there.

I can see how the terminology is confusing. So there is indicator_priv which has a GPtrArray of node->id's. Confusingly that GPtrArray is called "indicators" and the pointers to node->id's are "indicator", thus it actually is casting 'source_id' from a gpointer to char.

Does messaging menu "rate-limit" at the moment? Cause that indicator_priv is mostly to keep track of how many source_ids are displayed (no more than 6 at the moment)