Giter Club home page Giter Club logo

meteor-electron's Introduction

meteor-electron

meteor-electron lets you easily transform your Meteor webapp to a desktop app. Its ultimate goal is to build meteor add-platform desktop.

Some of the things it does:

  • automatically builds and launches a desktop application, rebuilding when the native code changes
  • defines feature detection APIs and a bridge between web and native code
  • serves downloads of your application and update feeds

Getting Started

meteor add meson:electron

meteor-electron will download the Electron binary for your system and build and launch an Electron app pointing to your local development server. The download process may take a few minutes based on your Internet connection but only needs to be done once.

The app, as well as the ready-to-distribute binaries (see Deploy), is built within YOUR_PROJECT_DIRECTORY/.meteor-electron. This allows the apps to be easily located as well as the builds to be cached for speedier startup. You should add this directory to your .gitignore.

Configuration

Configuration is possible via Meteor.settings.electron. For example,

{
  "electron": {
    "name": "MyApp",
    "icon": {
      "darwin": "private/MyApp.icns",
      "win32": "private/MyApp.ico"
    },
    "version": "0.1.0",
    "description": "A really cool app.",
    "rootUrl": "https://myapp.com",
    "launchPath": "/app/landing",
    "downloadUrls": {
      "win32": "https://myapp.com/download/win/",
      "darwin": "https://myapp.com/download/osx/{{version}}/MyApp.zip"
    },
    "sign": "Developer ID Application: ...",
    "height": 768,
    "width": 1024,
    "frame": true,
    "title-bar-style": "hidden",
    "resizable": true,
    "protocols": [{
      "name": "MyApp",
      "schemes": ["myapp"]
    }],
    "appSrcDir": "private/app"
  }
}
icon
platform dependent icon paths relative to application root
version
must confirm to semver
rootUrl
If unset, defaults to the `APP_ROOT_URL` and then `ROOT_URL` environment variables, in that order.
launchPath
If you want your app to open to a non-root URL. Will be appended to the root URL.
downloadUrls
URLs from which downloads are served. A CDN is recommended, but any HTTP server will do.
downloadUrls.win32
Copy the output of `grunt-electron-installer` (see Building and serving an auto-updating Windows app) to this location. Do not rename the files. If you wish to host the Windows installers at versioned URLs for caching or archival reasons, specify this as an object with the following keys.
downloadUrls.win32.releases
Copy the output of `grunt-electron-installer` (see Building and serving an auto-updating Windows app) to this location. Do not rename the files.
downloadUrls.win32.installer
If you like, you may copy the `Setup.exe` file created by `grunt-electron-installer` to this location rather than the "releases" location. If the URL contains '{{version}}', it will be replaced with `version`.
downloadUrls.darwin
Place the latest app at this location. If the URL contains '{{version}}', it will be replaced with `version`.
sign
Must be set to enable auto-updates on Mac.
appSrcDir
A directory of code to use instead of meteor-electron's default application, relative to your app's project directory. See warning below.

Electron-specific code

By default, all client web code will be executed in Electron. To include/exclude code use Electron.isDesktop

if (!Electron.isDesktop()){
  showModal("Have you considered downloading our Electron app?");
}

Deploying

Hot code push will work to update your app's UI just like it does on the web, since the app is loading the UI from the web. If you want to update the part of the app that interfaces with the OS, though—to change the app icon, to add a menu bar icon, etc.—you'll need to distribute a new version of the .app or .exe. Here's how to do that.

Building and serving an auto-updating Mac app

  1. Set Meteor.settings.electron.autoPackage to true to ZIP your app for distribution after it is built.
  2. If you wish to enable remote updates, you will need to codesign your application. This requires that you build your app on a Mac with a Developer ID certificate installed. Set Meteor.settings.electron.sign to the name of that certificate.
  3. Wait for the app to finish building and packaging, then copy YOUR_PROJECT_DIRECTORY/.meteor-electron/darwin-x64/final/YOUR_APP_NAME.zip to a publically-accessible location.
  4. Set downloadUrls.darwin in Meteor.settings.electron to the URL of the location where you copied the ZIP.

Downloads of the Mac app will be served at your webapp's ROOT_URL + /app/download?platform=darwin.

Building and serving an auto-updating Windows app

  1. Make sure that you have specified name, version, and description in Meteor.settings.electron.
  2. Build the app on a Mac, because changing a Windows application icon does not work on Windows at present.
  3. Ensure the URL specified by Meteor.settings.electron.downloadUrls.win32 has an empty RELEASES file.
  4. On a Windows machine or in a Windows VM (not a Mac, at present), run the electron installer grunt plugin against your app. Your Gruntfile should look something like https://github.com/rissem/meteor-electron-test/tree/master/.test. The value of remoteReleases should be your webapp's ROOT_URL + '/app/latest'.
  5. Copy the output to the server serving Meteor.settings.electron.downloadUrls.win32, to be served from that location.
  6. When you publish a new update, run the installer again and it will generate diffs, a new RELEASES file, and new installers. After copying these to Meteor.settings.electron.downloadUrls.win32 again (overwriting the RELEASES file and installers), apps that check for updates should receive a new version.

Downloads of the Windows installer will be served at your webapp's ROOT_URL + /app/download?platform=win32.

Building for Windows on Mac

  1. Install homebrew
  2. brew update
  3. brew install wine
  4. Specify a Windows build in your settings (otherwise defaults to current platform (mac)).
{
  "electron": {
    "builds": [
      {"platform": "win32",
       "arch": "ia32"}
    ]
  }
}

Example

[TODO] Link to an awesome chat app

Q&A

Q: How is this different from all the other Meteor electron packages?

This package differs from Electrometeor and Electrify by not baking Meteor into the packaged app. This makes things significantly simpler, but if you need strong offline support, one of them is a better solution.

Q: How can I create new browser windows, set app notifications and all the other awesome native functionality that Electron gives me?

This project selectively exposes such functionality to the client, in a way that is safe and avoids memory leaks, via the Electron module--see client.js. To request that this module expose additional functionality, please submit a pull request or file an issue.

You may also substitute your own application code for meteor-electron's default application by setting the appSrcDir settings option. meteor-electron will continue to package your application and serve the application update feed and download URLs, but in-app functionality will be your responsibility. Warning: this responsibility includes setting up your application window and menu, checking for remote updates, registering the Electron module (that defines Electron.isDesktop), and possibly other things. If you take this route, it's recommended that you start by copying meteor-electron's app directory.

Also, you also probably want to keep your application code in a subdirectory of your application's private directory so that Meteor will observe changes to it and restart the server; when it does so, meteor-electron will rebuild and relaunch the app.

Q: How do I prevent the Electron app from being automatically built and launched?

Set Meteor.settings.electron.autoBuild to "false".

meteor-electron's People

Contributors

chanpory avatar primigenus avatar rdickert avatar rissem avatar rlqualls avatar simonbelanger avatar wearhere avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

meteor-electron's Issues

`Electron` object not present on Windows build

To reproduce: meteor create an app, build for Windows, and run it in Windows. Open the dev tools with xtrl-shift-I. Open the console with esc. In the console, Begin typing "Electron". You will see that ElectronImplementation is present, but Electron is not. Compare to osx where both objects are present.

It's not clear to me why ElectronImplementation exists. It seems to have the same methods as Electron. In this case, it leads to a simple workaround in the app code:

Electron = Electron || ElectronImplementation;

But it would be nice to have the Electron object turn up properly on both platforms (and perhaps remove ElectronImplementation).

Support for Meteor 1.1

Just tried it with my production app and had a bit of trouble getting it to work since we still use Meteor 1.1.

Here's what I had to do to get it working:

  • change the versions in package.js to Meteor 1.1 equivalents.
  • use addFiles instead of addAssets.

Here's the git diff:

$ git diff
diff --git a/package.js b/package.js
index 57341a8..f274b78 100644
--- a/package.js
+++ b/package.js
@@ -20,8 +20,13 @@ Npm.depends({
 });

 Package.onUse(function (api) {
-  api.use(["[email protected]", "[email protected]", "[email protected]", "[email protected]"], "server");
-  api.use("[email protected]", ["server", "client"]);
+  var both = ['client', 'server'];
+
+  api.versionsFrom("[email protected]");
+
+  api.use(['underscore'], both);
+
+  api.use(["mongo-livedata", "webapp", "ejson", "promise"], "server");
   api.use(["iron:[email protected]||1.0.0"], {weak: true});

   api.addFiles([
@@ -35,14 +40,14 @@ Package.onUse(function (api) {
     'server/index.js'
   ], 'server');

-  api.addAssets([
+  api.addFiles([
     "app/autoUpdater.js",
     "app/main.js",
     "app/menu.js",
     "app/package.json",
     "app/preload.js",
     "app/proxyWindowEvents.js"
-  ], "server");
+  ], "server", {isAsset: true});

   api.addFiles(['client/index.js'], "client");

Should be able to support both without issue with some feature checking.

I'll put together a PR in a bit if you guys don't get to it first.

Version-based Windows cachebusting

Currently, we cachebust the Windows installer and RELEASES file using Date.now(). This is unnecessarily wasteful--we only need to bust the cache when the version changes. Thus, we should replace "?cb=" + Date.now() with "?version=" + Meteor.settings.electron.version.

minimize, maximize

I'm looking for a way to minimize and maximize (and unmaximize) the window.

We don't have access to the 'remote' object so I can't do something like:

window = remote.getCurrentWindow();

and then

// minimize-button clicked:
window.minimize(); // minimize

// maximize-button clicked:
if (!Electron.isFullScreen()) {
  window.maximize();
} else {
  window.unmaximize();
}

how do we minimize / maximize the window programmatically with this package?

Electron.isFullScreen() in browser throws error

client/index.js attemps to stub out Electron methods that could be inappropriately called from the browser by assigning _.noop to them. Unfortunately, Meteor apparently uses an old version of underscore that does not support that function, so Electron.isFullScreen & similar are undefined, and if you try to call them in the browser, you will get Uncaught TypeError: Electron.isFullScreen is not a function(…).

move to electron-builder

We needed some missing features and needed to build for win/lin/osx.

We ended up with a fork on https://github.com/risetechnologies/meteor-electron which also moved from electron-packager to electron-builder.

Why?

This project reinvents the wheel times too often, as a result it tries to solve all problems electron-builder and nuts already solved.

This is what we've done:

  • replace electron-builder with electron-packager
    • adopt to new configuration scheme
    • remove code signing and packaging implementation
    • remove npm rebuilder implementation
  • refactor and overhaul 50% app code, 100% server code
  • remove serve update implementation (let nut handle this)

Still rough and not tested very well, but at least we could easily build from osx for win/lin/osx.

As a lot of breaking changes have been done, I'm not sure if a merge is applicable. What do you think?

Build size too big

See electron/packager#142.

My buildsize is about 100mb for the osx- and x32 build, the x64 build is about 200mb in size.

How can I add the --ignore flag? Are there other options?

Wrong IronRouter version

I get this error after installing the package and starting my Meteor app :

=> Started proxy.
=> Started MongoDB.
=> Errors prevented startup:

   While selecting package versions:
   error: Potentially incompatible change required to top-level dependency: iron:router 0.9.4, was 1.0.12.
   Constraints on package "iron:router":
   * iron:[email protected] <- meson:electron 0.1.3

   To allow potentially incompatible changes to top-level dependencies, you must pass --allow-incompatible-update on the command line.

=> Your application has errors. Waiting for file change.

What exactly should I do? Downgrading caused a lot of issues. Should I pull-request and update iron-router?

Cant install this package because I get error: MINISAT-out: Cannot enlarge memory arrays.

Whenever I try to install this package into my Meteor 1.4 app I get the error

MINISAT-out: Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 67108864, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.
MINISAT-err: Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 67108864, (2) compile with ALLOW_MEMORY_GROWTH which adjusts the size at runtime but prevents some optimizations, or (3) set Module.TOTAL_MEMORY before the program runs.

/Users/Nearpoint/.meteor/packages/meteor-tool/.1.4.1_2.1r2z6b4++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/isopackets/ddp/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:165
      throw error;
      ^
abort() at Error
    at jsStackTrace (packages/logic-solver/minisat.js:3:1)
    at stackTrace (packages/logic-solver/minisat.js:3:1)
    at abort (packages/logic-solver/minisat.js:33:1)
    at enlargeMemory (packages/logic-solver/minisat.js:3:1)
    at Function.Runtime.dynamicAlloc [as alloc] (packages/logic-solver/minisat.js:3:1)
    at _sbrk (packages/logic-solver/minisat.js:3:1)
    at Sd (packages/logic-solver/minisat.js:7:1)
    at Ud (packages/logic-solver/minisat.js:7:1)
    at gc (packages/logic-solver/minisat.js:7:1)
    at pc (packages/logic-solver/minisat.js:7:1)
    at Kb (packages/logic-solver/minisat.js:7:1)
    at Dc (packages/logic-solver/minisat.js:7:1)
    at Object.dd [as _addClause] (packages/logic-solver/minisat.js:7:1)
    at packages/logic-solver/minisat_wrapper.js:74:1
    at Object._native.savingStack (packages/logic-solver/minisat_wrapper.js:37:1)
    at [object Object].MiniSat.addClause (packages/logic-solver/minisat_wrapper.js:68:1)
    at [object Object].Logic.Solver.solve (packages/logic-solver/logic.js:1326:1)
    at [object Object].Logic.Solver.solveAssuming (packages/logic-solver/logic.js:1369:1)
    at minMaxWS (packages/logic-solver/optimize.js:52:1)
    at [object Object].Logic.Solver.minimizeWeightedSum (packages/logic-solver/optimize.js:139:1)
    at packages/constraint-solver/solver.js:368:1
    at Function.time (/tools/tool-env/profile.js:305:10)
    at [object Object].CS.Solver.minimize (packages/constraint-solver/solver.js:352:1)
    at [object Object].CS.Solver.minimize (packages/constraint-solver/solver.js:346:1)
    at [object Object].CS.Solver._getAnswer (packages/constraint-solver/solver.js:735:1)
    at packages/constraint-solver/solver.js:603:1
    at Function.time (/tools/tool-env/profile.js:305:10)
    at [object Object].CS.Solver.getAnswer (packages/constraint-solver/solver.js:602:1)
    at packages/constraint-solver/constraint-solver.js:165:1
    at Object.Logic.disablingAssertions (packages/logic-solver/logic.js:45:1)
    at Function.CS.PackagesResolver._resolveWithInput (packages/constraint-solver/constraint-solver.js:164:1)
    at [object Object].CS.PackagesResolver.resolve (packages/constraint-solver/constraint-solver.js:128:1)
    at /tools/project-context.js:518:35
    at Function.time (/tools/tool-env/profile.js:305:10)
    at /tools/project-context.js:514:19
    at /tools/utils/buildmessage.js:359:18
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:352:34
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:350:23
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.enterJob (/tools/utils/buildmessage.js:324:26)
    at /tools/project-context.js:486:20
    at /tools/packaging/catalog/catalog.js:100:5
    at /tools/utils/buildmessage.js:271:13
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:264:29
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:262:18
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:253:23
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.capture (/tools/utils/buildmessage.js:252:19)
    at Object.catalog.runAndRetryWithRefreshIfHelpful (/tools/packaging/catalog/catalog.js:99:31)
    at ProjectContext._resolveConstraints (/tools/project-context.js:485:13)
    at /tools/project-context.js:268:9
    at /tools/utils/buildmessage.js:359:18
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:352:34
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:350:23
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.enterJob (/tools/utils/buildmessage.js:324:26)
    at ProjectContext._completeStagesThrough (/tools/project-context.js:258:18)
    at /tools/project-context.js:250:12
    at Function.run (/tools/tool-env/profile.js:489:12)
    at ProjectContext.prepareProjectForBuild (/tools/project-context.js:249:13)
    at /tools/cli/commands-packages.js:2034:20
    at /tools/utils/buildmessage.js:271:13
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:264:29
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:262:18
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at /tools/utils/buildmessage.js:253:23
    at [object Object].withValue (/tools/utils/fiber-helpers.js:89:14)
    at Object.capture (/tools/utils/buildmessage.js:252:19)
    at Command.func (/tools/cli/commands-packages.js:2033:27)
    at /tools/cli/main.js:1410:23
If this abort() is unexpected, build with -s ASSERTIONS=1 which can give more information.

Any suggestions on how to get this working?

Mac build for Windows

I'm able to build my app for a mac from a mac but i'm trying to build for windows but it doesn't seem to work. This is my Meteor.settings.electron file:

{
  "electron": {
    "name": "Test",
    "icon": {
      "darwin": "private/MyApp.icns",
      "win32": "private/MyApp.ico"
    },
    "version": "0.1.0",
    "description": "Test app",
    "rootUrl": "https://myapp.com",
    "launchPath": "/app/landing",
    "downloadUrls": {
      "win32": "https://myapp.com/download/win/",
      "darwin": "https://myapp.com/download/osx/{{version}}/MyApp.zip"
    },
    "sign": "Developer ID Application: ...",
    "height": 768,
    "width": 1024,
    "frame": true,
    "title-bar-style": "hidden",
    "resizable": true,
    "protocols": [{
      "name": "MyApp",
      "schemes": ["myapp"]
    }],
    "appSrcDir": "private/app",
    "builds": [
      {"platform": "win32",
       "arch": "ia32"}
    ]
  }
}

Close the window programatically

I can't find a way to close the window through code in the app.

If I'm missing something, it'd be awesome if someone could point it out.

Discuss deploying the server in the README

That is, discuss when to deploy app-related changes (at least a change to Meteor.settings.electron.version, possibly other things) relative to uploading the binaries.

Make sure to discuss how to solve releasing an update that requires new server functionality other than the change to Meteor.settings.electron.version: #48 (comment) #49 (comment)

Conditionally open the Electron app at startup

This is a great feature while working on the Electron app, but I can easily see it getting annoying when working on the webapp.

(Which I envision to be most of the time? Since Electron apps created using this tool will probably be a pretty thin shell around the webapp, and browsers' developer tools will probably be a bit richer than Electron's.)

Ways to do this include passing an environment variable to suppress/enable auto-launch or reading it from electronSettings.json.

Split meson:electron into 2 parts to eliminate dev dependencies from build

We are having trouble building our Meteor app on production the meson:electron. We are getting this error:

Errors prevented bundling:
While linking the program:
error: meson:electron is not compatible with architecture 'os.linux.x86_64'".  

The issue is that the webservers are linux so the build command is meteor build --architecture os.linux.x86_64 latestBuild.

It seems likely that it is the electron build tools that are causing this. What if we split meson:electron into two parts:

  1. App: Includes client/index.js, the app dir, and app update server logic (routing etc.). Build in all environments.
  2. Dev tools: Includes Electron build infrastructure and reload code. Use the debugOnly flag so it doesn't build in production. For people with unusual build situations, they could also choose to remove the dev package manually.

This would decouple dev environments from deployment. Alternatively, is there a solution to this without any changes to the package?

Windows build: Clicking the exe gives me default Electron

I did a Windows build from a Mac, and I click on ../win32-ia32/release/APPNAME-win32-ia32/Appname.exe. I get the following:

Welcome to Electron

To run your app with Electron, execute the following command under your Console (or Terminal):

path_to_generated path-to-your-app
The path-to-your-app should be the path to your own Electron app, you can read the quick start guide in Electron's docs on how to write one.

Or you can just drag your app here to run it:

I didn't follow the steps in Building and serving an auto-updating Windows app, because I just want an exe that people can click on and access the app through (auto-updating isn't important to me right now), similar to how the Mac apps are built. What am I missing from the process?

Here are my electron settings:

electron": {
    "autobuild": true,
    "name": "Olis",
    "version": "0.1.0",
    "description": "A really cool app.",
    "height": 768,
    "width": 1024,
    "frame": true,
    "resizable": true,
    "builds": [
      {"platform": "win32",
       "arch": "ia32"}
    ]
 }

Customizing menus

I need to customize the app menus. I would be tempted to modify /.meteor-electron/[platform]/apps/menu.js directly, but I guess it's a not a good idea to go play in folders beginning with "." ... Any particular input on the subject?

Linux support

Im wondering if there is going to be support for linux :)

Linux support please...

Good day...

Just hoping there will also be support for linux!
and thanks for this awesome package...
finally, meteor has something for the desktop in online mode..

tnx.

Support versioned Windows installer URLs

Similar to the download links for Mac, so that the installers may be cached. This is a follow-up to #48.

downloadUrls should be changed to append a cachebusting parameter if and only if the download URL is not versioned.

Linux support

(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.

Convert preload API to a messaging API for maximum security?

Per electron/electron#1753 (comment):

The current security model for exposing main process APIs to the renderer process (i.e. preload scripts) is fragile because it puts a large burden on developers to ensure main process objects don't leak, such as fs, etc.

I'd be interested in seeing a prototype of what this might look like. I imagine it to be less usable: with a messaging API,

  • the client and developer would have to worry about whether that API was asynchronous or no
  • the client would still have to load a preload shim (to provide access to the ipc module) as well as registering the event handlers with the window
  • and the developer would have to keep shim and event handlers in sync

and given that the preload API isn't going to change that much, I think usability is paramount; but perhaps I am mistaken about usability being a problem with the messaging API and/or usability being the priority.

Disable Node integration

That is, set webPreferences.nodeIntegration to false as documented here, because:

  1. it fools dependencies into loading themselves into the module rather than the window: electron/electron#254
  2. it would allow unmitigated script injection attacks to read the user's filesystem: electron/electron#1753

Since this project is meant to wrap a webapp as simply as possible, that content shouldn't expect to have access to non-web functions anyway.

Unfortunately, I can't figure out how to make this option work. I tried passing webPreferences: { nodeIntegration: false } here and no dice; module is still defined.

(It seems like the naming scheme for the options changed recently but we're using v0.35 now and also tried web-preferences and node-integration and still no dice.)

Full Functionality

This project selectively exposes such functionality to the client, in a way that is safe and avoids memory leaks

Can you elaborate? What's the harm in exposing all of Electron?

How to use with meteor accounts

Hey guys,

Has anyone had any luck using meteor-electron with account authentication via Google/Facebook/Azure/etc.? After adding my account authentication, the web version works as expected.

However, when I try logging in via the desktop app, it doesn't work. Namely, after entering my credentials on the pop-up (to sign-in via Google, for example), the it seems to authenticate, but the desktop application doesn't recognize the successful login. The {{> loginButtons}} render still thinks it's not logged in.

Any ideas?

Share app dir between builds

Right now the app is built separately for each platform. Not a huge deal, but sharing more of the build process could save a lot of time for apps with an expensive npm install step.

Autorestart app when the contents of the generated `app` directory change

Cases in which the app needs to restart:

  1. settings.json changes
  2. app code changes
  3. electron-packager options change

Meteor will already restart in response to any of the above triggers since it watches the package directory, so the real task is how to determine, after building the binary on restart, when we should ignore the already running process and restart the app.

My idea for doing this is:

  1. after building, take the checksum of the build directory using dirsum
  2. see if there's a prerecorded checksum in the working directory (the build directory's parent directory e.g. .meteor-electron)
  3. if a checksum doesn't exist, or it differs, restart the app
  4. save the checksum in the working directory

This will account for restart needs 1 and 2, since electronSettings.json will change if Meteor.settings changes meaningfully, and obviously the other files in the build directory will change if the app code changes. This won't account for restart need 3 but I'm ok forcing devs to quit the app and restart the server if that happens since it should be rare.

Update to Electron 1.0

Electron 1.0 came out today. Seems like a great time for new release. :) I'd be happy to help with this. Is it as simple as changing ELECTRON_VERSION and testing the functionality? It looks like there is a special version of electron-packager in use - not sure if that matters. Any pointers would be great.

"Auto-update" vs "hot code push" clarification

Hey,

Thanks for this package. It looks like a fantastic solution!

I was hoping to have the differences (if any) between "auto-updates" vs "hot code pushes" clarified a bit. With my local testing, it looks like the Meteor client application can be updates via hot code push, but the documentation makes extensive references to "enabling auto-updates".

Does auto-updating refer to updates to the compiled electron application (the contents of /app), rather than the Meteor client application? Does hot code push still work for signed and distributed electron executables?

Thanks for your help!

/client/main.js is never called?

Using Meteor 1.4

I am expericencing an issue where my main.js file is never called. Can't get the electron app to start but it runs fine in browser.

Create offline apps

I would like to use meteor-electron to build offline apps. I did an attempt to implement this. See #86

It differs from other solutions like arboleya/electrify in that it will not bundle the server. All you need is already there, simple javascript in the client and node_modules in electron. No need to have a meteor server packaged as well.

Furthermore I like the concept of this project where we just have to add a single package to meteor that handles it all. Configuring through a settings file is easy. Furthermore I like the automatic app reload when using custom appSrc. That is something that most other projects don't handle (right now). Therefore I would like to use meteor-electron to build offline apps.

Earlier I tried to reach this goal by adding the 'AppCache' package. It will store the app in cache and therefore only needs a server on initial load. Although I wasn't satisfied. When a new version is detected, a few seconds after startup, the app will reload which is an awkward user experience. Furthermore is hard to keep versions synced between the native client (electron) and server. Therefore offline apps could be useful too.

How set configuration?

Hi.
in document :

Configuration is possible via Meteor.settings.electron

But where do i create this file? and need any file extension eg json or js?
Thank you.

throw er; // Unhandled 'error' event

Getting the following output when trying to start meteor with you package on OS X:

meteor

=> Started proxy.
=> Started MongoDB.
Downloading electron-v0.36.2-darwin-x64.zip
I20160218-22:58:10.304(1)? [============================================>] 100.0% of 39.34 MB (389.51 kB/s)
W20160218-22:58:10.352(1)? (STDERR) Packaging app for platform darwin x64 using electron v0.36.2
I20160218-22:58:13.383(1)? Build created for  darwin x64 at /Users/x/meteor/electron/.meteor-electron/darwin-x64/builds/Electron-darwin-x64
W20160218-22:58:13.406(1)? (STDERR)
W20160218-22:58:13.406(1)? (STDERR)         throw er; // Unhandled 'error' event
W20160218-22:58:13.407(1)? (STDERR) Error: spawn ENOENT
W20160218-22:58:13.406(1)? (STDERR) events.js:72
W20160218-22:58:13.408(1)? (STDERR)     at errnoException (child_process.js:1011:11)
W20160218-22:58:13.408(1)? (STDERR)     at Process.ChildProcess._handle.onexit (child_process.js:802:34)
W20160218-22:58:13.406(1)? (STDERR)               ^
=> Exited with code: 8

Its the only installed package on a newly created project.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.