Currently you need to force quit or kill the electron process in order to close the app because JupyterLab is prompting the user if they really want to leave the page and Electron is not showing that prompt.

We want to show our own prompt in the onbeforeunload event of the Electron BrowserWindow
https://github.com/electron/electron/blob/master/docs/api/browser-window.md#event-close

The JupyterLab electron app will place the menu bar content in the native menu bar instead of at the top of the window. This will be a more efficient use of screen space.

Some resources for @jasongrout students and other approaching Electron. I will keep adding these as they come to mind:

Main and renderer process: Electron is based on a dance between two communicating processes, one for the UI, one on the native side. The division is not that clear, but this is the most important concept to grasp.

• official reference
• better article
• classic talk about js event loop

General UI and design articles:

• lots of small useful suggestions

And of course official docs

Build an AppImage too

The electron compile package allows for easier development with TypeScript. We were originally using it; however, I was having build issues that were solved when I installed the plain electron package. It should be changed back.

We should figure out an elegant way to handle lab extensions in the application.

If were to use "jupyter labextension install ", the JupyterLab application assets are built and run in the application directory. So, if we wanted to use this command as-is with the Electron application, we really would only be using the extension tarballs created by "npm pack" and the settings. Then, we'd still have to use npm to install the extensions for the Electron app and we're basically repeating the process, or something similar to it. This would also mean that any lab extension installed in the standard JupyterLab would be installed for the Electron app. And this also requires the user to have npm installed to install a lab extension.

Any thoughts on the best way to approach this?

To augment the architectural issue opened #2, I wanted to open an issue to discuss the overall design goals for an electron app. Let's start this as an issue and evolve it into a markdown doc in the readme. Some of the goals I have in mind are:

• Ability to minimize the "extra" UI to provide more working area in the app. This includes getting rid of the browser chrome and being able to move the JupyterLab menu bar to being a native menu bar.
• Access to npm on the server side to make it easier for users to manage JupyterLab extensions as npm packages, and rebuild on the fly, etc.
• Ability to offer a nice experience for double clicking on a notebook file and having it opened in the app.
• Easy management of notebook servers without using the command line. The app can automatically start/stop a local notebook server, keep track of remote servers, etc. This would allow users to seamlessly track and switch between the different servers easily.
• Integration between our keyboard handling/shortcuts and the native OS ones.

Can others add more design goals? @charnpreetsingh @rschroll

We need to communicate with the Jupyter Notebook server and parse the token string. Right now it is a hard coded value that needs to be manually inputted here for the app to work.

I'll fix this, just for tracking

Should be for Jupyter Development Team @ellisonbg ? Or Project Jupyter Contributors?

On launching the app with npm run build:all, the splash screen opens and animates, but nothing progresses from there. Stdout from the process is below.

This is on Ubuntu Linux 14.04, with node v6.11.2 and npm 3.10.10. I'm currently at 85cf025.

> [email protected] build:all /home/rschroll/jupyterlab_app
> npm run build && npm start


> [email protected] build /home/rschroll/jupyterlab_app
> npm run build:main && npm run build:browser


> [email protected] build:main /home/rschroll/jupyterlab_app
> webpack --config webpack.main.js


[at-loader] Using [email protected] from typescript and "tsconfig.json" from /home/rschroll/jupyterlab_app/tsconfig.json.


[at-loader] Checking started in a separate process...

[at-loader] Ok, 0.89 sec.
Hash: ea29979e9db284a5ec8f
Version: webpack 2.7.0
Time: 3919ms
             Asset       Size  Chunks             Chunk Names
        index.html  985 bytes          [emitted]  
    main.bundle.js     138 kB       0  [emitted]  main
main.bundle.js.map     193 kB       0  [emitted]  main
   [0] ./~/@phosphor/algorithm/lib/iter.js 5.61 kB {0} [built]
   [2] ./src/ipc.ts 3.79 kB {0} [built]
   [3] ./~/@phosphor/algorithm/lib/index.js 1.03 kB {0} [built]
   [4] ./src/main/app.ts 7.53 kB {0} [built]
  [12] ./~/@phosphor/algorithm/lib/range.js 3.33 kB {0} [built]
  [13] ./~/@phosphor/algorithm/lib/reduce.js 1.99 kB {0} [built]
  [14] ./~/@phosphor/algorithm/lib/repeat.js 2.36 kB {0} [built]
  [15] ./~/@phosphor/algorithm/lib/retro.js 2.19 kB {0} [built]
  [16] ./~/@phosphor/algorithm/lib/sort.js 2.15 kB {0} [built]
  [21] ./src/main/main.ts 412 bytes {0} [built]
  [22] ./src/main/menu.ts 3.78 kB {0} [built]
  [23] ./src/main/server.ts 7.96 kB {0} [built]
  [24] ./src/main/shortcuts.ts 4.28 kB {0} [built]
  [25] ./src/main/state.ts 9.04 kB {0} [built]
  [26] ./src/main/window.ts 4.88 kB {0} [built]
    + 17 hidden modules

> [email protected] build:browser /home/rschroll/jupyterlab_app
> webpack --config webpack.browser.js


[at-loader] Using [email protected] from typescript and "tsconfig.json" from /home/rschroll/jupyterlab_app/tsconfig.json.


[at-loader] Checking started in a separate process...

[at-loader] Ok, 1.024 sec.
Hash: cfa4587654efecc5cea0
Version: webpack 2.7.0
Time: 13846ms
                                 Asset       Size  Chunks                    Chunk Names
  42bbe4eefcde1297b11dc4b6491e9746.ttf     174 kB          [emitted]         
  3275372707f7d039afebb96123631395.png    5.44 kB          [emitted]         
  995a1d96b1fef026c61ac03f4c6ff841.png  210 bytes          [emitted]         
  200b3fc810ff360a023c4cc309f77e5a.png  217 bytes          [emitted]         
  1c8b268ec020a3aa5cd211cdda05fe2b.png  214 bytes          [emitted]         
  674f50d287a8c48dc19ba404d20fe713.eot     166 kB          [emitted]         
  42755f5d26c8ce544c6c5ae41fe2135e.map    3.17 kB          [emitted]         
  30e4639d54822ef7e3f80f11a73ebc3f.map    1.17 kB          [emitted]         
af7ae505a9eed503f8b8e6982036873e.woff2    77.2 kB          [emitted]         
 fee66e712a8a08eef5805a46892932ad.woff      98 kB          [emitted]         
  b06871f281fee6b241d60582ae9369b9.ttf     166 kB          [emitted]         
  ee7b96fa85d8fdb8c126409326ac2d2b.ttf     171 kB          [emitted]         
  1eb7a893589ddce89d81cdb22a356660.ttf     175 kB          [emitted]         
  7a564d5604efdab6ca2325dcced48457.png  210 bytes          [emitted]         
  3e1af3ef546b9e6ecef9f3ba197bf7d2.ttf     172 kB          [emitted]         
  a3c3082872743102af82207d10076209.ttf     212 kB          [emitted]         
  d77c7593ff187c79a73360a5edd1da75.ttf     174 kB          [emitted]         
  4f22015ae8668226a7f7e8413fe93a81.ttf     180 kB          [emitted]         
  1066e54d79f902a2ff4d864c9a38a183.ttf     213 kB          [emitted]         
  fcad2f97acb3c868bd1ca7629d36d80e.svg    16.9 kB          [emitted]         
  912ec66d7572ff821749319396470bde.svg     444 kB          [emitted]  [big]  
  2e6d2674cbb01a89b6044ae1dd256066.svg    24.1 kB          [emitted]         
                   0.browser.bundle.js     892 kB       0  [emitted]  [big]  
                     browser.bundle.js    7.85 MB       1  [emitted]  [big]  main
               0.browser.bundle.js.map    1.08 MB       0  [emitted]         
                 browser.bundle.js.map    9.39 MB       1  [emitted]         main
  [16] ./~/style-loader/addStyles.js 6.91 kB {1} [built]
  [41] (webpack)/buildin/global.js 509 bytes {1} [built]
  [67] ./~/react/react.js 56 bytes {1} [built]
 [219] ./src/browser/app.tsx 9.15 kB {1} [built]
 [220] ./~/react-dom/index.js 59 bytes {1} [built]
 [285] ./src/browser/extensions/electron-extension/index.ts 5.79 kB {1} [built]
 [539] ./~/@jupyterlab/theming/style/index.css 871 bytes {1} [built]
 [540] ./~/font-awesome/css/font-awesome.min.css 892 bytes {1} [built]
 [541] ./src/browser/style/main.css 920 bytes {1} [built]
 [759] ./src/browser/extensions/index.ts 1.42 kB {1} [built]
 [762] ./src/browser/index.tsx 639 bytes {1} [built]
 [831] ./~/css-loader!./~/@jupyterlab/theming/style/index.css 3.85 kB {1} [built]
 [861] ./~/css-loader!./~/font-awesome/css/font-awesome.min.css 33.3 kB {1} [built]
 [870] ./~/css-loader!./src/browser/style/main.css 3.12 kB {1} [built]
[1010] ./~/react-dom/lib/ReactDOM.js 5.17 kB {1} [built]
    + 1416 hidden modules

WARNING in ./~/xterm/lib/addons/search/search.js
10:31-45 Critical dependency: the request of a dependency is an expression

> [email protected] start /home/rschroll/jupyterlab_app
> electron .

We should start setup a CI, but what and how to test?

In replacing the default electron menu bar with the JupyterLab menu bar (#40), I have taken away the ability to open the chrome developer tools. This is fine for the final product, but for development we should be able to start the app in debug mode using a command line argument. Debug mode should add an additional menu to the menu bar that enables the developer tools.

I just tried the 0.1 release. I have Python installed using Anaconda, but my default conda env doesn't have Jupyter in it. I have a separate named conda env I would like to run JupyterLab on. Right now in the app, if a python+jupyter can't be found, the user sees a screen that refers them to the jupyter docs. I think this screen should minimally allow them to enter a path to a python.

The default fonts used in lab may not be great depending on what a user has installed. We should ship some good open-source fonts and use them. Open Sans and Source Code Pro are probably good starting points.

Right now the server is started in the electron app directory, should probably start in the user's home directory.

I just updated and built master. When I launch I see this:

This issue is to discuss and consider if there are shortcuts that should be made more native-like.

From #3

Definitely not urgent 😄

Beaker browser (not to be confused with beaker notebook!) is an electron-based browser that also supports serving (and writing!) to the dat and ipfs p2p protocols (as well as http).

If you haven't seen any of those words, have a gander at:
https://www.youtube.com/watch?v=GRNWZRz4JqU

Here are some things I'm thinking about.

beaker as inspiration

There's already a ton of work sunk into the electron-y, browser-y bits. It might be worth looking at some stuff there for a non-trivial app (i.e. binary kernel comms, etc).

beaker as baseline

Going further, taking beaker as an upstream would do some pretty amazing things.

dat/ipfs as realtime backend

DAT would make a fascinating target for the continuation of @ian-r-rose's realtime work.

export a jupyterlab as dat sites

@yuvipanda and I did some stuff with nbconvert back in the day to push nbconverted stuff out to IPFS. Humorously easy from a developer point of view, but would need some UI polish. But at the end of it, you got a shareable link to an HTML page, and couldn't necessarily recover the notebook, or the data that was used to create it, or a running kernel state.

A directory of files with a cryptographically-assured identity is called a site and support familiar contents manager things of creating files/folders, etc.

Experimentally, I tried building JupyterLab as a Beaker site (good ol' wget --mirror plus some extra bits) and it works pretty well, up to and including editing its own HTML and CSS code... bundle.js is a non-starter, but yeah, at the end of the day, your reproducible computing could basically ship, including terabytes of data, everything except the running kernel process... conda or docker or whatever could get you there.

There are enough things that didn't work at the time (copying files) that I'm not comfortable suggesting anyone go through the entire build chain to try it out, but once the extension stuff is a little more resolved, i'll probably take another look. Anyhow, here's the core of it:
https://gist.github.com/anonymous/9c4bfe12471ff1f35ec0d6a7ef702475

jupyterlab as beaker native chrome

To manage all this stuff, beaker ships a google-docs-inspired document editor, as well as a site manager, which is kind of its own thing. I'd love to see us be able to bring the weight of the JupyterLab proposition to this effort, with all of the content type viewers we are anticipating.

There should probably be an user friendy message in case jupyter is not correctly installed that sends the user to http://jupyter.readthedocs.io/en/latest/install.html

Opening to see how people foresee handling "search/find" commands inside the app. Using chrome's default browser behavior might provide some consistency across platforms(?). However, it would be nice if there were some more advanced search/find-replace method similar to in other IDEs... perhaps this discussion belongs in the jupyterlab main repository.

(Thanks for setting this up! Works like a charm 🥇 )

VSCode, Sublime, and several other editors provide a mechanism to install a launch script that allows easily launching the app from the command line. The script is setup so that the terminal immediately returns back to running bash instead of displaying the stdout of the app. We want to include something similar.

This would involve adding a command to the command palette that installs the script to a directory like /usr/local/bin. I talked to @ellisonbg , and he recommends using "jlab" for the script name.

We should divide source files into "main" and "browser" folders. Maybe something similar to the "main" and "notebook" separation nteract has?

Right now, the code that handles errors from the spawned Jupyter server is not particularly robust. It should be improved to a) cleanly handle Jupyter server anomalies and b) properly inform the user when something goes wrong with the Jupyter server.

I began implementing this with #96, but we can make a lot more improvements.

As a default (not locally installation) we could allow JupyterLab Native to connect to binder. Here is an issue on the binder hub repo that is discussing the proposed API for starting a binder instance with a a REST API.

jupyterhub/binderhub#13

@yuvipanda

The following graphical elements can improve the app appearance:

• NSIS sidebar, the default one is very blue
• NSIS installer icon
• Mac's DMG background, including retina support
• Mac's DMG icon
• check if Mac's app icon works well with retina devices

Following up on our video chat discussion: We need to determine the basic architecture for the desktop application. There are (at least) two general approaches:

1. A thin application that offers a browser to view a JupyterLab server running locally or remotely. This is the approach taken by Juno. Desktop integration of things like menus and dialogs could be achieved by injecting JavaScript into the browser window, either to monkey patch some features or to connect to hooks provided by JupyterLab.

Pros:

• Smaller code base.
• Easy support for both local and remote servers.

Cons:

• Introduces another interface, which will presumably need to be versioned.

2. A thick application that ships with some / most / all of the JupyterLab browser-side code. Relevant UI modules could be easily swapped out for desktop replacements. The app would load this content, and then instruct it to contact a server to complete the setup. (I'm doing my best to summarize @ellisonbg's description, but I may be screwing it up a bit.)

Pros:

• Easier insertion of desktop customizations.
• Split may occur along existing interface (?)
• Potential to build easy system for installing additional extensions.

Cons:

• Interface likely more extensive, may be more sensitive to versioning.
• May not be easy to serve JupyterLab resource without Jupyter server. (Based on my 10 minute exploration of the code; I'll defer to others on this point.)

Personally, I'm prejudiced in favor of (1). Part of that is that I've worked in that direction, and things seem to be working. Part of it is that it will probably lead to a working app faster. (Arguably, it's already there.) And part of it is that I don't understand the JupyterLab architecture enough to really judge the amount of work required for (2).

What say all of you? Is my understanding mostly right? Am I missing another architectural approach?

I'm opening this issue to discuss connecting to remote Jupyters following @ellisonbg design guidelines.

What should we support?

• http with token/pass autentication
• ssh tunneling (how to be sure of the ports used? should we spawn jupyter remotely too?)
• Spawning VMs on cloud (maybe with pkgcloud lib on VMs such as this one suggested by @ellisonbg
• jupyterhub

I've had a couple users report that the application hangs on the splash screen with old versions of the Jupyter server. I've heard the issue reported on v4.2.0 and v4.0.6.

following #3 :

• associate ipython notebooks files with the app
  • with proper icon
• ability to open code files

This (meta) issue is to discuss the app distribution. I suggest first the following targets:

• linux appimage
• MacOS dmg

Then, when those are working, move to:

• Linux deb and rpm repo, hosted on Bintray
• Windows installer
• Brew cask installer for the MacOS app

We should be able to build the Windows app on Travis, using docker. Travis will work fine for MacOS and linux too. The build can be automated when the release is tagged on the repo.

Linux apps can be automatically updated from the repos. Windows and mac require an autoupdate. Electron supports this functionality, but it requires some external hosting.

The MacOS app needs to be signed using a certificate from Apple, this is something like 99$ but will require probably a legally recognised entity.

Builds are failing https://travis-ci.org/jupyterlab/jupyterlab_app/jobs/260434845

#87 was merged without setting GH_TOKEN

@lucbouchard1

I saw some / in paths...

Following #62 we're gonna need a windows installer.

I'm going to tackle this next weekend (maybe sooner). If someone gets to it sooner, I plan to use the old-looking boring installer, not the fancy one-click installer. Don't wanna to freak out corporate sysadmin.

macOS handles applications differently from Windows/Linux in that when you close a window, the app continues to run in the background. When the application is in this backgrounded state, the user is supposed to be able to 'reactivate' the application window by clicking the application icon.

This currently works in the electron app; however, the time for the window to reappear is almost equal to the time it takes the app to startup, making the feature pretty much useless. We need to refactor the reactivate code to improve performance. This could be accomplished by not showing the splash screen on reactivate, and not destructing the electron BrowserWindow when the window is closed.

When the application is minimized and a a new local server is spawned through the menubar, I get this error:

The splash screen is pretty inconsistent in how it disappears. Sometimes it fades, sometimes it doesn't, and sometimes JupyterLab isn't even fully rendered.

We need to investigate this a little bit. I think the problem is coming from how we trigger the splash screen fade. Right now, we fade the splash screen when we receive the message from the main process that the server is ready, but we should wait until JupyterLab is ready.

Some browser source files are written in JavaScript. These should be translated into TypeScript.

JupyterLab 0.25 was released today, so we can update the Electron app.

Since JupyterLab publishes to npm every week or two, we've been running into issues with not being able to utilize the newest JupyterLab features. This has already caused us some headaches, and I'm sure it will only get worse in the future. I talked to @ellisonbg about the possibility of nightly JupyterLab builds; however, it's probably far enough down the road that we should create a workaround.

As a temporary solution, I think we should configure npm to pull/build a particular version of JupyterLab from github using this package. JupyterLab will have to be built as part of the install, which isn't ideal; however, I think it will mitigate issues/blockers in the future.

The ENV VARs in a user's environment determine which python and notebook server will be used. We will need to figure out a way of propagating the those to the electron app when installed so it can start the notebook server.

Clicking on the app icon spawns a new lab every time. If the app isn't in focus, it should focus an open application window or restore a minimized window. It should only create a new local server on activate if there are no running labs.

Linux and Windows distribution work, but it's hard to distribute apps for MacOS without apple certificates. https://developer.apple.com/programs/

This is going to require a legally registered entity, I imagine NumFocus

We should add a command line flag that enables a more verbose debug output. The expanded debug output should include things like the output of the Jupyter server.

The Electron process should launch the jupyter notebook server so the user does not need to start the server manually before opening the electron app.

I'm starting this issue to talk about how the electron app will manage multiple Jupyter server connections. This includes both remote connections and servers that are already running locally when the application starts. I think there are two primary ways to approach this: either we provide a UI that appears before the JupyterLab frontend and allows selecting/adding a connection, or we create an extension for JupyterLab that manages connections after the app has started.

1) Independent Server Management UI

This UI would appear before the splash screen and would allow the user to choose between spawning a new local server, connecting to a local server that's already running, or connecting to a remote server. If the user selects to create a new local server, the splash screen is displayed until the server starts.

Pros

• We don't need to to start a local server if the user wants to use a server that is already running.

Cons

• The user has to do something every time the app starts, which can slow down workflow and be confusing for new users.
• We would need to restart the app in order to change connections.
• We would need to develop a UI from scratch that is independent of JupyterLab.

2) JupyterLab Server Management Extension

This option requires that we spawn a Jupyter server when the electron app starts, because, as far as I know, the JupyterLab frontend needs a server connection to start properly. The UI would provide a list of currently running local servers and a list of previously used remote connections.

Pros

• We wouldn't need to restart the app in order to change the server connection.
• We wouldn't need to start from scratch on a UI design.

Cons

• We always need to start a Jupyter server when the application starts, even if the user plans to use a remote connection.

Analysis

There are, of course, slight deviations from these two options. For example, we could do a hybrid of the two where the user can manage connections after choosing an initial connection to start on. However, I think these are a good starting place.

I think option 2 makes the most sense, as it makes the startup process really smooth and allows the user to start working immediately.

Looks like this could be very useful in talking between the two processes:

https://github.com/electron-userland/electron-remote

#46

Having multiple Jupyter servers running on start up crashes the application. In this case, listing the servers running returns multiple JSON objects, and the program only expects one. The application should be able to handle this and connect to the server it created.