This is directly related to #1579 but I feel deserves a new issue as the potential fixes, whilst similar, aren't the same.
Just like in the linked issue, our Linux .desktop file is produced directly by electron-builder and does not actually reference our own, maintained, template within the repo.
This is the .desktop file we produce (taken from our 1.132.1 deb package):
[Desktop Entry]
Name=Pulsar
Exec=/opt/Pulsar/pulsar %U
Terminal=false
Type=Application
Icon=pulsar
StartupWMClass=Pulsar
Comment=A Community-led Hyper-Hackable Text Editor
Categories=Development;
but this is what Atom 1.60.0 has:
[Desktop Entry]
Name=Atom
Comment=A hackable text editor for the 21st Century.
GenericName=Text Editor
Exec=env ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false /usr/bin/atom %F
Icon=atom
Type=Application
StartupNotify=true
Categories=GTK;Utility;TextEditor;Development;
MimeType=application/javascript;application/json;application/x-httpd-eruby;application/x-httpd-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/x-ruby;application/x-bash;application/x-csh;application/x-sh;application/x-zsh;application/x-shellscript;application/x-sql;application/x-tcl;application/xhtml+xml;application/xml;application/xml-dtd;application/xslt+xml;text/coffeescript;text/css;text/html;text/plain;text/xml;text/xml-dtd;text/x-bash;text/x-c++;text/x-c++hdr;text/x-c++src;text/x-c;text/x-chdr;text/x-csh;text/x-csrc;text/x-dsrc;text/x-diff;text/x-go;text/x-java;text/x-java-source;text/x-makefile;text/x-markdown;text/x-objc;text/x-perl;text/x-php;text/x-python;text/x-ruby;text/x-sh;text/x-zsh;text/yaml;inode/directory
StartupWMClass=atom
And it can be seen that this far more closely aligns with the template in our repo that we actually continue to maintain which actually has even more functionality added:
[Desktop Entry]
Name=<%= appName %>
Comment=<%= description %>
GenericName=Text Editor
Exec=env ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false <%= installDir %>/bin/<%= appFileName %> --no-sandbox %F
Icon=<%= iconPath %>
Type=Application
StartupNotify=true
Categories=Utility;TextEditor;Development;
MimeType=application/javascript;application/json;application/x-httpd-eruby;application/x-httpd-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/x-ruby;application/x-bash;application/x-csh;application/x-sh;application/x-zsh;application/x-shellscript;application/x-sql;application/x-tcl;application/xhtml+xml;application/xml;application/xml-dtd;application/x-zerosize;application/xslt+xml;text/coffeescript;text/css;text/html;text/plain;text/xml;text/xml-dtd;text/x-bash;text/x-c++;text/x-c++hdr;text/x-c++src;text/x-c;text/x-chdr;text/x-csh;text/x-csrc;text/x-dsrc;text/x-diff;text/x-go;text/x-java;text/x-java-source;text/x-makefile;text/x-markdown;text/x-objc;text/x-perl;text/x-php;text/x-python;text/x-ruby;text/x-sh;text/x-zsh;text/yaml;inode/directory
StartupWMClass=pulsar
Actions=new-window
[Desktop Action new-window]
Name=New Window
Exec=pulsar --new-window
So what problem does this cause?
Again, technically no actual problem but, like the linked issue, I think this was another unintended change caused by switching to electron-builder which hasn't gone noticed. We still do produce a .desktop file (in the deb, rpm and appimage at least - we really should be providing one for the tar.gz) because it mostly seems to work from defaults in electron-builder itself.
The main negative effect of this change is just loss of some functionality. Without the MimeType values it means we don't actually register Pulsar as something that can handle those mime types. We also miss out on the categories to place it in an appropriate place on certain desktop environments.
The Exec
This one is interesting. With Atom it clearly shows that it was always meant to be executed via the atom.sh script in /usr/bin. With Pulsar we still use it but only for launching via $PATH because we do still place it in the same place as Atom.
However, when launching via the .desktop we actually launch the pulsar binary directly in /opt/Pulsar, bypassing the script entirely.
The Exec also does a few other things in that it sets ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false as well as adding --no-sandbox as an argument.
Whilst this clearly doesn't really seem to cause much of a problem in practice I would like to know if there is a justified reason for either using it or or not using it to launch Pulsar from the desktop shell.
Even if not causing an active problem now, are we likely going to want to add any additional features into pulsar.sh that would benefit from it being in the .desktop Exec?
One other small issue with hard linking the path to the binary makes this non-portable and non-relocateable without manual editing. Ideally we should always be executing from a location on $PATH.
AppImage exception
A little weird curiosity we have here is our AppImage. What happens there is a little different because we do have a .desktop but, as it is a self-contained application, it doesn't actually use it directly. Instead what it does is the AppRun script will run pulsar.sh to launch the main application.
This actually does have an undesirable side-effect which is raised here: #1581
What can or should we do?
Like with the rpm and deb packaging issue, I think we should at the very least do the following:
- Add some of the data into the
electron-builder script so that we do at least produce the mime type values as well as a few other items
- Evaluate whether to "correct" the
Exec back to pulsar.sh from /opt/Pulsar/pulsar
- Decide if
ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=false and --no-sandbox should be added to the Exec
- Make sure a desktop file is added to the
tar.gz when packaged.
Pulsar version
1.132.1
Additional Information:
Pulsar team members can find a thread on Discord at https://discord.com/channels/992103415163396136/1508277521966301264/1508277534100295691 that goes into my initial findings and discussion with @savetheclocktower about them.
This is directly related to #1579 but I feel deserves a new issue as the potential fixes, whilst similar, aren't the same.
Just like in the linked issue, our Linux
.desktopfile is produced directly byelectron-builderand does not actually reference our own, maintained, template within the repo.This is the .desktop file we produce (taken from our 1.132.1 deb package):
but this is what Atom 1.60.0 has:
And it can be seen that this far more closely aligns with the template in our repo that we actually continue to maintain which actually has even more functionality added:
So what problem does this cause?
Again, technically no actual problem but, like the linked issue, I think this was another unintended change caused by switching to
electron-builderwhich hasn't gone noticed. We still do produce a .desktop file (in the deb, rpm and appimage at least - we really should be providing one for the tar.gz) because it mostly seems to work from defaults inelectron-builderitself.The main negative effect of this change is just loss of some functionality. Without the
MimeTypevalues it means we don't actually register Pulsar as something that can handle those mime types. We also miss out on the categories to place it in an appropriate place on certain desktop environments.The
ExecThis one is interesting. With Atom it clearly shows that it was always meant to be executed via the
atom.shscript in/usr/bin. With Pulsar we still use it but only for launching via$PATHbecause we do still place it in the same place as Atom.However, when launching via the
.desktopwe actually launch thepulsarbinary directly in/opt/Pulsar, bypassing the script entirely.The
Execalso does a few other things in that it setsATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=falseas well as adding--no-sandboxas an argument.Whilst this clearly doesn't really seem to cause much of a problem in practice I would like to know if there is a justified reason for either using it or or not using it to launch Pulsar from the desktop shell.
Even if not causing an active problem now, are we likely going to want to add any additional features into
pulsar.shthat would benefit from it being in the.desktopExec?One other small issue with hard linking the path to the binary makes this non-portable and non-relocateable without manual editing. Ideally we should always be executing from a location on
$PATH.AppImage exception
A little weird curiosity we have here is our AppImage. What happens there is a little different because we do have a .desktop but, as it is a self-contained application, it doesn't actually use it directly. Instead what it does is the
AppRunscript will runpulsar.shto launch the main application.This actually does have an undesirable side-effect which is raised here: #1581
What can or should we do?
Like with the rpm and deb packaging issue, I think we should at the very least do the following:
electron-builderscript so that we do at least produce the mime type values as well as a few other itemsExecback topulsar.shfrom/opt/Pulsar/pulsarATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=falseand--no-sandboxshould be added to theExectar.gzwhen packaged.Pulsar version
1.132.1
Additional Information:
Pulsar team members can find a thread on Discord at https://discord.com/channels/992103415163396136/1508277521966301264/1508277534100295691 that goes into my initial findings and discussion with @savetheclocktower about them.