Open wearhere opened 8 years ago
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:
platform
and arch
in Meteor.electron.settings.builds
works flawlessly.Meteor.electron.settings
.IS_LINUX
in server/createBinaries.js
.path.resolve
better than joining strings).x
button is hiding it; this allows for closing it definitely or bringing it up again).Roadmap:
Problems found:
png
format tested)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 shownangular2-meteor
, because I've seen that iron:router
is used in some places, but Angular2 has its own router)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!
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.
@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.
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!"
}
}
}
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:
sudo add-apt-repository ppa:user/ppa-name
in Ubuntu).sudo apt-get update
in Ubuntu).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 kbrpm
installer: 37.283 kbasar
file: 162 kbHoly 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!
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 :sob:).
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.
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 git@github.com: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.
@cgalvarez Try the Atom AppImage to find out whether this might be an option for you: https://bintray.com/probono/AppImages/Atom/_latestVersion#files
@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!
Remote updates working now for Linux. Keep working on the found issues.
@cgalvarez electron-builder will support AppImage target next week.
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
@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.
@develar Thanks! I'll take a look at it asap.
@cgalvarez, hi! Why your PR is closed now? Could we just use your fork for now while it isnt in official package?
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 git@github.com: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 :wink:
(Copied from https://github.com/electron-webapps/meteor-electron/issues/62#issuecomment-174344468)
I don't need to support Linux at the moment, but I'd definitely take a pull request. A rough sketch of tasks:
Meteor.settings.electron.build
just worksOn 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.