Application entry in Messaging Menu always starts the application

[Mirco Bauer]

When I ported Smuxi to the new libmessaging-menu library I noticed that the Messaging Menu is always executing/invoking the application. This is all good and nice as long as the application supports single-instance, when not it's a real pain though. Wouldn't it be sufficient to use the source-activiated event for the application itself, or by adding a new dedicated app-activated event. This way the application wouldn't need to deal with IPC at all and just work, I think this would be in the spirit of the new library to make it easy for application developers.

Thanks for considering! Besides this, the new lib works great!

[Lars Karlitski (larsu)]

I agree that this signal would be convenient in some cases, but there are several problems with how multiple-instance applications would interact with the messaging menu:

If two instances of the same application are running, how should they appear in the messaging menu? Showing two application sections would be confusing, as there would be no way to tell which one activates which instance. Showing one section with two running indicators (triangles) would obfuscate which source originates in which instance.

Also, when no instance of the application is running, how many sections should be shown? When one instance unregisters from the messaging menu (as a result of the user unchecking a box in preferences), but another instance is still running, should the sections disappear from the menu?

In general, the type of applications that appear in the messaging menu should not allow multiple instances. I can't think of a reason why empathy, thunderbird, or smuxi would need a second instance. In fact, it would be great if this decision leads to more single-instance apps ;)

> I think this would be in the spirit of the new library to make it easy for application developers.

Definitely! However, we couldn't find good answers to the above questions and decided to de-facto require apps to be single-instance. Supporting single-instance is really easy on Linux (either with GtkApplication or even with D-Bus directly).

> Thanks for considering! Besides this, the new lib works great!

Thank you! And thanks for updating smuxi so quickly.

[Mirco Bauer (meebey)]

> If two instances of the same application are running, how should they appear in the messaging menu? Showing two application sections would be confusing, as there would be no way to tell which one activates which instance. Showing one section with two running indicators (triangles) would obfuscate which source originates in which instance.

IMHO the 2nd register would replace the 1st register and the 1st application no longer receives signals and messaging-menu ignores the requests (if it can identify the 1st instance). If it can't detect if the 1st instance makes calls, then the 2st instance should be ignored instead and 1st stays active.

> Also, when no instance of the application is running, how many sections should be shown? When one instance unregisters from the messaging menu (as a result of the user unchecking a box in preferences), but another instance is still running, should the sections disappear from the menu?

This does not happen, the application has a single desktop file and only registers in .config/indicators/messages/applications/* once. If no instance is running, it would never show more than one app section

> In general, the type of applications that appear in the messaging menu should not allow multiple instances. I can't think of a reason why empathy, thunderbird, or smuxi would need a second instance. In fact, it would be great if this decision leads to more single-instance apps ;)

I fully agree, those apps should never need a 2nd instance running. In the case of Smuxi it is a purely technical issue why I am not supporting single-instance yet.

>> I think this would be in the spirit of the new library to make it easy for application developers.
> Definitely! However, we couldn't find good answers to the above questions and decided to de-facto require apps to be single-instance.

Well, my point is that this is a "feature regression" from libindicate, which didn't have this issue :-)
Now I would need to fix something in Smuxi that wasn't an issue before...

> Supporting single-instance is really easy on Linux (either with GtkApplication or even with D-Bus directly).

This isn't true for GTK+2 apps and neither for cross-platform applications (other OSs have no D-Bus).

> Thank you! And thanks for updating smuxi so quickly.
Yeah, it was hard work, as C# has no out-of-the-box GIR support, and libmessaging-menu dropped the C# binding. I had to write the C# binding first (https://github.com/meebey/messagingmenu-sharp), then port Smuxi to the new API and make a special Ubuntu 12.10 release of Smuxi. And all that in 4 days :-D as the 12.10 release was getting so close! :-) Was a real hackothon...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mirco Bauer (meebey)]

Smuxi has now a workaround for this feature regression, see:
https://github.com/meebey/smuxi/commit/928e4e9ce9c7bd3c299101b8996df009702e9c8e

If no other software is also/still affected, this report could be closed I guess.

[Mirco Bauer (meebey)]

In case someone else also needs a single application instance library for C# (or for inspiration for other languages), my MIT/X11 licensed implementation can be found here:
https://github.com/meebey/smuxi/commit/b6f538d92417e77445541886768bc50414faf281
Current version:
https://github.com/meebey/smuxi/blob/master/src/Common/SingleApplicationInstance.cs

[Mirco Bauer (meebey)]

Since Smuxi 1.0, single application instance is supported and this issues no longer applies to it.