Community
Participate
Working Groups
For SWT.OpenDocument and SWT.OpenUrl to function properly, the following needs to be added as jvm arg: -Dswt.dbus.init I'll be updating relevant *.product files simmilar to when -XstartOnFirstThread was added to eclipse.ini files. See: 528414 – (swtWaylandLauncher) [Gtk3][Wayland] Launcher segfault under Wayland when openFile is used https://bugs.eclipse.org/bugs/show_bug.cgi?id=528414 525305 – [API]Provide SWT.OpenUrl event https://bugs.eclipse.org/bugs/show_bug.cgi?id=525305
New Gerrit change created: https://git.eclipse.org/r/116059
We should also consider adding this flag to some projects downstream.
Why not having this value assumed it's true by default so it's enabled without any necessary change in all .product files of the world?
(In reply to Mickael Istria from comment #4) > Why not having this value assumed it's true by default so it's enabled > without any necessary change in all .product files of the world? Hmmm. I thought about it for a while. @Alex, what about if we init GDBus only when a user adds a SWT.OpenUrl/SWT.OpenDocument listener? Like upon registering the listener, gdbus is fired up. I could wip together a proof of concept in <30 mins.
(In reply to Mickael Istria from comment #4) > Why not having this value assumed it's true by default so it's enabled > without any necessary change in all .product files of the world? To avoid conflicting unique (aka well-known) session bus "org.eclipse.swt". Ex, we wouldn't want an app like "Vuze" stealing org.eclipse.swt name, otherwise if both eclipse and vuze are running, vuze might steal the session bus name. But this could potentially be avoided if we only init gdbus if/when we add OpenDocument/OpenUrl listener.
(In reply to Leo Ufimtsev from comment #5) > (In reply to Mickael Istria from comment #4) > > Why not having this value assumed it's true by default so it's enabled > > without any necessary change in all .product files of the world? > > Hmmm. I thought about it for a while. > > @Alex, what about if we init GDBus only when a user adds a > SWT.OpenUrl/SWT.OpenDocument listener? > Like upon registering the listener, gdbus is fired up. > > I could wip together a proof of concept in <30 mins. Will that work for the launcher case?
(In reply to Mickael Istria from comment #4) > Why not having this value assumed it's true by default so it's enabled > without any necessary change in all .product files of the world? Mickael, for the record OpenDocument (the way it was implemented prior to M5) relied on X11 atoms which were set by eclipse executable only thus eclipse launched with java -jar launcher.jar was not supporting it. So what Leo proposes is net addition opening the possibility to use the new dbus based method so in theory we don't need this for every product to change (possibly very few people launch eclipse that way) it's a matter of opening the door for people working on the dbus code itself (inner eclipse) or trying to work on other code using the dbus method to do new integration. IMHO if we can get Platform and EPP packages it's good enough for now. With that said if Leo manages to make it more dynamic without the system property - that would be perfect.
(In reply to Leo Ufimtsev from comment #7) > To avoid conflicting unique (aka well-known) session bus "org.eclipse.swt". > Ex, we wouldn't want an app like "Vuze" stealing org.eclipse.swt name, > otherwise if both eclipse and vuze are running, vuze might steal the session > bus name. Could we have unique session bus id for each app. So it would be "org.eclipse.swt.<launcherName>" or something like that that allows to distinguish apps?
(In reply to Alexander Kurtakov from comment #8) > (In reply to Leo Ufimtsev from comment #5) > > (In reply to Mickael Istria from comment #4) > > > Why not having this value assumed it's true by default so it's enabled > > > without any necessary change in all .product files of the world? > > > > Hmmm. I thought about it for a while. > > > > @Alex, what about if we init GDBus only when a user adds a > > SWT.OpenUrl/SWT.OpenDocument listener? > > Like upon registering the listener, gdbus is fired up. > > > > I could wip together a proof of concept in <30 mins. > > Will that work for the launcher case? *In theory* yes. This could potentially simplify the launcher in that we could remove setting of the gtk platform-specific flag in the eclipseGtk.c code altogether. I'll experiment and report my findings.
(In reply to Mickael Istria from comment #10) > (In reply to Leo Ufimtsev from comment #7) > > To avoid conflicting unique (aka well-known) session bus "org.eclipse.swt". > > Ex, we wouldn't want an app like "Vuze" stealing org.eclipse.swt name, > > otherwise if both eclipse and vuze are running, vuze might steal the session > > bus name. > > Could we have unique session bus id for each app. So it would be > "org.eclipse.swt.<launcherName>" or something like that that allows to > distinguish apps? We do this for webkit extension. Every eclipse has a unique session bus. But for opening files, clients usually expect a well known 'aka unique' session bus. It's possible to have a '<launcherName>' extension to the session name of sort, e.g set by a System Property. Would be ~2 extra lines of code in GDBus.java. But there should probably be some kind of use case first?
(In reply to Leo Ufimtsev from comment #12) > (In reply to Mickael Istria from comment #10) > > (In reply to Leo Ufimtsev from comment #7) > > > To avoid conflicting unique (aka well-known) session bus "org.eclipse.swt". > > > Ex, we wouldn't want an app like "Vuze" stealing org.eclipse.swt name, > > > otherwise if both eclipse and vuze are running, vuze might steal the session > > > bus name. > > > > Could we have unique session bus id for each app. So it would be > > "org.eclipse.swt.<launcherName>" or something like that that allows to > > distinguish apps? > > We do this for webkit extension. Every eclipse has a unique session bus. > But for opening files, clients usually expect a well known 'aka unique' > session bus. > > It's possible to have a '<launcherName>' extension to the session name of > sort, e.g set by a System Property. Would be ~2 extra lines of code in > GDBus.java. > But there should probably be some kind of use case first? Having the launcherName property will be totally useless as none of the products rebuild the native launcher thus it will always be the same for all.
(In reply to Alexander Kurtakov from comment #13) > Having the launcherName property will be totally useless as none of the > products rebuild the native launcher thus it will always be the same for all. The launcher name shouldn't be included in the launcher code, but computed dynamically at runtime. For Red Hat Developers Studio, it's `devstudio`. This is the launcher name that should be considered to name the bus with.
(In reply to Mickael Istria from comment #14) > (In reply to Alexander Kurtakov from comment #13) > > Having the launcherName property will be totally useless as none of the > > products rebuild the native launcher thus it will always be the same for all. > > The launcher name shouldn't be included in the launcher code, but computed > dynamically at runtime. For Red Hat Developers Studio, it's `devstudio`. > This is the launcher name that should be considered to name the bus with. One option is to have the name be "org.eclipse.swt" as default, and optionally append a post-fix via System Property if there is need for it.
Proof of concept works: 530397 – [Gtk] Make gdbus initialization dynamic https://bugs.eclipse.org/bugs/show_bug.cgi?id=530397 There's no need for the swt.gdbus.init property and by extension no need for adding the vmarg to *.product files.
Ok, so making gdbus dynamic appears to be the better approach. To be continued in: 530397 – [Gtk] Make gdbus initialization dynamic https://bugs.eclipse.org/bugs/show_bug.cgi?id=530397 The gdbus session naming is a slightly different issue that can be handled independently. If there is a need to have a separate session bus, feel free to open a bug with use case and we can implement the feature. (~3 lines of code probably). Thanks for your suggestion!
