In the current notebook, you have to go to a menu to perform operations on cells, know some keybindings, or click a button on a toolbar at the top.

It would be nice if cells had their own contextual menu or other UI device so you can keep context on the cell you're working in. I'm not sure how to design this, though I think it's important.

While implementing cells by uuid I got to a point where the page was rendering blank and there were no error in the console. It turns out one of the react components was failing to render. Unfortunately this failure was logged no where. We need to make sure asynchronous errors get logged and we will need to come up with a really good story for when we decide nteract should be able to render components from user extensions (maybe even rendering errors to the screen).

The last segment of this read, provided by @rgbkrk , is relevant: https://nylas.com/blog/react-plugins

cc @kenwheeler

It's been suggested that we either rename to:

• nteract/nteract

or

• nteract/notebook

The first presumes that the Electron based notebook will be the primary byproduct of the nteract org (similar to Atom). Considering how many people refer to Jupyter as JupyterHub | jupyter/notebook | tmpnb, I'm fairly tempted to go along with that. One other issue we've run into in the past is that "the notebook" can refer to the notebook document, the notebook server (python), or the frontend application that is the jupyter notebook.

The composition name came from me thinking of a different way to say notebook; @Karissa and I rolled with it and all was happy.

/cc @jackparmer

We should have a Python kernel installed for users that relies on an Anaconda. Package it up, ship it.

I'd like to have some way to access our current channels from the actions.

This is motivated by wanting to offload/move execution of a cell to an action function. We currently only have the subject, which is a scan on the state. While we could subscribe, it would be pretty odd to wait for the ​_next_​ change when we really want the ​_last_​ channels. Possibly even the last state in general.

It's a bit unclear to me how to launch the kernel as a result of a new notebook load. The current flow of loading is unidirectional and very Redux like.

The problem I feel like I'm facing in creating the initial connections is that I would expect that the first READ_JSON event would propagate a NEW_KERNEL event. I'll post a PR with my current code and hopefully we'll figure out something clean.

Out of my domain of expertise, though there are good packages and efforts around it:

https://github.com/andischerer/atom-keyboard-localization

The changelog for RxJS 5 lists a bunch of performance improvements as well as fixing Subject.create's arguments (we ran into this and they fixed it after our feedback). It needs adaption in any place where Subject.create is used (flip the args). Other than that, these are the two packages that will need to handle the bump:

• enchannel-zmq-backend
• nteract (here, silly)

It's time to outline what we want out of an Electron application for the Jupyter notebook!

• Fully standalone desktop application (in Electron!)
• One click installers for OS X and Windows
• Integrates well with the current ecosystem of tooling
• Bundles a kernel with scientific Python packages

If you click a link inside of nteract, it opens it in the current Electron window rather than your browser of choice.

Pure Cell

• render markdown when a markdown cell
• editable markdown area
• render all Jupyter mimetypes (mostly - nteract/transformime-react#1)
• handler prop to notify on change of inputs
• indicates when cell is hovered over with the mouse

Draggable Cell

• has a cell while working well as a dnd item

In order to connect to any Jupyter kernel, they rely on zmq for reliable interprocess communication. The node bindings, which are quite stable (and awesome), are a bit persnickety to install on some platforms (as with anything relying on native bindings to C). In order for a developer to build, e.g., an Electron app that relies on zmq, they tend to need these items:

• zmq headers
• (optionally) libsodium for encryption TweetNACL is built in now!
• C compiler
• pkg-config
• for every version of Electron and node that come out, these need to be rebuilt
• rebuild for each version

Releasing multiplatform precompiled binaries for node modules is completely doable, though care has to be taken to allow users to use their local version of libzmq + libsodium as well.

If you dig through issues on zmq, you'll find quite a few about installation issues. Currently there are bundled Windows binaries in the repository for libzmq (for linking against).

Hi!

npm-debug.log.zip

• Find available kernels on a system - now in kernelspecs package

As we progress, we should take some time to think about how we do internationalization of text. The current way that people appear to be doing this in React apps is with react-intl, which relies on formatjs. There are standard APIs for the easy ones:

> new Intl.NumberFormat().format(1000.0)
"1,000"

It's the string messages that I'm not sure of. What I do know we have to do is make it easy for others to provide translations as PRs. Seems like people are used to JSON files with things like templated dialog messages, etc. for all the languages. @TwistedHardware suggested that there may be translations available for a lot of common things like File, Edit, etc.

Within jupyter/notebook, @TwistedHardware is putting together an enhancement proposal for the current Tornado app and templates. We should make sure to learn from both efforts.

Related resources

• formatjs
• react-intl
• Video on Formatting with Format.js + react-intl

Where do notebooks get saved by default? What's your workspace area (your cwd if you will)?

Since this is an electron app that can run from clicking a shortcut on someone's Windows Desktop or Apple Applications menu, we have to make sensible defaults (while clearly allowing for file browsing).

Read practical undo, implement the model for our notebook.

As implemented in jupyter/notebook currently, there are quite a few security features to deal with malicious notebooks (whether intentional or not).

• Signed notebooks
• Sanitization of HTML outputs

We'll need to implement those up to the spec as well.

Earlier @captainsafia and I discussed the ability to do diffs on notebooks. With our immutable.js structure, this might turn out to be pretty simple. Hooking it up with git would be super slick.

There's already a diffing library for Immutable.js that produces RFC 6902 style patches, called immutable-js-diff:

var Immutable = require('immutable');
var diff = require('immutablediff');

var map1 = Immutable.Map({a:1, b:2, c:3});
var map2 = Immutable.Map({a:1, b:2, c:3, d: 4});

diff(map1, map2);
// List [ Map { op: "add", path: "/d", value: 4 } ]

It would be super cool to see what @smashwilson thinks about this one in terms of making custom diff tools for git.

So I properly logged in as suggested in #67
then:

$ rm -rf ./composition
$ git clone [email protected]:nteract/composition.git
$ cd composition
$ npm install

And... surprise surprise:

npm-debug.log.zip

Now that we have a custom menu, we lost our default actions for things like Copy Paste. We should bring in some of the default menu options that come with Electron.

We should start packaging this for pre-pre-pre-alpha releases to at least figure out a bit of the flow. Some things we'll need:

• Icons!
• Metadata about the built application across the other platforms

• Open a new notebook
• Save a notebook
• Load a notebook from disk

We need to post mocks and UI flows for the state of the kernel.

States:

• Kernel busy
• Current language
• Icon for language

We likely need to support the current notebook's $ inline and $$ block modes via KaTeX and/or MathJax.

Resources:

• Discussion on a react notebook renderer
• Khan Academy's TeX component

While we're launching a notebook at the start, we should have a loading screen/indicator.

I'm not sure what limits we're running into right now (disk space, memory?). Travis seems to be stalling out on the regular while I'm able to build and run this all locally on Linux and OS X.

Given a kernelspec, launch a kernel. This doesn't have to take into account the UI aspect and may end up being a node package in its own right.

We need to have the concept of active cells (user has clicked on the cell, is interacting with it in some way, etc.)

The current notebook has a header and menu that looks like this:

At the very least, we should display what the current language is + logo. In Atom, it's shown in the gutter and, depending on your plugins, before the name in the editor tab. nteract's sidecar does the same thing.

We have disallowed using capital case at Walmart, due to OSX case insensitivity issues. Additionally, we use the .js extension instead of .jsx.

Do we have good reasons for either? On other projects we've found these patterns to be more trouble than they are worth.

Thoughts?

• Start a kernel (given a kernelspec)
• Stop a kernel
• Run code against a kernel

Note that much of this is encompassed within jupyter-js-services, though we'll be reliant on zmq directly.

• Kernel Selection - Top level menu?
• Notebook(s) - Are these in individual windows, tabbed, selectable?
• Notebook selection - is this a dashboard, a menu, or a sidebar?

This little snippet of code works just fine run locally as a script via babel-node ($( npm bin )/babel-node in composition):

const launchKernel = require('./src/api/kernel').default;
const createExecuteRequest = require('./src/api/messaging').createExecuteRequest;

console.log('prelaunch');
launchKernel('python3')
  .then(kc => {
    console.log(kc);
    const channels = kc.channels;
    const shell = channels.shell;
    const iopub = channels.iopub;
    const msg = createExecuteRequest('print(3)');
    console.log(msg);
    shell.subscribe(console.log, console.error);
    iopub.subscribe(console.log, console.error);
    shell.next(msg);
  }).catch(console.error);

If I run the same thing from the chrome console in Electron (or if inserted in the code base after channels are launched), I get this error:

spawnteract v1.0.0 is out, with a new API:

const spawnteract = require('spawnteract')

spawnteract.launch('python3').then(kernel => {
  // Returns
  // kernel.spawn <-- The running process, from child_process.spawn(...)
  // kernel.connectionFile <-- Connection file path
  // kernel.config <-- Connection information from the file
}

The only change there is that connFile is now connectionFile. Underneath the hood, kernelspecs has changed and is faster than before because it tore out RxJS4 and switched to native promises.

• Basic CodeMirror as input area for cells (done in #11)
• Markdown editing
• Maintain a consistent immutable notebook state over time superseded by commutable work
• Input/Output styling
• Handle all the mimetypes that Jupyter supports (see nteract/transformime-react#1)

We're currently relying on ansi-to-html, which creates HTML text from ANSI colored text. It would be great to make a separate package (or find one!) that does the direct route so it can rely on React's Virtual DOM.

Sometime ago, I wrote nbformatjs (available on npm as nbformat) for working with the notebook format. We need to add on to that package and/or build follow ons that use it to handle a variety of things:

• Upgrading from previous formats
• Validation of format
• Converting from the disk format to the in-memory format, e.g. The "multi-line string" array of strings should be .join('')ed
• Utilities for working with an Immutable.js notebook (load, convert, save)

From some of the classes I have taught and some observations at conferences, I've noticed that people tend to use the notebook in two ways, as a note-taking tool and as the "traditional" interactive programming tool. Simply put a note-taking user will mostly be writing text with occassional code cells. On the other hand, a "traditional" user will mostly be writing code with occassional text cells.

As mentioned by @rgbkrk in #41, composition will only support the Markdown and code cell types so we are dealing with a binary toggle. I'm imagining the following implementation option.

1. Add a defaultCellType property to the Notebook class.
2. Configure the cells to render with the defaultCellType by default.
3. Add a toggle, either as a menu item or as a literal toggle, although I am leaning towards the menu item that will allow the user to set the default cell type.

There might be more details to flesh out on this but this is my cursory impression based on user observations and code reading.

Same as nteract/ick#19, we need to issue a shutdown_request before we kill the process.

Right now everything is built on the predicate of loading a notebook from disk. As I'm fleshing this out, I'm noticing it matches up much better to be reacting to changes in state. The notebook document itself is a final state representation that can be turned back into the messages that put the application state together.

We're a bit different in the current keybindings for the notebook. Our current shift-enter stays on the same cell.

In the Jupyter Notebook, that action is supposed to be ctrl-enter. shift-enter should run the cell and move to the next, creating one if necessary.

This generally brings up a point about needing to think about keybindings and action names.

Solution: Command-q / ctrl-q should exit the application

Bonus points: close the kernel channels, kill the spawn, and fs.unlink the connectionFile.

People have iterated on the cell design quite a few times.

There's the classic IPython/Jupyter notebook cells:

In CoLaboratory, they took a lot of approaches that we should look back to, namely

• Cells have their own context menu
• Active and hovered cells are raised up as cards (material design)

In jupyter/design#10, the cell is very trim and clean:

I'd really love to see the entire app colorscheme to be dependent on top level variables, similar to Atom's. I'm imagining that, for the time being, we can rely on code mirror choices used as less variables throughout the application.

This isn't so much of a concern for the Electron notebook itself. This is more about how the notebook gets presented when sharing on the web (converted to HTML, no kernel backed compute). As much as possible, we need to make sure that components which are pure can be extracted. Thus far, the primary ones have been:

• https://github.com/nteract/react-jupyter-display-area
• https://github.com/nteract/transformime-react

It makes a good bit of sense that Cell isn't, since we're keyed into editor changes. In order for us to have full parity with nbviewer and the notebook we're going to need more implemented within our other projects:

• Handle old notebook versions - nteract/commutable#8
• Console text as React Components - nteract/react-jupyter-display-area#1
• Maths - #99
• Sanitization or sandboxing of HTML/JavaScript embedded in notebooks - nteract/react-jupyter-display-area#6

Another piece that needs to be explored is:

• Prismjs input segments (instead of CodeMirror) for CodeCells

Roughly speaking, the static rendering component starts to look like this, complete with custom transforms (swapping out the defaults used in https://github.com/nteract/transformime-react):

import { transforms } from 'transformime-react';
import Display from 'react-jupyter-display-area';

const IFramedHTML = React.createClass({
  render: function() {
    return (
      <iframe ...>
         <somehow {this.props.data} />
      </iframe>
    );
  }
});

const myTransforms = transforms.set('text/html', IFramedHTML);

...

const StaticCodeCell = React.createClass({
  render: function() {
    return (
      <div>
        <PrismCode>
          {this.props.cell.get('source')}
        </PrismCode>
        <Display transforms={myTransforms}
                 outputs={this.props.cell.get('outputs')} />
      </div>
    );
  }
});

OS X

brew install zmq
brew install pkg-config

Jupyter tooling

pip install jupyter_console
jupyter kernelspec install-self

Installing the Python 3 kernel:

python3 -m pip install ipykernel
python3 -m ipykernel install --user

We have to make a difficult choice in how we handle cell output.

The current notebook lets cell output do anything with the page, including modifying the notebook itself and running code on kernels. This is both powerful and a large risk which is overcome by restricting cell output to <iframe>s or even Electron's web-view. That ends up meaning you get consistent state on the notebook and all the UI while restricting what can be mutated by cells. On the other hand, this also means that cells can't communicate with each other. It's a tradeoff!

Howdy! I was trying the install instructions in the readme and hit this error. I'm on node v5.4.1 and npm 3.3.12. Wondering if there are other dependencies that need to be installed before I can try this out?

Here's a bit more detail:

$ npm run start

> [email protected] start /Users/odewahn/Desktop/composition
> electron main.js

App threw an error when running [Error: Electron compilers not found but were requested to be loaded

]

In following with C4.1, I'd like to propose that we relicense composition to MPLv2.

In order to do this, I'd need a 'yay' from each contributor to relicense your contributions as MPLv2:

• @rgbkrk
• @kenwheeler
• @Karissa
• @phfrohring
• @captainsafia
• @jdfreder

Please let me know a yay or nay as soon as you can.