[Linux] Add nativefier apps to menu / create FreeDesktop .desktop files

[ghost]

Programs which are created with nativefier won't appear in the application menu.

I am a Linux-user (Linux Mint) and when i create a new app with nativefier I always have to create a .desktop file by myself to add the app to my application menu. It is not a big deal to make it by myself but it is boring after some time. So it would be nice to have a feature build in nativefier which makes this for the user.

Improvements

• Easier to find
• More like a native app
• Easier to start the app

Code

Here is a little help if you need it: https://community.linuxmint.com/tutorial/view/1504
The .desktop file should be in the same directory like the created application.

Here is a little example for a .desktop file for whatsapp:

[Desktop Entry]
Comment=Whatsapp created with nativefier
Terminal=false
Name=Whatsapp
Exec=/the/folder/of/the/Webapp/Whatsapp
Type=Application
Icon=/the/folder/of/the/Webapp/resources/app/icon.png
Categories=Network;

Thanks

However, thank you for this usefull tool. I am also sorry for my bad english.

[ghost]

Edit

The .desktop file should be in:

/home/$USER/.local/share/applications

[eduardo-robles]

@flofreitag I agree that it should be easier for a user to be able to open the a Nativefier app after it is created. Though I'm wondering if creating a .desktop file is a job that should be relegated to Nativefier? My thinking was to contribute .desktop files for various apps that user may end up using.

I'm not sure what's the best approach to solve this problem. Having .desktop is part of the solution but not the full solution I think.

[mlncn]

To start with it needs to be documented that users on Debian, at least, will need to do this for the nativefied application to work as we expect a native application to work— launchable by application launchers, findable in the OS menu. Very grateful to ghost for having this issue, which served as the critical documentation for me! I'd say it's a core enough feature that it should be built into nativefier, if not by default on Linux than with a flag.

[mlncn]

Note also that once an application has a .desktop file in ~/.local/share/applications, the Nativifier-created application will work from launchers also.

[darrenhaken]

@mlncn I have found that if i manually create a desktop app and save it to the doc when I open the app it creates a second instance of it alongside the other. Have you seen this?

Something like WhatsApp and WhatsApp{sha}

[mvoropaiev]

@darrenhaken same here, Fedora 25 with Gnome, as you can see on screenshot, the first Trello icon is a pinned one after making a .desktop file, but after clicking it a second one appears (I run nativefier with --name argument, but the actual name still has -nativefier-769e8e in it for some reason)
Have also tried with changes from #323 with no luck

[mvoropaiev]

Actually a name can be easily fixed by editing a resources/app/package.json inside the application directory, but it does not solve the "double icon" issue.

[tdgroot]

@mvoropaiev @darrenhaken You're missing a setting in your desktop file. This has to do with the WM_CLASS of your window. You have to set StartupWMClass in your desktop file to the same WM_CLASS of your window.

To find out the corresponding WM_CLASS, please run the command xprop WM_CLASS and then click your window.

Here's an example desktop file:

[Desktop Entry]
Version=1.0
Type=Application
Name=1Password
Icon=...
Exec=...
Comment=1Password
Categories=Development;Office;
Terminal=false
StartupWMClass=1-password-nativefier-4a0ed2

[darrenhaken]

@tdgroot that helped with the issue actually! Now when I launch the application it reuses the same window. It does however launch a second version of the app rather than simply using the one which is already open. Make sense?

[alxlg]

Hi, I started Nativefier Freedesktop here on GitHub to provide the best integration on Linux desktop. Feel free to look at it for inspiration or helping to finish it.

[quanglam2807]

@ghost Try https://getwebcatalog.com

[alxlg]

@quanglam2807 I think you are exaggerating: you suggested your tool as an alternative to Nativefier to a lot of issues. I tried your app, it's cool but it has different purposes than Nativefier.
You can use Nativefier to every URL you want, also very personal favorites. Yours instead is a store of web apps you decide.

[quanglam2807]

@alxlg That's why I created #333. I need to understand the use cases first to develop.

So what you need is a CLI which works with any URL? Is that what you want?

[alxlg]

@quanglam2807 Nativefier does everything I need thanks. Installation should be by design out of scope for Nativefier. That's why I started Nativefier Freedesktop that is a tool to automate the installation of Nativefier apps on Linux desktops.
All in one tools don't follow the Unix philosophy. Do one thing but do it well. I hope it's clear what I mean.

[quanglam2807]

@alxlg All in one? You are exaggerating. Nativefier creates a Electron container for each app. WebCatalog creates a shortcut. Which one is more exaggerating? You don't need it, but others may. The point is not to create software for advanced users like you who understand "Unix philosophy" but to create software people can use easily. By the way, I'm tagging @ghost, not you.

[alxlg]

@quanglam2807 but I have to see your spam in a lot of Nativefier issues. Doesn't WebCatalog has its own UI? My Nativefier Freedesktop will be very easy to use and totally follow Freedesktop spec for Linux desktop, there is no need to compile anything since it's a bash script.
For example: does WebCatalog support creating a Web App of a custom URL injecting CSS and JS? That wouldn't for noobs, no? That's why you need to define an input that is more complete than a URL. I defined *.webapp files for the purpuse of being easily installable by users and I wrote a wizard to create *.webapp. Everything for non-geek users. I tried your WebCatalog, next time before replying trying my Nativefier Freedesktop and objectively judge which one is better for this issue.

[quanglam2807]

@alxlg I'm not spamming randomly. People are looking for solution and as this repo is no longer maintained, I don't see any problem suggesting an alternative. And of course, it takes you so many sentences to explain what it does so it's complicated and for noobs. :)

[alxlg]

@quanglam2807 once installed the user can click on *.webapp files and install them as Freedesktop apps. And *.webapp files can include custom CSS and JS. Is it enough short as explanation?

[quanglam2807]

@alxlg So they still need to click the webapp file, they still need to find the URL, they still need to find an icon, they still need to update the app manually later. And injecting CSS and JS is coming to WebCatalog. Does Freedesktop works on macOS and Windows? I feel like you are pitching about your project and then being upset because I disrupt you with mine.

[alxlg]

@quanglam2807 no, they just need to click on a .webapp file that contains everything. They will be able to uninstall webapp from their menu and they will be able to update them from there.
My project is explicitly for this issue: managing Nativefier apps on Linux. Yours is a new Nativefier with apps choosen by you, or am I wrong?

So are you going to add Linux desktops support without knowing what Freedesktops are? Good luck. MacOS and Windows? Are you kidding me? I said from the first moment I did a script for Nativefier+Linux and I said "do one thing and do it well". On the other side there is you with your all-in-one solution that don't know what Freedesktop is. And notice that I just said in the first comment: take a look at my script for inspiration, I don't say "try my all-in-one solution" without an exaplanation as you are used to do in Nativefier issues.

[darrenhaken]

Can you take this to a private chat or something? It's off topic and I don't feel it's respectful. It's good to have diverse products (also a Unix philosophy)

[quanglam2807]

@darrenhaken Kudo!
@alxlg You are wrong. Check my first reply to you in which I mentioned #333. It's coming. And why are you talking about Freedesktop and your app? When I mentioned WebCatalog in my first comment, I have never commented anything about your app and then you jumped in. The point I am trying to make is that my app has its advantages. I did not try to objectively judge which one is better for this issue; I simply suggested a solution Try https://getwebcatalog.com and for a reason, you tried to take this conversation elsewhere.

[alxlg]

@quanglam2807 I already said that your WebCatalog has nothing to do with this issue. I specifically wrote a solution for this issue and I commented only here suggesting to take inspiration from it. You commented on a big amount of Nativefier issues just saying "try WebCatalog". Though yours is a very cool app, stop suggesting a totally different app to people that are commenting an issue of Nativefier. If your WebCatalog solves that issue is OK, but your WebCatalog doesn't use Freedesktop specifications so it has nothing to do with this issue.
Probably you have no idea what this issue is about and you are trying to promote your app without really know if it solve this issue or not.
Please before replying again search what Freedesktop is so you will be able to understand why Nativefier Freedesktop tries to solve this issue while WebCatalog not.

[alxlg]

@darrenhaken did you notice that @quanglam2807 commented on an enormous amount of Nativefier issues saying to try WebCatalog that is a totally different thing and often has nothing to do with the issues he comment? Isn't it spam?

[quanglam2807]

@alxlg

• Create a desktop application for any web site with succinct and minimal configuration.
• Add apps to menu.
• Use Electron

that is a totally different thing?

[alxlg]

@quanglam2807 it doesn't use Nativefier. It's like spamming Firefox bug tracking system with suggestions to use Chrome. Yes both Chrome and Firefox are used to browse the Web, but issue tracking systems shouldn't be used to promote totally different software.

If I can build an app from a URL I choose with Nativefier and then your tool add that to app menu I will recognize that your tool is a solution to this issue.

[quanglam2807]

@alxlg In your point of view. But as @darrenhaken suggested, I think we should stop.

[alxlg]

@quanglam2807 if this is the last time I see you promoting WebCatalog in Nativefier issues tracker.

[quanglam2807]

@alxlg I don't promote. But I'll mention WebCatalog if it is relevant to any issue.

[leonidasv]

A little bit late, but I just submitted a Pull Request solving this issue: #729

[ronjouch]

@alxlg @darrenhaken @eduardo-robles @ghost @leonidas @mlncn @mvoropaiev @quanglam2807 @tdgroot : I'm looking at @leonidasv 's PR adding automatic creation of .desktop files: #729 .

• I'm okay with that, because it feels like reasonable OS-specific hygiene, and is (as witnessed by this very issue) what users expect.
• And I would like to avoid yet-another-commandline-flag (we already have a million billions of them). So, a user who does not want launchers (e.g. if packaging for another machine), would have to remove the launchers after nativefying.

Is everyone okay with such an {automatic, not disableable} creation, or does anyone have a good reason to require a flag?

If you're all good, vote this comment with a 👍. If you oppose, vote 👎 and add a comment explaining why.

[tdgroot]

@ronjouch @leonidasv looks good! To me this seems like default behaviour, so you have my 👍.

[anaibol]

+1

[ronjouch]

So, #799 (a duplicate of this issue) reminded me this issue is still open, and I didn't merge PR #729 (sorry @leonidasv), for a reason I never took the time to explain, so here it is.

The problem is that once a user creates a Nativefier app, they will often move it to wherever they please (for example, to /opt/ or whatever "applications" folder), of course breaking any .desktop file pointing to the old path. It's unreasonable to expect users to not move their apps; Nativefier isn't an installer. So, we must assume they will.

People want automatic creation of .desktop launchers because they're not as easy to create as a Windows shortcut or dragging an app in your Mac Applications folder. But as the app bundler, since we have no idea what the final target is, we cannot do a good job at reliably creating the .desktop launcher. This is typically a distribution concern, because it's the distro's job to decide where things are in the filesystem. Also, given .desktop files are meant to show up as a launcher (which they are), sometimes the extension is hidden, users are easily confused as to how to edit them, they may not understand they are text files, and then badly save them without the .desktop extension, or not knowing where to put them.

So, and re-considering the potentially menu-polluting-with-broken-links consequences of #729, here's pseudocode for what I think could make sense:

• On finishing building an app, if the target OS is Linux,
  • Automatically create a .desktop file in the output app folder, e.g. WhatsApp.desktop, pre-populated with reasonable entries and the current path (potentially obsolete after a move). But do not move it to the OS XDG applications folder. Instead,
  • Next to it, create a help file explicitly named (e.g. WhatsApp_README-LAUNCHER-SHORTCUT.txt), explaining to novice users what to do with this file, the need to edit it if the application is moved, and how to edit it. Later below is what it could look like.
  • Change the Linux-specific build success help message to mention looking at this README if you want a launcher.

If that makes sense, PR / rework of PR #729 welcome. Yesterday I put a little helper text telling about the .desktop file and guiding them to create it, but the extra help would be welcome, to the extent of what Nativefier can do. Makes sense?

---

WhatsApp_README.txt could look like (with templating replacing the s):

Your Nativefier app for <URL> is ready in this folder.
To run it, just launch the contained executable with ./<APPNAME>

If you want a launcher for your desktop environment's menu (GNOME, KDE, etc.),
an example `.desktop` file was created in this folder, `<APPNAME>.desktop`
(note the `.desktop` extension may be hidden by your desktop environment).

To use this `.desktop` file, please run the following command:
    mv <APPNAME>.desktop ~/.local/share/applications
but remember to update it if you move the Nativefier app.

Editing it is easy, it is a plain text file, open it with your favorite
text editor, adjust the path (and other config if you wish) and save it.
For more help, search for "linux .desktop entry" for help, or see
https://wiki.archlinux.org/index.php/Desktop_entries`

[cassidyjames]

@ronjouch I think the approach works, or alternatively this text could just be output in the Terminal instead of a separate README file. But either works, and each has its pros/cons. I also understand that it might feel outside the realm of Nativefier to install the app locally, though I think that is what people on Linux would want when using Nativefier. But again, a separate tool could also be in charge of moving the files into the right places to "install" them, if so desired.

Either way, at least generating a usable .desktop file out of the box would seem to be a big improvement to me. 👍

[ronjouch]

I think the approach works, or alternatively this text could just be output in the Terminal instead of a separate README file.

@cassidyjames my intention behind suggesting writing an extra README file is that I anticipate users looking at the .desktop file and thinking "oh where should I put this, again? How do I edit it?". The extra file adds a tiny bit of clutter to the output dir, but will be here when these users will need it without the need to search the web or start a new Nativefier build just to get the help again.

But either works, and each has its pros/cons. I also understand that it might feel outside the realm of Nativefier to install the app locally, though I think that is what people on Linux would want when using Nativefier. But again, a separate tool could also be in charge of moving the files into the right places to "install" them, if so desired.

I agree what most people want is a launcher entry straight in their menu, and it's exactly what PR #729 does. But given the high potential for breakage due to moving an app after build, I think it was a bad idea.

[alxlg]

@ronjouch I know it but again: the right way to install third party apps on Linux/Freedesktop is using Flatpak, not adding a .desktop launcher that execute a binary in a fixed user folder.

Otherwise you could add a parameter that:

• move the output files to ~/.local/bin
• add a .desktop launcher that points there
• (some DE support quick actions defined in the .desktop file) add a quick action, "Uninstall", that delete the corresponding files and the launcher so that the user can do right-click on the launcher > Uninstall

[Natetronn]

I've been creating my own .desktop files over and over again by copying from an older Nativefier to the newer one and replacing all the paths, categories, keywords, icons and names etc. I often forget the path for the .desktop files so I even wrote an alias to help me move the file into place after I finish editing it:

# move a .desktop file to user application folder
function desktop() {
  file="$1"
  if [[ $file == *.desktop ]]
  then
    cp $file ~/.local/share/applications
    echo "File successfully copied to user-specific applications folder."
  else
    echo "Please provide path filename argument"
  fi
}

(~/.zshrc, ~/.bashrc, ~/.profile etc.)

I could take this further on my own but, it sure would be nice if Nativefier was able to chip in here a bit from the get go.

What I'd like to see is the creation of the .desktop file at build time and have it placed in the build folder with current paths completed (like in the PR) and then we can move the file and adjust paths accordingly, on our own accord.

Anyone who knows what a .desktop file is will know they have to edit paths. Anyone who doesn't know what a .desktop file is or is looking for what amounts to a .desktop file is going to start googling or asking around and subsequently find out what they are and learn how to manage them; including where they need to live in order to show up in menus etc.

If done this way and it's not used it can move along with the app folder, no harm no foul. Then for those of us who'd like to use it, we will know what to do with it (or start googling and learn, like all those who've used Linux before us have had to do.)

[Natetronn]

Maybe if the PR is wrapped in a flag with a help comment that states, something along the lines of, "note: if you move the .desktop file to your user application folder or similar location, usually ~/.local/share/applications/, this to have it show up in the menus, you'll need to edit the paths directly in the .desktop file itself."

Or something like that. Would that be sufficient?

Anyone who is using the flag or learning about it for the first time will now know they have to edit the paths and potentially understand where .desktop files should live too.

[ronjouch]

@Natetronn yup and that's exactly what #204 (comment) suggests. PR welcome 🙂.

[alxlg]

My comment was marked as off topic but it's relevant. If you are talking about .desktop files you are talking about INSTALLATION and that includes:

* move the output files to ~/.local/bin

* add a .desktop launcher that points there

and also moving the icon in the icons folder. Please don't break Freedesktop spec by pointing the .desktop file to some random path for the executable and the icon.

[matthewruzzi]

I created a zenity interface for nativefier that automatically creates and installs .desktop files.
https://github.com/mattruzzi/nativefier-zenity

[bdombro]

I too made a script:

NAME=Fastmail
URL=https://fastmail.com
ICON_PNG_URL=https://www.fastmail.com/static/favicons/touch-icon-196x196.png
DESCRIPTION=Social

cat << EOF > /tmp/inject.css
EOF


cat << EOF > /tmp/inject.css
EOF

mkdir apps &> /dev/null
cd apps
rm -rf "$NAME" "/usr/local/lib/$NAME" &> /dev/null

echo "$CSS" > "/tmp/inject.css"
echo "$JS" > "/tmp/inject.js"

nativefier "$URL" --single-instance --name "$NAME" --inject /tmp/inject.css --inject /tmp/inject.js
mv "$NAME-linux-x64" "$NAME"

if [ -n "$ICON_PNG_URL" ]; then
	ehco OVERRIDE
	curl -o "$NAME/resources/app/icon.png" "$ICON_PNG_URL"
fi

cp ../bootstrap.sh "$NAME/"
echo "[Desktop Entry]
Type=Application
Version=1.0
Name=$NAME
StartupWMClass=`jq -r '.name' "$NAME/resources/app/package.json"`
Comment=$DESCRIPTION
Exec=/usr/local/lib/$NAME/$NAME
Icon=/usr/local/lib/$NAME/resources/app/icon.png
Terminal=false
Categories=GTK
MimeType=text/html;text/xml;application/xhtml_xml;
" > "$NAME"/"$NAME".desktop
chmod +x "$NAME"/"$NAME".desktop
sudo cp -rf "$NAME" "/usr/local/lib/"
sudo mkdir /usr/local/share/applications &> /dev/null
sudo cp "$NAME/$NAME.desktop" /usr/local/share/applications/