After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 670928 - Command line option for '--open-note' fails if Tomboy is already running
Command line option for '--open-note' fails if Tomboy is already running
Status: RESOLVED FIXED
Product: tomboy
Classification: Applications
Component: General
1.9.x
Other Linux
: Normal normal
: 1.9.0
Assigned To: Tomboy Maintainers
Tomboy Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-02-28 02:20 UTC by Jens Knutson
Modified: 2012-10-08 23:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to fix "Command line option for '--open-note' fails if Tomboy is already running" (2.97 KB, patch)
2012-09-02 08:39 UTC, Matteo Nardi
committed Details | Review

Description Jens Knutson 2012-02-28 02:20:35 UTC
If tomboy is NOT started already, using the --open-note flag works as expected.

However, if it IS running, I now get: "Tomboy is already running.  Exiting..."


This used to work in the past, so I hope that means it's a relatively easy fix.
Comment 1 Jared Jennings 2012-02-28 03:18:22 UTC
I believe there is different behavior on Windows than Linux for this too. It's a bug that I've seen before.
Comment 2 Matteo Nardi 2012-09-02 08:39:28 UTC
Created attachment 223189 [details] [review]
Patch to fix "Command line option for '--open-note' fails if Tomboy is already running"

This is caused by named mutexes which, since Mono 2.8 [1], work only if the MONO_ENABLE_SHM environment variable is set. This caused single instance detection not to work.

Assuming this Mono decision was for a good reason, I decided to fix it using DBus. Patch attached.
It works only if Tomboy is build with DBus support: Mac and Windows version might still have this problem (I can't test it since I only run Ubuntu). In that case we should probably set the MONO_ENABLE_SHM environment variable in the Windows and Mac build.

To remove all these ifdef I would have loved to refactor the affected class (RemoteControlProxy), making it an interface with two classes implementing it. (Then using Services.cs/PlatformFactory.cs to instantiate it.) ..but again: I would have probably broken Windows and Mac support since I can't test it.

[1] http://www.mono-project.com/Release_Notes_Mono_2.8#Shared_handles_are_disabled_by_default
Comment 3 Jared Jennings 2012-09-27 03:30:16 UTC
Review of attachment 223189 [details] [review]:

It appears good, but I don't really understand much of the code.
For now I've applied the patch at https://github.com/trepidity/Tomboy
Comment 4 Sandy Armstrong 2012-09-29 03:07:22 UTC
Interesting, unless things have changed since this commit [0] we should either explicitly set MONO_ENABLE_SHM, or merge something like Matteo's patch (which I haven't actually reviewed).

[0] http://git.gnome.org/browse/tomboy/commit/Tomboy/tomboy.in?id=123677b19bf7cc54cf872c1ec0da2a544e0b0df2

I don't recall off the top of my head how single instance detection works on Mac, but Windows uses a different scheme for that and for the remote control calls (and also it uses MS.NET instead of Mono).
Comment 5 Jared Jennings 2012-10-08 23:55:57 UTC
Review of attachment 223189 [details] [review]:

After running in my branch I have now pushed it to tomboy master