Use Different appName Values for the different EPP packages

[azoitl]

Currently the different EPP packages define in their plugin.xml the appName property with the value Eclipse. This is problematic on Linux machines as this property is to my understanding used for distinguishing different application instances.

So if you have as I have several EPP versions installed and for each a dedicated desktop file, Gnome Shell (not sure for KDE), can not associated any running instance with the according launcher. This is rather annoying.

The problem was already some time ago reported at the Eclipse bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=500571

the proposed solution was that the Eclipse launcher would correctly handle the --class command line option. Then the desktop file could provide an own name and the problem would be solved. As I don't know how much effort it is to implement that in the launcher, and yes I know I'm in the wrong github project here, I also found a simpler workaround: https://medium.com/@gayanper/installing-multiple-eclipse-in-gnome-29db46f57401, which is the one proposed above.

I currently do this every-time when I update my different Eclipse instances. For me this works nicely, however I don't know if there is any reason that all app packages have the same appName property value.

[merks]

I'm on Windows, so this is not a problem for me, but I have literally dozens of desktop links to various installations specialized to work with specific project setups. But most are the Committers package so if I were on Linux, just changing the app name wouldn't really help with that regard either...

[azoitl]

@merks not sure if your use case would be easily solvable on linux anyhow. At least the way I proposed is mostly for linking desktop files to running instances. With the --class commandline option there is a possibility. But I think for most Linux users this is not the need.

My use case, and I hope that is similar to others, is, that I have a few epp packages installed (in my case, Eclipse contributor, CDT, PhP) and would like to see in the overview (task bar) the different ones. By just changing the one line in all of the EPPs this works out of the box. I'm happy to do a sample PR for CDT or PhP.

[merks]

The product catalog generator in Oomph would need to know the new app names to produce correct *.desktop files and that's not information that's easily available from the p2 metadata. What else might make assumptions about the current names? I forget exactly how link handlers are registered...

A more general solution for dealing with multiple installations, even of the same product, would be better. Perhaps something as simple as a system property to control what org.eclipse.ui.internal.Workbench.createDisplay() passes to org.eclipse.swt.widgets.Display.setAppName(String)...

[merks]

I realize I have no clue what you mean by --class command line option. What exactly would "correct handling" entail?

In Oomph we generate a *.desktop file like this:

https://github.com/eclipse-oomph/oomph/blob/09cc8d40cd34341e838d2a1bd31ff745fdfdd57a/plugins/org.eclipse.oomph.setup.installer/src/org/eclipse/oomph/setup/internal/installer/FreeDesktopSupport.java#L59-L126

[azoitl]

There are two things that need to be check for the *.desctop file. The first is the StartupWMClass option this option's value is the value that the desktop environment (in my case Gnome) expects as application name. So all applications started that adhere to the name provided in StartupWMClass option will be grouped together in the task bar.

I googled a bit and it seems to be a common practice that applications should allow to change the wmclass value through a command line parameter called --class=. This would allow that you can create several different startup files for different Eclipse instances. Below you can find my manually created *.desktop file that I use for my JDT installation (some paths are obfuscated). There I tested the --class= option. But found out it is not working. And I had to change the value in CDT's epp plugin.xml.

[Desktop Entry]
Type=Application
Terminal=false
Encoding=UTF-8
Version=1.1
Name=Eclipse for Committers
Exec= <eclipse cdt install location>/eclipse --class=eclipse-cdt
Categories=Eclipse
Icon=<eclipse cdt install location>/cdt_logo_icon.xpm
StartupWMClass=eclipse-cdt

PS: what you also can see is that I have my own cdt icon. I have no problem that all eclipse products have an icon named eclipse.xpm but it is extremely bad that they also have all the same image. This is also something that I wanted to contribute to epp if there are no objections.

[merks]

Firstly, I would prefer we not change the default app name for all the EPP products. That just seems disruptive. What will stop working if we do that? E.g., people will update their existing installation and suddenly their desktop file doesn't work properly anymore because the StartupWMClass needs to be changed to some new value.

Of course --class doesn't work because that's specific to Linux and the launcher hasn't implemented support for that; implementing things in the launcher is a lot of work but if you want support for that, that's where it should be implemented. Maybe it's possible to implement it downstream from the launcher, I'm not sure. This is why I draw attention to org.eclipse.swt.widgets.Display.setAppName(String) and org.eclipse.ui.internal.Workbench.createDisplay() because I think it would be simple to support something like this via a few lines of code in createDisplay():

Exec= <eclipse cdt install location>/eclipse -vmargs -Dsome.system.property=whatever
StartupWMClass=whatever

I think that would solve the problem in a general way, including support multiple different installations of the same EPP product. To my thinking, that's better than a solution that creates new problems. I.e., provide a solution that gives users more flexibility without forcing everyone to make changes to adapt to a new choice we make for them.

[azoitl]

I understand that changing the default app name for EPP products seems disruptive. But I want to point out that this was IMHO from a branding perspective a bad decision. If I download, for example, CDT, I don't see anywhere that I have CDT. I get an eclipse executable, I get the default Eclipse icon, the window has Eclipse IDE in its title bar. I you look on our market companion, when I download CLion I see that its CLion. I strongly belive that this should also happen sooner then later with EPPs. And yes this is a disruption.

I'm happy to look into the launcher and Workbench to check how to best handle such an option.

FYI @jonahgraham

[merks]

Your comments about the name of the executable and the branding icons are expanding beyond the scope of this issue as stated in the title. Furthermore, given that I can install CDT, PHP, and whatever feature into any Eclipse Package, it's not entirely clear we need a name that excludes things, but I really don't want to digress here, because we go down into a topic where everyone is likely to have an opinion. I would rather focus on finding a solution that helps you, solves the problem in the most general way possible, and isn't disruptive to everyone else (who have not ask for change).

[azoitl]

Sorry @merks. You are right I'm expanding here way to much.

[merks]

I'm not sure how we could quickly test and confirm that providing a way to override the default app name here would be sufficient:

https://github.com/eclipse-platform/eclipse.platform.ui/blob/8bd169c3b24dc34a09ff68d2b78fa7f980c493e1/bundles/org.eclipse.ui.workbench/eclipseui/org/eclipse/ui/internal/Workbench.java#L749-L755

That's certainly the least amount of work...

---

Definitely a digression, but even for BIRT we do the branding thing:

[azoitl]

I spent some time today on digging deeper and also to understand better what options and how. But first things first. Using a different name in Display.setAppName() in Workbench.createDisplay() is the least effort and also the right way to do this for any Workbench based IDE/RCP. In principle this is also what I'm doing when I change the appName parameter in my installations.

What I looked furhter is what parameter to use. The -vmargs -Dsome.system.property approach has the advantage that with adding a view lines of code we could have a solution.

The drawback would be it would be some Eclipse specific parameter. If you would search for it or ask any LLM all answers that you get to solve the problem described above will tell you use the --class command line option.

So I searched further. If chatgpt didn't betrayed me I can access all command line options in IApplication's start method via: '`Map<String, String[]> arguments = context.getArguments(); Is this correct?

If yes we could also take in the IDEApplication the --class option. There also the Display is created. However I don't know how to pass the --class option to the Workbench plugin and if we even should do that.

---

PS: regarding the digression. It seems I was just unlucky with the Eclipse packages I use. Will follow up with the specific projects in their repos.

[jonahgraham]

FWIW I don't think adding --class to eclipse.c that converts to a custom -D vmarg is very difficult. Not sure if it is worth the extra effort, and it would special case one of the standard gtk options in a way that doesn't thrill me (i.e should we support --name too?)

As for renaming all the EPP IDEs, there used to be more branding per package and that has slowly been removed over time so that they share branding.

I am all in favour of making it easier to customize wm_class (easier than editing xml files deep in install)

[merks]

I think an option like --class, if not consumed by the launcher, would end up being passed to the application and that could consume it set a system property, i.e., I don't think the launcher necessarily needs to be specialized. But like Jonah, I'm not a big fan of adding a special command line option simply because it's a standard Linux thing. It seems to me that folks who want to solve a problem will be happy if there exists a solution and won't get to fussed out about the nature of that solution...

[azoitl]

I'm not sure if I was clear enough but I was also strongly in favor of adding --class support. I also would only accept that option if we are on Linux. I did a quick test and --class command line option would be forwarded to IDEApplication. So there I could check for that. Set a property before invoking createDisplay().

The correct way of doing this would be to set the appName property. However from the code I don't see a away of setting it. I guess that is not for seen in the branding API or?

@jonahgraham what should --name do differently? Or what property would you set with it?

[jonahgraham]

@jonahgraham what should --name do differently? Or what property would you set with it?

IIUC --name is to override the name for the window manager, but my point was more that there are a handful of gtk options and we use gtk in a non-standard way in Eclipse. See https://manpages.org/gtk-options/7 - most gtk apps have a --help-gtk which shows what is supported.

---

The correct way of doing this would be to set the appName property. However from the code I don't see a away of setting it. I guess that is not for seen in the branding API or?

Its too bad that it isn't there already, and I don't know exactly what it would take to expose this out. But having the appName be a overridable by some external method that you can connect to a command line option (or a preference?) seems like a reasonable thing to do.

---

I am not particularly keen on changing the appName in EPP itself, but then I don't use gnome desktop (I use xfc4e desktop). The reason I am not keen is that this type of grouping seems to always be wrong for some users, so changing it now seems disruptive. IIUC VS Code windows all get grouped together and when I use Windows which has similar grouping features I often find it does the wrong thing, but that seems like a personal preference issue.

---

PS does xdotool work as a simpler workaround than editing xml files? See for example https://stackoverflow.com/a/70198417

[azoitl]

@jonahgraham what should --name do differently? Or what property would you set with it?

IIUC --name is to override the name for the window manager, but my point was more that there are a handful of gtk options and we use gtk in a non-standard way in Eclipse. See https://manpages.org/gtk-options/7 - most gtk apps have a --help-gtk which shows what is supported.

Doing more of that gtk options would mean we need to do that in the gtk swt port. Because for these we would need access to the the gtk/X11/Wayland API.

---

The correct way of doing this would be to set the appName property. However from the code I don't see a away of setting it. I guess that is not for seen in the branding API or?

Its too bad that it isn't there already, and I don't know exactly what it would take to expose this out. But having the appName be a overridable by some external method that you can connect to a command line option (or a preference?) seems like a reasonable thing to do.

That I found no way does not mean there is no. One option would be to call Display.setAppName() already in the application and add a checkin workbench to not set a name if there is already a none default one.

---

I am not particularly keen on changing the appName in EPP itself, but then I don't use gnome desktop (I use xfc4e desktop). The reason I am not keen is that this type of grouping seems to always be wrong for some users, so changing it now seems disruptive. IIUC VS Code windows all get grouped together and when I use Windows which has similar grouping features I often find it does the wrong thing, but that seems like a personal preference issue.

I get that. For me this is mostly a workaround or when we want to have branded groups. Please see also the discussion I started in CDT (I hope I'm not overdoing it).

---

PS does xdotool work as a simpler workaround than editing xml files? See for example https://stackoverflow.com/a/70198417

For that we would need separate names per window which we don't have as most eclipse EPP instances have Eclipse as name.

[jonahgraham]

Doing more of that gtk options would mean we need to do that in the gtk swt port. Because for these we would need access to the the gtk/X11/Wayland API.

Sorry - my point was going in the opposite direction. That we don't do need to support any of the gtk special command line options using the gtk standard naming scheme. On a quick play around on my Linux system, many of the GUI programs don't support --class (e.g. pinta, google-chrome, file-roller, baobab all don't support --class).

[azoitl]

I have a first working version using the --class option: azoitl/eclipse.platform.ui@cf16411

What do you think? It was very little code and for me it is less ugly then expected.

[merks]

It would need some documentation here eventually:

https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html

Having an option that is specific to an OS would be a new thing and I'm not convinced that's a good thing.

It also made me wonder if on Windows the icons are all grouped into a single group because of the app name and that even for Windows one might want to configure that differently. Certainly when I run the birt.exe it's a different group on my task bar, even if I rename it to eclipse.exe, so I think that's the case. A system property would do the trick for this as well...

[azoitl]

I also didn't like the the os check in IDE application and I'm open to suggestions.

Birt is a bad example because Birt is a fully branded RCP and has set an app name in its product defining plugin.xml: https://github.com/eclipse-birt/birt/blob/master/UI/org.eclipse.birt.report.designer.ui.rcp/plugin.xml

[merks]

I only mention BIRT to point out that it is displayed in a different icon group on the Windows task bar which I expect is because it has a different appName...

I think a simple change like this would provide the desired functionality upon request for only those who desire it:

[azoitl]

To be honest I don't care to much how we do it. This solution looks cleaner for all platforms supported by Eclipse. How about eclipse.appName as system property name? This would be in line with the existing properties.

[merks]

Yes, eclipse.appName sounds fine to me. When there is a PR, other folks are likely to chime in...

[azoitl]

Did a first pull request. This contains now only the code. I was not smart enough to find the location where the documentation is maintained. Happy for any pointers.

[jonahgraham]

I added doc links in eclipse-platform/eclipse.platform.ui#2631 (comment)

[azoitl]

I added doc links in eclipse-platform/eclipse.platform.ui#2631 (comment)

thx

[merks]

Given this changes in the Platform to accommodate this, I think we can close this issue here as addressed upstream.