Community
Participate
Working Groups
In our RCP app we rely on distinguishing two different products when opening files from the commmand line on Linux. This was possible using <executable> -product <product1> -name <name1> <executable> -product <product2> -name <name2> Recent changes to support Wayland changed the mechanism for opening files, described in this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=528414 Now the running application is identified using gdbus, but all apps use the same coordinates. So if I: * open my app * open Eclipse * try to open a file in my app * the file opens in Eclipse This comment: https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT/gtk/org/eclipse/swt/widgets/Display.java#L766 seems to acknowledge this. Is there anything I can do about this?
(In reply to Will Rogers from comment #0) > In our RCP app we rely on distinguishing two different products when opening > files from the commmand line on Linux. This was possible using > > <executable> -product <product1> -name <name1> > <executable> -product <product2> -name <name2> > > Recent changes to support Wayland changed the mechanism for opening files, > described in this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=528414 > > Now the running application is identified using gdbus, but all apps use the > same coordinates. That is a design issue I would say. > Is there anything I can do about this? Try to provide a better patch / improve design. IMHO this implementation "as is" is nonsense. I have ~3 Eclipse applications running in parallel almost all the time, so what kind of meaningful interaction such API provides, if it always chooses some random (last connected, not even last active) instance? Right, zero. It is a "Russian roulette", literally. I would assume patching org.eclipse.swt.internal.GDBus.init(GDBusMethod[]) could be the key - instead of using hard coded keys/names it could check some system property and use that instead, so your product could specify that property by using some unique name/version.
Thank you for responding. If you think it is possible that I could get a change merged into an Eclipse release fairly promptly (2020-12, I suppose) then I might be able to work on this.
(In reply to Will Rogers from comment #2) > Thank you for responding. > > If you think it is possible that I could get a change merged into an Eclipse > release fairly promptly (2020-12, I suppose) then I might be able to work on > this. If your patch would solve the problem & would be accepted in the review, why not? You can try. This will be 4.18 release, 4.17 is too late I think (but it depends on the patch). If it will be small & simple, we may even try to get it into 4.17, but you must work very fast for that :)
My initial proposal is to use the value of the -name command line argument. This should be different between different Eclipse products and could be different between different instances of the same product if the command-line argument is used. This is somewhat similar to the older behaviour. The native code has access to this value. I expect that the SWT code can get hold of it as well although I am still figuring out how to build and use that to check. Since an app 'owns' the destination org.eclipse.swt, it seems to me that we will have to change that string to include the name somehow - for example org.eclipse.swt.<name>. Problems I can foresee: * do we need to keep backward compatibility e.g. Eclipse still uses just org.eclipse.swt be default? * do we need to be careful about the characters that we use in the destination string? Let me know what you think. I don't know much in these areas so I could easily miss important problems.
(In reply to Will Rogers from comment #4) > My initial proposal is to use the value of the -name command line argument. > > This should be different between different Eclipse products and could be > different between different instances of the same product if the > command-line argument is used. This is somewhat similar to the older > behaviour. > > The native code has access to this value. Which native code? > I expect that the SWT code can get > hold of it as well although I am still figuring out how to build and use > that to check. I fear that this could be not directly possible, because at the moment where SWT init code runs, you are probably not being in application code yet (where you can use all the Eclipse product related APIs / equinox start arguments etc. SWT itself has no dependencies and can only access system properties / environment variables, so most likely you would need either add the system property to the JVM launcher (e. g. start with -DswtPleaseUseThisNameForDbus) or you would need somehow change the equinox launcher code to translate the application names into SWT system property. > Since an app 'owns' the destination org.eclipse.swt, it seems to me that we > will have to change that string to include the name somehow - for example > org.eclipse.swt.<name>. Yes, most likely > Problems I can foresee: > > * do we need to keep backward compatibility e.g. Eclipse still uses just > org.eclipse.swt be default? I wouldn't care. Whoever used that couldn't really build anything useful before, due the limitations you know, and for the end users this was not visible anyway. > * do we need to be careful about the characters that we use in the > destination string? Probably yes, but I haven't looked at this code/not a dbus expert.
My proposed changes: * rt.equinox.framework/features/org.eclipse.equinox.executable.feature/library/gtk/eclipseGtk.c Here you can use getOfficialName() and append it to GBUS_SERVICE. * eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Display.java You could pass getAppName() to GDBus.init(). * eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/internal/GDBus.java Use the passed appName to append to DBUS_SERVICE_NAME. In my tests these seems to be reliably getting the same piece of information, which would be changed by using the command-line argument -name, but my development setup is still a bit ad-hoc. The diff is about 25 lines in total, but I haven't yet figured out my way around Gerrit or the patch system here to best show it. Pasting it into this box doesn't look like a good idea.
(In reply to Will Rogers from comment #6) > The diff is about 25 lines in total, but I haven't yet figured out my way > around Gerrit or the patch system here to best show it. Pasting it into this > box doesn't look like a good idea. Does https://wiki.eclipse.org/Platform/How_to_Contribute help?
I am trying to push to Gerrit as described on this page: https://www.eclipse.org/community/eclipse_newsletter/2014/july/article3.php Eclipse says eclipse.buildId=4.17.0.I20200826-1800 java.version=11.0.2 java.vendor=Oracle Corporation BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_GB Command-line arguments: -os linux -ws gtk -arch x86_64 ssh://git.eclipse.org:29418/equinox/rt.equinox.framework: No more authentication methods available Quite likely I need additional permissions of some kind or there's some misconfiguration. I have just created an account on Gerrit and uploaded my SSH key.
OK, I seem to have got around that. Here are two changes. There's nothing 'correct' about them, they just demonstrate the approach that seems like it should work. https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/168374 https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/168376
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/168377
How do you think I should proceed with this? I have pushed a proposed fix to Gerrit, but I would appreciate feedback from someone who knows the code to make sure that it is a viable approach before finishing it off.
I am now pretty happy with these changes and hope to get them merged.
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/168377 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=eb2597355105f93a1b7f3cf8fa4525ee7d841ed6
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/168376 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3ca3f06eed3590e589fc5f8d79968245b635e47a
Thanks, Will.
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/168928
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/168928 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=ebb925eae87ac505b3c3243c72a3150ceb2e6f84
launcher has been rebuilt and committed via https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/?id=b232e1524a27753c0a4d86e0e1f7eb35cdd22478
(In reply to Sravan Kumar Lakkimsetti from comment #18) > launcher has been rebuilt and committed via > https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/ > ?id=b232e1524a27753c0a4d86e0e1f7eb35cdd22478 I don't see SWT/Equinox bundle version updates - was this done already before?
(In reply to Andrey Loskutov from comment #19) > (In reply to Sravan Kumar Lakkimsetti from comment #18) > > launcher has been rebuilt and committed via > > https://git.eclipse.org/c/equinox/rt.equinox.binaries.git/commit/ > > ?id=b232e1524a27753c0a4d86e0e1f7eb35cdd22478 > > I don't see SWT/Equinox bundle version updates - was this done already > before? We are handling that via https://bugs.eclipse.org/bugs/show_bug.cgi?id=566362. I do know SWT versions have been incremented. But I will check equinox bundles in the next build and update the versions if necessary
I am very happy to report that I have built my product against the latest I-build and I can reliably launch against two different instances using the -name command-line argument.
(In reply to Will Rogers from comment #21) > I am very happy to report that I have built my product against the latest > I-build and I can reliably launch against two different instances using the > -name command-line argument. Great to hear. Unfortunately I now see the following message if I start a customer IDE. (Custom IDE:79356): GLib-GIO-CRITICAL **: 09:43:07.592: g_bus_own_name: assertion 'g_dbus_is_name (name) && !g_dbus_is_unique_name (name)' failed SWT GDBus: Failed to aquire bus name: org.eclipse.swt.Custom IDE Is this related to the change?
It does look like it. Is that the real message or have you substituted the actual name? It looks like the bus name has a space in it - is that correct? If so, how has that happened? Usually it takes the name of the product executable.
I guess the launcher code using the appname should do some trivial sanity checks for leading/trailing/included white space.
Created attachment 284090 [details] Screenshot Here is a screenshot of the product configuration I'm using. If you want I can upload an example set of projects.
That might help. I'm pretty sure the problem is that we're trying to create a gdbus session with a space in but I can't figure out how to build a product that does that.
Created attachment 284092 [details] Example projects This is a small example from the start of our commercial Eclipse IDE extension training. You can use "mvn clean verfiy" to build it, you also get the error if you import the projects into an empty workspace of an integration build of 4.18 and start via the .product file.
(In reply to Lars Vogel from comment #27) > Created attachment 284092 [details] > Example projects > > This is a small example from the start of our commercial Eclipse IDE > extension training. You can use "mvn clean verfiy" to build it, you also get > the error if you import the projects into an empty workspace of an > integration build of 4.18 and start via the .product file. "mvn clean verify"
Thank you, I can recreate this now. I propose to remove leading and trailing whitespace then replace any sequence of whitespace within the string with a hyphen. That would make the bus name in Lars's example org.eclipse.swt.Custom-IDE I'll try to look at that this afternoon.
We may also want to handle other cases for completeness: (CustomIDE😅:20061): GLib-GIO-CRITICAL **: 12:25:37.179: g_bus_own_name: assertion 'g_dbus_is_name (name) && !g_dbus_is_unique_name (name)' failed SWT GDBus: Failed to aquire bus name: org.eclipse.swt.CustomIDE😅
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/169086
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/169087
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/169087 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=35c6554087a521ad6896f5c62d213572c5aed85d
Thanks, will validate with next integration build.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/169086 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=03285ca2c39c48d86b22211483638f53c9a56da6
Please confirm/verify this bug fix using latest Eclipse IBuild, Thanks!
I built my product against the latest I-build and this seems to be working well for me now.
(In reply to Will Rogers from comment #37) > I built my product against the latest I-build and this seems to be working > well for me now. Thanks Will, marking as Verified.
