Jupyter Desktop App about jupyter HOT 5 CLOSED

Yeah, https://github.com/nteract/nteract is the realization of the above vision with Electron.

from jupyter.

I think the is the most promising avenue (and is already under the jupyter project apparently). Since atom already provides advanced text editing features and is readily hackable I really like the idea of using it for desktop iPython. There's loads of work to do still, as will as plenty of basic design decisions - starting with whether it should just be an atom plugin or an app forked from atom. I don't think there are any good python alternatives to NW/electron - happy to be shown wrong though, the world could definitely use an ipython notebook renderer written in python.

from jupyter.

The atom-notebook integration looks great – I might start using that in the meantime. However, I don't know if it's a good general solution for a desktop app. It seems equally problematic to tell people to install and access Jupyter through Atom as through a browser. Restricting a fork of Atom to solely wrap Jupyter seems slightly better, but could be very bloated and potentially slow. Just my opinion though.

Something standalone and one click away in your task bar seems like the nicest solution (like how Mathematica or Matlab would be used).

@rgbkrk I'm not totally sure what you mean by not using the notebook server to reach kernels. Instead of having nw start the Jupyter server and just pointing the nw browser to localhost, we should have a custom webpage on the client that uses the JS APIs to interact with Jupyter functionality?

from jupyter.

I'm certainly a fan of this.

My personal opinion is that we need our JavaScript broken out into smaller reusable packages, which has already been done for the output area and the primary services of the notebook - session, kernel, contents. Note that the contents API is not necessary for a pure desktop application.

The output area is already being used in sidecar which is an Electron app. Additionally, there's Hydrogen and the Atom Notebook - both Atom packages.

ZeroMQ and Node

The most common issue we (developers of the above mentioned projects) have faced is native extensions, especially node-zmq. In particular, each release of V8 ends up having inconsistencies which are addressed in nan (Native abstractions for Node.js). On top of that, actually building it on the various platforms (as in, on people's machines) is not the best story for Windows (requires specific version of Visual Studio). We really need to be shipping around the built binaries for zmq across Windows, OS X, and Linux in order to take advantage of the auto-updating.

You may ask (as does ipython-desktop above) "why not just use the notebook server itself to reach kernels"? My primary reasons for wanting to steer clear of this are all about security, primarily with respect to cross origin issues across websockets and shielding from other issues likely to come up with running a local server on machines (where not everyone understands they're running a server). I would be amenable to a very opinionated, very locked down, glorified zmq-websocket bridge.

from jupyter.

@rgbkrk I think it's reasonable to close this issue at this time. Agree?

from jupyter.