Linux support

[wearhere]

(Copied from #62 (comment))

I don't need to support Linux at the moment, but I'd definitely take a pull request. A rough sketch of tasks:

• support building for Linux — see if adding the appropriate platform/arch object to Meteor.settings.electron.build just works
• support setting the app icon on Linux — will need to be handled differently than for Mac/Windows, see https://github.com/maxogden/electron-packager 's README
• support downloading the Linux app - probably just a matter of parsing the download URL here but I don't have a sense of what that looks like (is it an installer like on Windows, or a (zipped form of?) the app itself like on Mac?)
• support remote updates

On the last note, I've heard that Electron's auto-updater framework doesn't actually support Linux—it's recommended that you update the app just via the system package manager. In that case, I don't know if there's anything for meteor-electron to do, I'd just want to document this in its README.

[cgalvarez]

Hi @wearhere.

I'm very interested in adding Linux support to meson:electron, so I've forked the project today and achieved some things (developing and testing in Ubuntu 16.04):

Implemented:

• Providing platform and arch in Meteor.electron.settings.builds works flawlessly.
• Auto-detection of platform and architecture if not provided in Meteor.electron.settings.
• The extension and path of the electron executable are now fixed, and the package launches it successfully.
• Added a boolean variable IS_LINUX in server/createBinaries.js.
• Fixed the way of getting the absolute path of an icon (using path.resolve better than joining strings).
• 🆕 Packaging electron app into a linux installer (rpm/deb packages, both tested & build from Ubuntu Xenial 16.04).
• Downloading.
• Remote updates (including AppImage!).
• App icon working on taskbar and tray (tested only in Ubuntu Xenial 16.04).
• 🆕 Added a tray menu to show/quit the app (the default behaviour when closing through the x button is hiding it; this allows for closing it definitely or bringing it up again).
• 🆕 Build AppImages.

Roadmap:

• Building Windows installers from Linux.

Problems found:

• The icon does not show in the Ubuntu app launcher at the left of desktop (png format tested). Linux icons are finally working, in taskbar and tray (tested only in Ubuntu Xenial 16.04).
• When closing the app through the x window close button, the app is hidden (but not quit), and I cannot find a way to show it since there is no taskbar icon shown. Now the app icon is shown in the tray, allowing to show or quit the app.
• The electron executable launches, but I see nothing (don't know if it has to do with using angular2-meteor, because I've seen that iron:router is used in some places, but Angular2 has its own router). App loads flawlessly.

Tomorrow next round. Can you give some hints on what are the remote updates (app updates, electron updates)? I've started today with this package and electron and I'm a bit lost.

BTW, any volunteer(s) to lend a hand will be welcome!

[wearhere]

Hey @cgalvarez, neat to see this! Thanks for the thorough testing.

The electron executable launches, but I see nothing (don't know if it has to do with using angular2-meteor, because I've seen that iron:router is used in some places, but Angular2 has its own router).

Hm, I don't think the UI framework would matter since this package loads your app from the root URL specified in settings/environment variables, i.e. if your root URL is https://myapp.com and you can load that in the browser, it should load just fine in meteor-electron.

Can you give some hints on what are the remote updates (app updates, electron updates)?

Remote updates are for updating the part of the app that interfaces with the OS—to change the app icon, to add a menu bar icon, etc. For updating your app's UI, hot code push will work just like it does on the web, since the app is loading the UI from the web.

[cgalvarez]

@wearhere You're right. The UI framework has nothing to do. It was my fault (set the wrong Meteor.electron.settings.rootUrl). Removed it and now can see the Meteor app.

Regarding the linux packages for downloading, I think the best way to accomplish this is through the NPM packages electron-installer-debian and electron-installer-redhat. They seem to build rpm (redhat/fedora) and deb (debian/ubuntu) packages from electron-packager builds, so the integration should work fine.

Going to start with them. Checklists updated. Any approach/ideas will be welcome.

[cgalvarez]

I've added a new subfolder next to "builds" called "installers".

It acts as intermediate folder where all the installers are saved.

Now meteor-electron can build deb/rpm installers, and I've tested and built both from Ubuntu Xenial. The distro detection relies on lsb_release, so, first of all, the linux user should have it installed to autodetect its distro (ubuntu, centos, redhat, opensuse, debian, fedora,...).

In order to build a deb/rpm installer, the system must have some packages installed. When using Ubuntu, if these packages are not installed (dpkg and fakeroot for deb, rpm for rpm), then user is warned through the command line and the build is skipped. I don't know their equivalent packages in the other systems (debian, centos, gentoo, fedora,...), but it can be easily fixed by customizing the deps object inside buildLinuxInstallers function.

I've installed the built deb installer in Ubuntu: the icon shows in the app launcher and the app launches and loads content successfully.

There is an error in the code because the app shows with the name "Electron". This is due to appName taking the default from the electronSettings.json of the vanilla electron app package. It should be overwritten when provided through Meteor.electron.settings.rootUrl.

There is a new option Meteor.electron.settings.installer, similar to icon. It's an object with keys being the platform (darwin/win32/linux), although it only works with linux at this moment. This options is used to provide extra parameters to the packages electron-installer-debian and electron-installer-redhat that cannot be extracted from the current existing options. For example, you must provide license to create rpm installers, and apt shows errors if the app was installed but maintainer was not provided when building the installer.

An example of these new parameters could be:

{
  "electron": {
    ...
    "name": "meteoric-electron",
    "installer": {
      "linux": {
        "license": "MIT",
        "maintainer": "Carlos Garcia",
        "productName": "Meteoric Electron!"
      }
    }
}

[cgalvarez]

On the last note, I've heard that Electron's auto-updater framework doesn't actually support Linux—it's recommended that you update the app just via the system package manager. In that case, I don't know if there's anything for meteor-electron to do, I'd just want to document this in its README.

Looking into electron autoUpdater docs, I can confirm what @wearhere have heard:

There is no built-in support for auto-updater on Linux, so it is recommended to use the distribution’s package manager to update your app.

That's absolutely horrible!

Your hint on updating the app via the system package manager (which is the recommendation from the electron docs too) requires:

• Developer:
  • Signing up into the PPA system.
  • Signing (with a GPG key/fingerprint) the installer each time it is rebuilt.
  • Submitting it to some PPA (which stands for Personal Package Archive, like launchpad for Ubuntu)
• User:
  • Adding the untrusted PPA to the system (i.e., sudo add-apt-repository ppa:user/ppa-name in Ubuntu).
  • Pulling down the latest list of software from all the trusted repos (i.e., sudo apt-get update in Ubuntu).
  • Installing the app updated package (i.e., sudo apt-get install --only-upgrade <app-installer>) or, in the most optimistic approach, getting notified through the software center and updating through it.

Anyone interested can check steps here. IMO, this seems too much interaction and steps for both, the developer and the user. Some steps could be automated, but following the spirit of keeping things simple, I did some research and came across electron-asar-updater. It's a NPM package that handles updates of the asar file of the app.

The filesizes for the app I'm using for testing are as follows:

• deb installer: 27.041 kb
• rpm installer: 37.283 kb
• asar file: 162 kb

Holy s***! So I'm definitely going with electron-asar-updater to implement the auto-update feature (0,43% out of the maximum installer filesize, which is really amazing; saves server bandwith; faster updates; avoids all the PPA issues; and enables for auto-updates from the electron app itself).

I think it is the best way to do this, but I'm open to other suggestions or different approaches.

I'm looking into a way of copy the asar file directly to the Meteor's public folder with a token to restrict updates to signed apps (like myapp.com/download/asar/latest/:token, and keep an archive of the built installer versions into different folders in Meteor's private folder (like appfolder/private/version/).

Suggestions/improvements are welcome!

[cgalvarez]

Just discovered electron-builder, which can build linux installers too. Windows installers can be built from Linux installing some prerequisites (cool!), and building dmg for OS X should be possible with appdmg, but the last ones can't be signed) can't be signed, so my happiness in a hole 😭).

It is also worth reading the multi platform build at electron-builder wiki.

Windows installers can also be built from Linux with NPM package electron-installer-windows, developed by the same author as the other two NPM packages I've already used to build deb/rpm.

Reading this issue I found the AppImage which is a portable self-executable format (no need to install) running all common Linux distributions. Seems very interesting.

[cgalvarez]

Downloading installers working now!

I had to adapt code due to the multiple formats available for Linux.

One question for @wearhere: I had no router package installed (neither iron:router nor meteorhacks:picker), so I was defaulting to WebApp.rawConnectHandlers during testing, but here req have no path member. Instead, I've used req._parsedUrl.pathname (don't know if this is only happening to me, using Meteor.js v1.3.3.1).

In addition, platform is retrieved from the req.query object here, but this object seems to be set only when using meteorhacks:picker. I can confirm that it is missing when defaulting to WebApp.rawConnectHandlers, so I've set it here if a query string exists in the URL.

No one else has happened this issue?

BTW, still need to fix the remote auto-updates before making the pull request, but please, everyone interested in this can test it by simply cloning the fork in the packages subfolder inside their meteor project(s) with the following commands:

cd /my/meteor/app/dir
mkdir -p packages
cd packages
git clone [email protected]:cgalvarez/meteor-electron.git electron

Meteor will use the fork without affecting your current meson:electron package, and will allow you to provide feedback before the pull request. The readme is also updated with all the new changes to get Linux support.

[probonopd]

@cgalvarez Try the Atom AppImage to find out whether this might be an option for you:
https://bintray.com/probono/AppImages/Atom/_latestVersion#files

[cgalvarez]

@probonopd thanks for pointing me in the right direction. I've found the AppImageKit wiki and your AppImages project, which contains your recipe for Atom. I will give it a chance, for sure, since Atom is also based on Electron. Thank you very much again!

[cgalvarez]

Remote updates working now for Linux. Keep working on the found issues.

[develar]

@cgalvarez electron-builder will support AppImage target next week.

[develar]

Also, electron-builder provides docker images to build Linux on Windows or just to avoid any setup. https://github.com/electron-userland/electron-builder/tree/master/docker

[cgalvarez]

@wearhere Just made a pull request for adding Linux support (first complete version). Building Windows installers from Linux and support for AppImage are in my roadmap.

[cgalvarez]

@develar Thanks! I'll take a look at it asap.

[mrzafod]

@cgalvarez, hi! Why your PR is closed now? Could we just use your fork for now while it isnt in official package?

[cgalvarez]

Hi @mrzafod. I closed the PR because I found some bugs just after pulling it, so I closed it, fixed those bugs and went on making more improvements. I didn't pull it again because still cannot build Windows installers from Linux (not implemented).

My fork is fully functional and documented (in readme and with jsdoc blocks). You can use it, of course. Clone the repo with git clone [email protected]:cgalvarez/meteor-electron.git /abspath-to-your-meteor-app/packages/electron and then install it with meteor add meson:electron.

Please, provide feedback after using it. I've enabled the issues for my fork, so if you found any related issue, please open it there, so we don't pollute the official project 😉