+ {% block h1_error %}
+ <%= htmlWebpackPlugin.options.title %>
+
+ <%= require('html-loader!./partial.html') %>
+
+
+
+
+
+
+
diff --git a/dev_mode/webpack.config.js b/dev_mode/webpack.config.js
new file mode 100644
index 00000000..aa76727b
--- /dev/null
+++ b/dev_mode/webpack.config.js
@@ -0,0 +1,237 @@
+/*-----------------------------------------------------------------------------
+| Copyright (c) Jupyter Development Team.
+| Distributed under the terms of the Modified BSD License.
+|----------------------------------------------------------------------------*/
+
+var path = require('path');
+var fs = require('fs-extra');
+var Handlebars = require('handlebars');
+var HtmlWebpackPlugin = require('html-webpack-plugin');
+var webpack = require('webpack');
+var DuplicatePackageCheckerPlugin = require('duplicate-package-checker-webpack-plugin');
+var Visualizer = require('webpack-visualizer-plugin');
+
+var Build = require('@jupyterlab/buildutils').Build;
+var package_data = require('./package.json');
+
+// Handle the extensions.
+var jlab = package_data.jupyterlab;
+var extensions = jlab.extensions;
+var mimeExtensions = jlab.mimeExtensions;
+
+var extraConfig = Build.ensureAssets({
+ packageNames: Object.keys(mimeExtensions).concat(Object.keys(extensions)),
+ output: jlab.outputDir
+});
+
+// Create the entry point file.
+var source = fs.readFileSync('index.js').toString();
+var template = Handlebars.compile(source);
+var data = {
+ jupyterlab_extensions: extensions,
+ jupyterlab_mime_extensions: mimeExtensions
+};
+var result = template(data);
+
+// Ensure a clear build directory.
+var buildDir = path.resolve(jlab.buildDir);
+if (fs.existsSync(buildDir)) {
+ fs.removeSync(buildDir);
+}
+fs.ensureDirSync(buildDir);
+
+fs.writeFileSync(path.join(buildDir, 'index.out.js'), result);
+fs.copySync('./package.json', path.join(buildDir, 'package.json'));
+
+// Set up variables for watch mode.
+var localLinked = {};
+var ignoreCache = Object.create(null);
+Object.keys(jlab.linkedPackages).forEach(function(name) {
+ var localPath = require.resolve(path.join(name, 'package.json'));
+ localLinked[name] = path.dirname(localPath);
+});
+var ignorePatterns = [/^\.\#/]; // eslint-disable-line
+
+/**
+ * Sync a local path to a linked package path if they are files and differ.
+ */
+function maybeSync(localPath, name, rest) {
+ var stats = fs.statSync(localPath);
+ if (!stats.isFile(localPath)) {
+ return;
+ }
+ var source = fs.realpathSync(path.join(jlab.linkedPackages[name], rest));
+ if (source === fs.realpathSync(localPath)) {
+ return;
+ }
+ fs.watchFile(source, { interval: 500 }, function(curr) {
+ if (!curr || curr.nlink === 0) {
+ return;
+ }
+ try {
+ fs.copySync(source, localPath);
+ } catch (err) {
+ console.error(err);
+ }
+ });
+}
+
+/**
+ * A WebPack Plugin that copies the assets to the static directory and
+ * fixes the output of the HTMLWebpackPlugin
+ */
+function JupyterFrontEndPlugin() {}
+
+JupyterFrontEndPlugin.prototype.apply = function(compiler) {
+ compiler.hooks.afterEmit.tap(
+ 'JupyterFrontEndPlugin',
+ function() {
+ // Fix the template output.
+ var indexPath = path.join(buildDir, 'index.html');
+ var indexData = fs.readFileSync(indexPath, 'utf8');
+ indexData = indexData
+ .split('{{page_config.bundleUrl}}/')
+ .join('{{page_config.bundleUrl}}');
+ fs.writeFileSync(indexPath, indexData, 'utf8');
+
+ // Copy the static assets.
+ var staticDir = jlab.staticDir;
+ if (!staticDir) {
+ return;
+ }
+ // Ensure a clean static directory on the first emit.
+ if (this._first && fs.existsSync(staticDir)) {
+ fs.removeSync(staticDir);
+ }
+ this._first = false;
+ fs.copySync(buildDir, staticDir);
+ }.bind(this)
+ );
+};
+
+JupyterFrontEndPlugin.prototype._first = true;
+
+const plugins = [
+ new DuplicatePackageCheckerPlugin({
+ verbose: true,
+ exclude(instance) {
+ // ignore known duplicates
+ return ['domelementtype', 'hash-base', 'inherits'].includes(
+ instance.name
+ );
+ }
+ }),
+ new HtmlWebpackPlugin({
+ template: path.join('templates', 'template.html'),
+ title: jlab.name || 'JupyterLab'
+ }),
+ new webpack.HashedModuleIdsPlugin(),
+ new JupyterFrontEndPlugin({})
+];
+
+if (process.argv.includes('--analyze')) {
+ plugins.push(new Visualizer());
+}
+
+module.exports = [
+ {
+ mode: 'development',
+ entry: {
+ main: ['whatwg-fetch', path.resolve(buildDir, 'index.out.js')]
+ },
+ output: {
+ path: path.resolve(buildDir),
+ publicPath: '{{page_config.bundleUrl}}',
+ filename: '[name].[chunkhash].js'
+ },
+ optimization: {
+ splitChunks: {
+ chunks: 'all'
+ }
+ },
+ module: {
+ rules: [
+ { test: /\.css$/, use: ['style-loader', 'css-loader'] },
+ { test: /\.md$/, use: 'raw-loader' },
+ { test: /\.txt$/, use: 'raw-loader' },
+ {
+ test: /\.js$/,
+ use: ['source-map-loader'],
+ enforce: 'pre',
+ // eslint-disable-next-line no-undef
+ exclude: /node_modules/
+ },
+ { test: /\.(jpg|png|gif)$/, use: 'file-loader' },
+ { test: /\.js.map$/, use: 'file-loader' },
+ {
+ test: /\.woff2(\?v=\d+\.\d+\.\d+)?$/,
+ use: 'url-loader?limit=10000&mimetype=application/font-woff'
+ },
+ {
+ test: /\.woff(\?v=\d+\.\d+\.\d+)?$/,
+ use: 'url-loader?limit=10000&mimetype=application/font-woff'
+ },
+ {
+ test: /\.ttf(\?v=\d+\.\d+\.\d+)?$/,
+ use: 'url-loader?limit=10000&mimetype=application/octet-stream'
+ },
+ {
+ test: /\.otf(\?v=\d+\.\d+\.\d+)?$/,
+ use: 'url-loader?limit=10000&mimetype=application/octet-stream'
+ },
+ { test: /\.eot(\?v=\d+\.\d+\.\d+)?$/, use: 'file-loader' },
+ {
+ test: /\.svg(\?v=\d+\.\d+\.\d+)?$/,
+ use: 'url-loader?limit=10000&mimetype=image/svg+xml'
+ }
+ ]
+ },
+ watchOptions: {
+ ignored: function(localPath) {
+ localPath = path.resolve(localPath);
+ if (localPath in ignoreCache) {
+ return ignoreCache[localPath];
+ }
+
+ // Ignore files with certain patterns
+ var baseName = localPath.replace(/^.*[\\\/]/, ''); // eslint-disable-line
+ if (
+ ignorePatterns.some(function(rexp) {
+ return baseName.match(rexp);
+ })
+ ) {
+ return true;
+ }
+
+ // Limit the watched files to those in our local linked package dirs.
+ var ignore = true;
+ Object.keys(localLinked).some(function(name) {
+ // Bail if already found.
+ var rootPath = localLinked[name];
+ var contained = localPath.indexOf(rootPath + path.sep) !== -1;
+ if (localPath !== rootPath && !contained) {
+ return false;
+ }
+ var rest = localPath.slice(rootPath.length);
+ if (rest.indexOf('node_modules') === -1) {
+ ignore = false;
+ maybeSync(localPath, name, rest);
+ }
+ return true;
+ });
+ ignoreCache[localPath] = ignore;
+ return ignore;
+ }
+ },
+ node: {
+ fs: 'empty'
+ },
+ bail: true,
+ devtool: 'source-map',
+ externals: ['node-fetch', 'ws'],
+ plugins,
+ stats: {
+ chunkModules: true
+ }
+ }
+].concat(extraConfig);
diff --git a/dev_mode/webpack.prod.config.js b/dev_mode/webpack.prod.config.js
new file mode 100644
index 00000000..440abc2b
--- /dev/null
+++ b/dev_mode/webpack.prod.config.js
@@ -0,0 +1,26 @@
+var UglifyJsPlugin = require('uglifyjs-webpack-plugin');
+var merge = require('webpack-merge');
+var config = require('./webpack.config');
+
+config[0] = merge(config[0], {
+ mode: 'production',
+ devtool: 'source-map',
+ optimization: {
+ minimizer: [
+ new UglifyJsPlugin({
+ parallel: true,
+ sourceMap: true,
+ uglifyOptions: {
+ beautify: false,
+ comments: false,
+ compress: false,
+ ecma: 6,
+ mangle: true
+ },
+ cache: process.platform !== 'win32'
+ })
+ ]
+ }
+});
+
+module.exports = config;
diff --git a/docs/Makefile b/docs/Makefile
new file mode 100644
index 00000000..e8d92b90
--- /dev/null
+++ b/docs/Makefile
@@ -0,0 +1,20 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS = -W --keep-going
+SPHINXBUILD = python -msphinx
+SPHINXPROJ = JupyterLab
+SOURCEDIR = source
+BUILDDIR = build
+
+# Put it first so that "make" without argument is like "make help".
+help:
+ @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+.PHONY: help Makefile
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+ @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
diff --git a/docs/environment.yml b/docs/environment.yml
new file mode 100644
index 00000000..4a880119
--- /dev/null
+++ b/docs/environment.yml
@@ -0,0 +1,8 @@
+name: jupyterlab_documentation
+channels:
+ - conda-forge
+dependencies:
+- python=3.5
+- sphinx>=1.8
+- sphinx_rtd_theme
+- recommonmark
diff --git a/docs/make.bat b/docs/make.bat
new file mode 100644
index 00000000..6814d9f1
--- /dev/null
+++ b/docs/make.bat
@@ -0,0 +1,36 @@
+@ECHO OFF
+
+pushd %~dp0
+
+REM Command file for Sphinx documentation
+
+if "%SPHINXBUILD%" == "" (
+ set SPHINXBUILD=python -msphinx
+)
+set SOURCEDIR=source
+set BUILDDIR=build
+set SPHINXPROJ=JupyterLab
+
+if "%1" == "" goto help
+
+%SPHINXBUILD% >NUL 2>NUL
+if errorlevel 9009 (
+ echo.
+ echo.The Sphinx module was not found. Make sure you have Sphinx installed,
+ echo.then set the SPHINXBUILD environment variable to point to the full
+ echo.path of the 'sphinx-build' executable. Alternatively you may add the
+ echo.Sphinx directory to PATH.
+ echo.
+ echo.If you don't have Sphinx installed, grab it from
+ echo.http://sphinx-doc.org/
+ exit /b 1
+)
+
+%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS%
+goto end
+
+:help
+%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS%
+
+:end
+popd
diff --git a/docs/scripts/graph-dependencies.js b/docs/scripts/graph-dependencies.js
new file mode 100644
index 00000000..4da89eae
--- /dev/null
+++ b/docs/scripts/graph-dependencies.js
@@ -0,0 +1,69 @@
+var childProcess = require('child_process');
+var fs = require('fs-extra');
+var glob = require('glob');
+var path = require('path');
+var url = require('url');
+
+var basePath = path.resolve('..');
+var baseUrl = 'https://github.com/jupyterlab/jupyterlab/tree/master/packages';
+var packages = glob.sync(path.join(basePath, 'packages/*'));
+
+// Begin the graph specification
+var text = 'digraph G {\n';
+text += 'ratio = 0.6;\n';
+text += 'rankdir=LR;\n';
+
+packages.forEach(function(packagePath) {
+ // Load the package.json data.
+ var dataPath = path.join(packagePath, 'package.json');
+ try {
+ var data = require(dataPath);
+ } catch (e) {
+ return;
+ }
+
+ // Don't include private packages.
+ if (data.private === true) {
+ return;
+ }
+
+ // Only include packages in the @jupyterlab namespace.
+ if (data.name.indexOf('@jupyterlab') === -1) {
+ return;
+ }
+
+ // In order to cut down on the number of graph nodes,
+ // don't include "*-extension" packages.
+ if (data.name.indexOf('-extension') !== -1) {
+ return;
+ }
+
+ // Don't include the metapackage.
+ if (data.name === '@jupyterlab/metapackage') {
+ return;
+ }
+
+ // Construct a URL to the package on GitHub.
+ var Url = url.resolve(baseUrl, 'packages/' + path.basename(packagePath));
+
+ // Remove the '@jupyterlab' part of the name.
+ var name = '"' + data.name.split('/')[1] + '"';
+ text += name + '[URL="' + Url + '"];\n';
+
+ var deps = data.dependencies || [];
+ for (var dep in deps) {
+ // Don't include non-jupyterlab dependencies.
+ if (dep.indexOf('@jupyterlab') === -1) {
+ continue;
+ }
+ dep = '"' + dep.split('/')[1] + '"';
+ text += name + ' -> ' + dep + ';\n';
+ }
+});
+
+text += '}\n';
+fs.writeFileSync('./dependencies.gv', text);
+childProcess.execSync(
+ 'cat dependencies.gv | tred | dot -Tsvg -o dependency-graph.svg'
+);
+fs.unlink('./dependencies.gv');
diff --git a/docs/source/_static/custom.css b/docs/source/_static/custom.css
new file mode 100644
index 00000000..2b59c601
--- /dev/null
+++ b/docs/source/_static/custom.css
@@ -0,0 +1,59 @@
+.wy-nav-side p.caption {
+ color: #f5f5f5;
+}
+
+div.wy-side-nav-search {
+ background: #f37626;
+}
+
+.wy-nav-content iframe {
+ margin: auto;
+ display: block;
+}
+
+.wy-breadcrumbs-aside img {
+ height: 1em !important;
+}
+
+/* Elevation
+ *
+ * We style box-shadows using Material Design's idea of elevation. These particular numbers are taken from here:
+ *
+ * https://github.com/material-components/material-components-web
+ * https://material-components-web.appspot.com/elevation.html
+ */
+
+.rst-content img.jp-screenshot {
+ border: none;
+ /* MD Elevation 8 */
+ box-shadow: 0px 5px 5px -3px rgba(0, 0, 0, 0.2),
+ 0px 8px 10px 1px rgba(0, 0, 0, 0.14), 0px 3px 14px 2px rgba(0, 0, 0, 0.12);
+ margin-bottom: 24px;
+}
+
+/*
+ * The div.jp-youtube-video styling is done to get the YouTube video to size dynamically
+ * to 100% of the content width.
+ */
+
+.rst-content div.jp-youtube-video {
+ position: relative;
+ width: 100%;
+ height: 0px;
+ /* This must be equal to the inverse of the aspect ratio of the video */
+ /* The current value is: 56.25% = 315/560 */
+ padding-bottom: 56.25%;
+ border: none;
+ /* MD Elevation 8 */
+ box-shadow: 0px 5px 5px -3px rgba(0, 0, 0, 0.2),
+ 0px 8px 10px 1px rgba(0, 0, 0, 0.14), 0px 3px 14px 2px rgba(0, 0, 0, 0.12);
+ margin-bottom: 24px;
+}
+
+.rst-content div.jp-youtube-video iframe {
+ position: absolute;
+ left: 0px;
+ top: 0px;
+ width: 100%;
+ height: 100%;
+}
diff --git a/docs/source/_static/jupyter_logo.svg b/docs/source/_static/jupyter_logo.svg
new file mode 100644
index 00000000..b85d1f4b
--- /dev/null
+++ b/docs/source/_static/jupyter_logo.svg
@@ -0,0 +1,42 @@
+
diff --git a/docs/source/_templates/breadcrumbs.html b/docs/source/_templates/breadcrumbs.html
new file mode 100644
index 00000000..d53215c2
--- /dev/null
+++ b/docs/source/_templates/breadcrumbs.html
@@ -0,0 +1,49 @@
+{% extends '!breadcrumbs.html' %}
+
+{% block breadcrumbs %}
+ {{ _('Docs') }} »
+ {% for doc in parents %}
+ {{ doc.title }} »
+ {% endfor %}
+ {{ title }}
+{% endblock %}
+ {% block breadcrumbs_aside %}
+
+ {% if hasdoc(pagename) %}
+ {% if display_github %}
+ {% if check_meta and 'github_url' in meta %}
+
+ {{ _('Edit on GitHub') }}
+ {% else %}
+ {{ _('Edit on GitHub') }}
+ {% endif %}
+ {% elif display_bitbucket %}
+ {% if check_meta and 'bitbucket_url' in meta %}
+
+ {{ _('Edit on Bitbucket') }}
+ {% else %}
+ {{ _('Edit on Bitbucket') }}
+ {% endif %}
+ {% elif display_gitlab %}
+ {% if check_meta and 'gitlab_url' in meta %}
+
+ {{ _('Edit on GitLab') }}
+ {% else %}
+ {{ _('Edit on GitLab') }}
+ {% endif %}
+ {% elif show_source and source_url_prefix %}
+ {{ _('View page source') }}
+ {% elif show_source and has_source and sourcename %}
+ {{ _('View page source') }}
+ {% endif %}
+ {% endif %}
+
+
+
+  }})
+ {{ _('Jupyter') }}
+
+ |
+
+
+{% endblock %}
diff --git a/docs/source/_templates/footer.html b/docs/source/_templates/footer.html
new file mode 100644
index 00000000..b91bf270
--- /dev/null
+++ b/docs/source/_templates/footer.html
@@ -0,0 +1,54 @@
+
+
diff --git a/docs/source/conf.py b/docs/source/conf.py
new file mode 100644
index 00000000..f2b95638
--- /dev/null
+++ b/docs/source/conf.py
@@ -0,0 +1,247 @@
+#!/usr/bin/env python3
+# -*- coding: utf-8 -*-
+#
+# JupyterLab documentation build configuration file, created by
+# sphinx-quickstart on Thu Jan 4 15:10:23 2018.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#
+# import os
+# import sys
+# sys.path.insert(0, os.path.abspath('.'))
+
+# For conversion from markdown to html
+import recommonmark.parser
+from recommonmark.transform import AutoStructify
+
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#
+# needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = ['sphinx.ext.intersphinx',
+ 'sphinx.ext.mathjax']
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+#
+# source_suffix = ['.rst', '.md']
+
+source_parsers = {
+ '.md': 'recommonmark.parser.CommonMarkParser',
+}
+
+source_suffix = ['.rst', '.md']
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = 'JupyterLab'
+copyright = '2018, Project Jupyter'
+author = 'Project Jupyter'
+
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+
+import os
+_version_py = os.path.join('..', '..', 'jupyterlab', '_version.py')
+version_ns = {}
+
+with open(_version_py, mode='r') as version_file:
+ exec(version_file.read(), version_ns)
+
+# The short X.Y version.
+version = '%i.%i' % version_ns['version_info'][:2]
+# The full version, including alpha/beta/rc tags.
+release = version_ns['__version__']
+
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+# This patterns also effect to html_static_path and html_extra_path
+exclude_patterns = []
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = False
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages. See the documentation for
+# a list of builtin themes.
+#
+import sphinx_rtd_theme
+html_theme = "sphinx_rtd_theme"
+html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further. For a list of options available for each theme, see the
+# documentation.
+#
+# html_theme_options = {}
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Custom sidebar templates, must be a dictionary that maps document names
+# to template names.
+#
+# This is required for the alabaster theme
+# refs: http://alabaster.readthedocs.io/en/latest/installation.html#sidebars
+html_sidebars = {
+ '**': [
+ 'about.html',
+ 'navigation.html',
+ 'relations.html', # needs 'show_related': True theme option to display
+ 'searchbox.html',
+ 'donate.html',
+ ]
+}
+
+# Output for github to be used in links
+html_context = {
+ "display_github": True, # Integrate GitHub
+ "github_user": "jupyterlab", # Username
+ "github_repo": "jupyterlab", # Repo name
+ "github_version": "master", # Version
+ "conf_py_path": "/docs/source/", # Path in the checkout to the docs root
+}
+
+# -- Options for HTMLHelp output ------------------------------------------
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'JupyterLabdoc'
+
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+ # The paper size ('letterpaper' or 'a4paper').
+ #
+ # 'papersize': 'letterpaper',
+
+ # The font size ('10pt', '11pt' or '12pt').
+ #
+ # 'pointsize': '10pt',
+
+ # Additional stuff for the LaTeX preamble.
+ #
+ # 'preamble': '',
+
+ # Latex figure (float) alignment
+ #
+ # 'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+# author, documentclass [howto, manual, or own class]).
+latex_documents = [
+ (master_doc, 'JupyterLab.tex', 'JupyterLab Documentation',
+ 'Project Jupyter', 'manual'),
+]
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+ (master_doc, 'jupyterlab', 'JupyterLab Documentation',
+ [author], 1)
+]
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+# dir menu entry, description, category)
+texinfo_documents = [
+ (master_doc, 'JupyterLab', 'JupyterLab Documentation',
+ author, 'JupyterLab', 'One line description of project.',
+ 'Miscellaneous'),
+]
+
+
+
+# -- Options for Epub output ----------------------------------------------
+
+# Bibliographic Dublin Core info.
+epub_title = project
+epub_author = author
+epub_publisher = author
+epub_copyright = copyright
+
+# The unique identifier of the text. This can be a ISBN number
+# or the project homepage.
+#
+# epub_identifier = ''
+
+# A unique identification for the text.
+#
+# epub_uid = ''
+
+# A list of files that should not be packed into the epub file.
+epub_exclude_files = ['search.html']
+
+
+
+# Example configuration for intersphinx: refer to the Python standard library.
+intersphinx_mapping = {'https://docs.python.org/': None}
+
+
+# autodoc configuration with AutoStructify
+#
+# See http://recommonmark.readthedocs.io/en/latest/auto_structify.html
+# See the setup function in current conf.py file in the recommonmark repo
+# https://github.com/rtfd/recommonmark/blob/master/docs/conf.py#L296
+github_doc_root = 'https://github.com/jupyterlab/jupyterlab/tree/master/docs/'
+
+# We can't rely on anchors because GitHub dynamically renders them for
+# markdown documents.
+linkcheck_anchors = False
+
+def setup(app):
+ app.add_config_value('recommonmark_config', {
+ 'url_resolver': lambda url: github_doc_root + url,
+ 'auto_toc_tree_section': 'Contents',
+ 'enable_eval_rst': True,
+ 'enable_auto_doc_ref': False,
+ }, True)
+ app.add_transform(AutoStructify)
+ app.add_stylesheet('custom.css') # may also be an URL
diff --git a/docs/source/developer/adding_content.rst b/docs/source/developer/adding_content.rst
new file mode 100644
index 00000000..ab3938a5
--- /dev/null
+++ b/docs/source/developer/adding_content.rst
@@ -0,0 +1,40 @@
+Adding Content
+--------------
+
+As an example: Add a leaflet viewer plugin for geoJSON files.
+
+- Go to npm: search for
+ `leaflet `__ (success!).
+
+- Go to ``jupyterlab`` top level source directory:
+ ``jlpm add leaflet``. This adds the file to the ``dependencies`` in
+ ``package.json``.
+
+- Next we see if there is a typing declaration for leaflet:
+ ``jlpm add --dev @types/leaflet``. Success!
+
+- If there are no typings, we must create our own. An example typings
+ file that exports functions is
+ `codemirror `__.
+ An example with a class is
+ `vdom `__.
+
+- Add a reference to the new library in ``src/typings.d.ts``.
+
+- Create a folder in ``src`` for the plugin.
+
+- Add ``index.ts`` and ``plugin.ts`` files.
+
+- If creating CSS, import them in ``src/default-themes/index.css``.
+
+- The ``index.ts`` file should have the core logic for the plugin. In
+ this case, it should create a widget and widget factory for rendering
+ geojson files (see :ref:`documents`).
+
+- The ``plugin.ts`` file should create the extension and add the
+ content to the application. In this case registering the widget
+ factory using the document registry.
+
+- Run ``jlpm run build`` from ``jupyterlab/jupyterlab``
+
+- Run ``jupyter lab`` and verify changes.
diff --git a/docs/source/developer/css.rst b/docs/source/developer/css.rst
new file mode 100644
index 00000000..3ad6296f
--- /dev/null
+++ b/docs/source/developer/css.rst
@@ -0,0 +1,193 @@
+CSS Patterns
+------------
+
+This document describes the patterns we are using to organize and write
+CSS for JupyterLab. JupyterLab is developed using a set of npm packages
+that are located in ``packages``. Each of these packages has its own
+style, but depend on CSS variables defined in a main theme package.
+
+CSS checklist
+~~~~~~~~~~~~~
+
+- CSS classnames are defined inline in the code. We used to put them as
+ all caps file-level ``const``\ s, but we are moving away from that.
+- CSS files for packages are located within the ``style``
+ subdirectory and imported into the plugin's ``index.css``.
+- The JupyterLab default CSS variables in the ``theme-light-extension``
+ and ``theme-dark-extension`` packages are used to style packages
+ where ever possible. Individual packages should not npm-depend on
+ these packages though, to enable the theme to be swapped out.
+- Additional public/private CSS variables are defined by plugins
+ sparingly and in accordance with the conventions described below.
+
+CSS variables
+~~~~~~~~~~~~~
+
+We are using native CSS variables in JupyterLab. This is to enable
+dynamic theming of built-in and third party plugins. As of December
+2017, CSS variables are supported in the latest stable versions of all
+popular browsers, except for IE. If a JupyterLab deployment needs to
+support these browsers, a server side CSS preprocessor such as Myth or
+cssnext may be used.
+
+Naming of CSS variables
+^^^^^^^^^^^^^^^^^^^^^^^
+
+We use the following convention for naming CSS variables:
+
+- Start all CSS variables with ``--jp-``.
+- Words in the variable name should be lowercase and separated with
+ ``-``.
+- The next segment should refer to the component and subcomponent, such
+ as ``--jp-notebook-cell-``.
+- The next segment should refer to any state modifiers such as
+ ``active``, ``not-active`` or ``focused``:
+ ``--jp-notebook-cell-focused``.
+- The final segment will typically be related to a CSS properties, such
+ as ``color``, ``font-size`` or ``background``:
+ ``--jp-notebook-cell-focused-background``.
+
+Public/private
+^^^^^^^^^^^^^^
+
+Some CSS variables in JupyterLab are considered part of our public API.
+Others are considered private and should not be used by third party
+plugins or themes. The difference between public and private variables
+is simple:
+
+- All private variables begin with ``--jp-private-``
+- All variables without the ``private-`` prefix are public.
+- Public variables should be defined under the ``:root``
+ pseudo-selector. This ensures that public CSS variables can be
+ inspected under the top-level ```` tag in the browser's dev
+ tools.
+- Where possible, private variables should be defined and scoped under
+ an appropriate selector other than ``:root``.
+
+CSS variable usage
+^^^^^^^^^^^^^^^^^^
+
+JupyterLab includes a default set of CSS variables in the file:
+
+``packages/theme-light-extension/style/variables.css``
+
+To ensure consistent design in JupyterLab, all built-in and third party
+extensions should use these variables in their styles if at all
+possible. Documentation about those variables can be found in the
+``variables.css`` file itself.
+
+Plugins are free to define additional public and private CSS variables
+in their own ``index.css`` file, but should do so sparingly.
+
+Again, we consider the names of the public CSS variables in this package
+to be our public API for CSS.
+
+File organization
+~~~~~~~~~~~~~~~~~
+
+We are organizing our CSS files in the following manner:
+
+- Each package in the top-level ``packages`` directory should contain
+ any CSS files in a ``style`` subdirectory that are needed to style
+ itself.
+- Multiple CSS files may be used and organized as needed, but they
+ should be imported into a single ``index.css`` at the top-level of
+ the plugin as `import '../style/index.css';`.
+
+CSS class names
+~~~~~~~~~~~~~~~
+
+We have a fairly formal method for naming our CSS classes.
+
+First, CSS class names are associated with TypeScript classes that
+extend ``phosphor.Widget``:
+
+The ``.node`` of each such widget should have a CSS class that matches
+the name of the TypeScript class:
+
+.. code:: TypeScript
+
+
+
+ class MyWidget extends Widget {
+
+ constructor() {
+ super();
+ this.addClass('jp-MyWidget');
+ }
+
+ }
+
+Second, subclasses should have a CSS class for both the parent and
+child:
+
+.. code:: TypeScript
+
+ class MyWidgetSubclass extends MyWidget {
+
+ constructor() {
+ super(); // Adds `jp-MyWidget`
+ this.addClass('jp-MyWidgetSubclass');
+ }
+
+ }
+
+In both of these cases, CSS class names with caps-case are reserved for
+situations where there is a named TypeScript ``Widget`` subclass. These
+classes are a way of a TypeScript class providing a public API for
+styling.
+
+Third, children nodes of a ``Widget`` should have a third segment in the
+CSS class name that gives a semantic naming of the component, such as:
+
+- ``jp-MyWidget-toolbar``
+- ``jp-MyWidget-button``
+- ``jp-MyWidget-contentButton``
+
+In general, the parent ``MyWidget`` should add these classes to the
+children. This applies when the children are plain DOM nodes or
+``Widget`` instances/subclasses themselves. Thus, the general naming of
+CSS classes is of the form ``jp-WidgetName-semanticChild``. This enables
+the styling of these children in a manner that is independent of the
+children implementation or CSS classes they have themselves.
+
+Fourth, some CSS classes are used to modify the state of a widget:
+
+- ``jp-mod-active``: applied to elements in the active state
+- ``jp-mod-hover``: applied to elements in the hover state
+- ``jp-mod-selected``: applied to elements while selected
+
+Fifth, some CSS classes are used to distinguish different types of a
+widget:
+
+- ``jp-type-separator``: applied to menu items that are separators
+- ``jp-type-directory``: applied to elements in the file browser that
+ are directories
+
+Edge cases
+~~~~~~~~~~
+
+Over time, we have found that there are some edge cases that these rules
+don't fully address. Here, we try to clarify those edge cases.
+
+**When should a parent add a class to children?**
+
+Above, we state that a parent (``MyWidget``), should add CSS classes to
+children that indicate the semantic function of the child. Thus, the
+``MyWidget`` subclass of ``Widget`` should add ``jp-MyWidget`` to itself
+and ``jp-MyWidget-toolbar`` to a toolbar child.
+
+What if the child itself is a ``Widget`` and already has a proper CSS
+class name itself, such as ``jp-Toolbar``? Why not use selectors such as
+``.jp-MyWidget .jp-Toolbar`` or ``.jp-MyWidget > .jp-Toolbar``?
+
+The reason is that these selectors are dependent on the implementation
+of the toolbar having the ``jp-Toolbar`` CSS class. When ``MyWidget``
+adds the ``jp-MyWidget-toolbar`` class, it can style the child
+independent of its implementation. The other reason to add the
+``jp-MyWidget-toolbar`` class is if the DOM structure is highly
+recursive, the usual descendant selectors may not be specific to target
+only the desired children.
+
+When in doubt, there is little harm done in parents adding selectors to
+children.
diff --git a/docs/source/developer/dependency-graph.svg b/docs/source/developer/dependency-graph.svg
new file mode 100644
index 00000000..7fd04ab6
--- /dev/null
+++ b/docs/source/developer/dependency-graph.svg
@@ -0,0 +1,502 @@
+
+
+
+
+
diff --git a/docs/source/developer/documentation.rst b/docs/source/developer/documentation.rst
new file mode 100644
index 00000000..abe35d7c
--- /dev/null
+++ b/docs/source/developer/documentation.rst
@@ -0,0 +1,150 @@
+Writing Documentation
+---------------------
+
+This section provides information about writing documentation for JupyterLab.
+See our `Contributor
+Guide `_ for
+details on installation and testing.
+
+Writing Style
+~~~~~~~~~~~~~
+
+- The documentation should be written in the second person, referring
+ to the reader as "you" and not using the first person plural "we."
+ The author of the documentation is not sitting next to the user, so
+ using "we" can lead to frustration when things don't work as
+ expected.
+- Avoid words that trivialize using JupyterLab such as "simply" or
+ "just." Tasks that developers find simple or easy may not be for
+ users.
+- Write in the active tense, so "drag the notebook cells..." rather
+ than "notebook cells can be dragged..."
+- The beginning of each section should begin with a short (1-2
+ sentence) high-level description of the topic, feature or component.
+- Use "enable" rather than "allow" to indicate what JupyterLab makes
+ possible for users. Using "allow" connotes that we are giving them
+ permission, whereas "enable" connotes empowerment.
+
+User Interface Naming Conventions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Documents, Files, and Activities
+''''''''''''''''''''''''''''''''
+
+Files are referrred to as either files or documents, depending on the context.
+
+Documents are more human centered. If human viewing, interpretation, interaction
+is an important part of the experience, it is a document in that context. For
+example, notebooks and markdown files will often be referring to as documents
+unless referring to the file-ness aspect of it (e.g., the notebook filename).
+
+Files are used in a less human-focused context. For example, we refer to files
+in relation to a file system or file name.
+
+Activities can be either a document or another UI panel that is not file backed,
+such as terminals, consoles or the inspector. An open document or file is an
+activity in that it is represented by a panel that you can interact with.
+
+
+Element Names
+'''''''''''''
+
+- The generic content area of a tabbed UI is a panel, but prefer to refer to the
+ more specific name, such as “File browser.” Tab bars have tabs which toggle
+ panels.
+- The menu bar contains menu items, which have their own submenus.
+- The main work area can be referred to as the work area when the name is unambiguous.
+- When describing elements in the UI, colloquial names are preferred
+ (e.g., “File browser” instead of “Files panel”).
+
+The majority of names are written in lower case. These names include:
+
+- tab
+- panel
+- menu bar
+- sidebar
+- file
+- document
+- activity
+- tab bar
+- main work area
+- file browser
+- command palette
+- cell inspector
+- code console
+
+The following sections of the user interface should be in title case, directly
+quoting a word in the UI:
+
+- File menu
+- Files tab
+- Running panel
+- Tabs panel
+- Single-Document Mode
+
+The capitalized words match the label of the UI element the user is clicking on
+because there does not exist a good colloquial name for the tool, such as “file
+browser” or “command palette”.
+
+See :ref:`interface` for descriptions of elements in the UI.
+
+Keyboard Shortcuts
+~~~~~~~~~~~~~~~~~~
+
+Typeset keyboard shortcuts as follows:
+
+- Monospace typeface, with spaces between individual keys:
+ ``Shift Enter``.
+- For modifiers, use the platform independent word describing key:
+ ``Shift``.
+- For the ``Accel`` key use the phrase: ``Command/Ctrl``.
+- Don’t use platform specific icons for modifier keys, as they are
+ difficult to display in a platform specific way on Sphinx/RTD.
+
+Screenshots and Animations
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Our documentation should contain screenshots and animations that
+illustrate and demonstrate the software. Here are some guidelines for
+preparing them:
+
+- Set screen resolution to non-hidpi (non-retina)
+
+- Set browser viewport to 1280x720 px.
+ The Firefox Web Developer extension and Chrome Developer Tools offer
+ device specific rendering that enables you to set this viewport resolution.
+
+- Capture the viewport, **not the full browser window**,
+ using the capture software of your choice. **Do not include any of the
+ desktop background**.
+
+- For PNGs, reduce their size using pngquant.
+ For movies, upload them to the IPython/Juptyter YouTube channel
+ and embed them in the docs with an iframe. The pngs can live in the main repository.
+ The movies should be added to the ``jupyterlab-media`` repository.
+
+- Use `www.youtube-nocookie.com` website, which can be found by
+ clicking on the 'privacy-enhanced' embedding option in the Share dialog on YouTube.
+ Add the following parameters the end of the URL ``?rel=0&showinfo=0``.
+ This disables the video title and related video suggestions.
+
+- Screenshots or animations should be proceeded by a sentence
+ describing the content, such as "To open a file, double-click on its
+ name in the File Browser:".
+
+- We have custom CSS that will add box shadows, and proper sizing of screenshots and
+ embedded YouTube videos. See examples in the documentation for how to embed these
+ assets.
+
+To help us organize screenshots and animations, please name the files with a prefix
+that matches the names of the source file in which they are used:
+
+ ::
+
+ sourcefile.rst
+ sourcefile_filebrowser.png
+ sourcefile_editmenu.png
+
+This will help us to keep track of the images as documentation content evolves.
+
+
diff --git a/docs/source/developer/documents.rst b/docs/source/developer/documents.rst
new file mode 100644
index 00000000..f7c091db
--- /dev/null
+++ b/docs/source/developer/documents.rst
@@ -0,0 +1,130 @@
+.. _documents:
+
+Documents
+---------
+
+JupyterLab can be extended in several ways:
+
+- Extensions (top level): Application extensions extend the
+ functionality of JupyterLab itself, and we cover them in the
+ :ref:`developer_extensions`.
+- **Document widget extensions (lower level):** Document widget
+ extensions extend the functionality of document widgets added to the
+ application, and we cover them in this section.
+
+For this section, the term 'document' refers to any visual thing that
+is backed by a file stored on disk (i.e. uses Contents API).
+
+Overview of document architecture
+---------------------------------
+
+A 'document' in JupyterLab is represented by a model instance implementing the `IModel `__ interface. The model interface is intentionally fairly small, and concentrates on representing the data in the document and signaling changes to that data. Each model has an associated `context `__ instance as well. The context for a model is the bridge between the internal data of the document, stored in the model, and the file metadata and operations possible on the file, such as save and revert. Since many objects will need both the context and the model, the context contains a reference to the model as its `.model` attribute.
+
+A single file path can have multiple different models (and hence different contexts) representing the file. For example, a notebook can be opened with a notebook model and with a text model. Different models for the same file path do not directly communicate with each other.
+
+`Document widgets `__ represent a view of a document model. There can be multiple document widgets associated with a single document model, and they naturally stay in sync with each other since they are views on the same underlying data model.
+
+
+The `Document
+Registry `__
+is where document types and factories are registered. Plugins can
+require a document registry instance and register their content types
+and providers.
+
+The `Document
+Manager `__
+uses the Document Registry to create models and widgets for documents.
+The Document Manager is only meant to be accessed by the File Browser
+itself.
+
+Document Registry
+~~~~~~~~~~~~~~~~~
+
+*Document widget extensions* in the JupyterLab application can register:
+
+- file types
+- model factories for specific file types
+- widget factories for specific model factories
+- widget extension factories
+- file creators
+
+`Widget Factories `__
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Create a widget for a given file.
+
+*Example*
+
+- The notebook widget factory that creates NotebookPanel widgets.
+
+`Model Factories `__
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Create a model for a given file.
+
+Models are generally differentiated by the contents options used to
+fetch the model (e.g. text, base64, notebook).
+
+`Widget Extension Factories `__
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Adds additional functionality to a widget type. An extension instance is
+created for each widget instance, enabling the extension to add
+functionality to each widget or observe the widget and/or its context.
+
+*Examples*
+
+- The ipywidgets extension that is created for NotebookPanel widgets.
+- Adding a button to the toolbar of each NotebookPanel widget.
+
+`File Types `__
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Intended to be used in a "Create New" dialog, providing a list of known
+file types.
+
+`File Creators `__
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Intended for create quick launch file creators.
+
+The default use will be for the "create new" dropdown in the file
+browser, giving list of items that can be created with default options
+(e.g. "Python 3 Notebook").
+
+`Document Models `__
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Created by the model factories and passed to widget factories and widget
+extension factories. Models are the way in which we interact with the
+data of a document. For a simple text file, we typically only use the
+``to/fromString()`` methods. A more complex document like a Notebook
+contains more points of interaction like the Notebook metadata.
+
+`Document Contexts `__
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Created by the Document Manager and passed to widget factories and
+widget extensions. The context contains the model as one of its
+properties so that we can pass a single object around.
+
+They are used to provide an abstracted interface to the session and
+contents API from ``@jupyterlab/services`` for the given model. They can
+be shared between widgets.
+
+The reason for a separate context and model is so that it is easy to
+create model factories and the heavy lifting of the context is left to
+the Document Manager. Contexts are not meant to be subclassed or
+re-implemented. Instead, the contexts are intended to be the glue
+between the document model and the wider application.
+
+Document Manager
+~~~~~~~~~~~~~~~~
+
+The *Document Manager* handles:
+
+- document models
+- document contexts
+
+The *File Browser* uses the *Document Manager* to open documents and
+manage them.
diff --git a/docs/source/developer/examples.rst b/docs/source/developer/examples.rst
new file mode 100644
index 00000000..b93c932a
--- /dev/null
+++ b/docs/source/developer/examples.rst
@@ -0,0 +1,56 @@
+Examples
+--------
+
+The ``examples`` directory in the JupyterLab repo contains:
+
+- several stand-alone examples (``console``, ``filebrowser``,
+ ``notebook``, ``terminal``)
+- a more complex example (``lab``).
+
+Installation instructions for the examples are found in the project's
+README.
+
+After installing the jupyter notebook server 4.2+, follow the steps for
+installing the development version of JupyterLab. To build the examples,
+enter from the ``jupyterlab`` repo root directory:
+
+::
+
+ jlpm run build:examples
+
+To run a particular example, navigate to the example's subdirectory in
+the ``examples`` directory and enter:
+
+::
+
+ python main.py
+
+Dissecting the 'filebrowser' example
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The filebrowser example provides a stand-alone implementation of a
+filebrowser. Here's what the filebrowser's user interface looks like:
+
+|filebrowser user interface|
+
+Let's take a closer look at the source code in ``examples/filebrowser``.
+
+Directory structure of 'filebrowser' example
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The filebrowser in ``examples/filebrowser`` is comprised by a handful of
+files and the ``src`` directory:
+
+|filebrowser source code|
+
+The filebrowser example has two key source files:
+
+- ``src/index.ts``: the TypeScript file that defines the functionality
+- ``main.py``: the Python file that enables the example to be run
+
+Reviewing the source code of each file will help you see the role that
+each file plays in the stand-alone filebrowser example.
+
+.. |filebrowser user interface| image:: filebrowser_example.png
+.. |filebrowser source code| image:: filebrowser_source.png
+
diff --git a/docs/source/developer/extension_dev.rst b/docs/source/developer/extension_dev.rst
new file mode 100644
index 00000000..8abab55f
--- /dev/null
+++ b/docs/source/developer/extension_dev.rst
@@ -0,0 +1,604 @@
+.. _developer_extensions:
+
+Extension Developer Guide
+-------------------------
+
+.. warning::
+
+ The extension developer API is not stable and will evolve in JupyterLab
+ releases in the near future.
+
+JupyterLab can be extended in four ways via:
+
+- **application plugins (top level):** Application plugins extend the
+ functionality of JupyterLab itself.
+- **mime renderer extensions (top level):** Mime Renderer extensions are
+ a convenience for creating an extension that can render mime data and
+ potentially render files of a given type.
+- **theme extensions (top level):** Theme extensions allow you to customize the appearance of
+ JupyterLab by adding your own fonts, CSS rules, and graphics to the application.
+- **document widget extensions (lower level):** Document widget extensions
+ extend the functionality of document widgets added to the
+ application, and we cover them in :ref:`documents`.
+
+See :ref:`xkcd_extension_tutorial` to learn how to make a simple JupyterLab extension.
+
+A JupyterLab application is comprised of:
+
+- A core Application object
+- Plugins
+
+Plugins
+~~~~~~~
+
+A plugin adds a core functionality to the application:
+
+- A plugin can require other plugins for operation.
+- A plugin is activated when it is needed by other plugins, or when
+ explicitly activated.
+- Plugins require and provide ``Token`` objects, which are used to
+ provide a typed value to the plugin's ``activate()`` method.
+- The module providing plugin(s) must meet the
+ `JupyterLab.IPluginModule `__
+ interface, by exporting a plugin object or array of plugin objects as
+ the default export.
+
+ We provide two cookie cutters to create JuptyerLab plugin extensions in
+ `CommonJS `__ and
+ `TypeScript `__.
+
+The default plugins in the JupyterLab application include:
+
+- `Terminal `__
+ - Adds the ability to create command prompt terminals.
+- `Shortcuts `__
+ - Sets the default set of shortcuts for the application.
+- `Images `__
+ - Adds a widget factory for displaying image files.
+- `Help `__
+ - Adds a side bar widget for displaying external documentation.
+- `File
+ Browser `__
+ - Creates the file browser and the document manager and the file
+ browser to the side bar.
+- `Editor `__
+ - Add a widget factory for displaying editable source files.
+- `Console `__
+ - Adds the ability to launch Jupyter Console instances for
+ interactive kernel console sessions.
+
+A dependency graph for the core JupyterLab plugins (along with links to
+their source) is shown here: |dependencies|
+
+.. danger::
+
+ Installing an extension allows for arbitrary code execution on the
+ server, kernel, and in the client's browser. You should therefore
+ take steps to protect against malicious changes to your extension's
+ code. This includes ensuring strong authentication for your npm
+ account.
+
+
+Application Object
+~~~~~~~~~~~~~~~~~~
+
+A Jupyter front-end application object is given to each plugin in its
+``activate()`` function. The application object has:
+
+- commands - used to add and execute commands in the application.
+- keymap - used to add keyboard shortcuts to the application.
+- shell - a generic Jupyter front-end shell instance.
+
+Jupyter Front-End Shell
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The Jupyter front-end
+`shell `__
+is used to add and interact with content in the application. The ``IShell``
+interface provides an ``add()`` method for adding widgets to the application.
+In JupyterLab, the application shell consists of:
+
+- A ``top`` area for things like top level menus and toolbars.
+- ``left`` and ``right`` side bar areas for collapsible content.
+- A ``main`` work area for user activity.
+- A ``bottom`` area for things like status bars.
+- A ``header`` area for custom elements.
+
+Phosphor
+~~~~~~~~
+
+The Phosphor library is used as the underlying architecture of
+JupyterLab and provides many of the low level primitives and widget
+structure used in the application. Phosphor provides a rich set of
+widgets for developing desktop-like applications in the browser, as well
+as patterns and objects for writing clean, well-abstracted code. The
+widgets in the application are primarily **Phosphor widgets**, and
+Phosphor concepts, like message passing and signals, are used
+throughout. **Phosphor messages** are a *many-to-one* interaction that
+enables information like resize events to flow through the widget
+hierarchy in the application. **Phosphor signals** are a *one-to-many*
+interaction that enable listeners to react to changes in an observed
+object.
+
+Extension Authoring
+~~~~~~~~~~~~~~~~~~~
+
+An Extension is a valid `npm
+package `__ that
+meets the following criteria:
+
+- Exports one or more JupyterLab plugins as the default export in its
+ main file.
+- Has a ``jupyterlab`` key in its ``package.json`` which has
+ ``"extension"`` metadata. The value can be ``true`` to use the main
+ module of the package, or a string path to a specific module (e.g.
+ ``"lib/foo"``).
+- It is also recommended to include the keyword ``jupyterlab-extension``
+ in the ``package.json``, to aid with discovery (e.g. by the extension
+ manager).
+
+While authoring the extension, you can use the command:
+
+.. code:: bash
+
+ npm install # install npm package dependencies
+ npm run build # optional build step if using TypeScript, babel, etc.
+ jupyter labextension install # install the current directory as an extension
+
+This causes the builder to re-install the source folder before building
+the application files. You can re-build at any time using
+``jupyter lab build`` and it will reinstall these packages. You can also
+link other local npm packages that you are working on simultaneously
+using ``jupyter labextension link``; they will be re-installed but not
+considered as extensions. Local extensions and linked packages are
+included in ``jupyter labextension list``.
+
+When using local extensions and linked packages, you can run the command
+
+::
+
+ jupyter lab --watch
+
+This will cause the application to incrementally rebuild when one of the
+linked packages changes. Note that only compiled JavaScript files (and
+the CSS files) are watched by the WebPack process. This means that if
+your extension is in TypeScript you'll have to run a ``jlpm run build``
+before the changes will be reflected in JupyterLab. To avoid this step
+you can also watch the TypeScript sources in your extension which is
+usually assigned to the ``tsc -w`` shortcut. If WebPack doesn't seem to
+detect the changes, this can be related to `the number of available watches `__.
+
+Note that the application is built against **released** versions of the
+core JupyterLab extensions. If your extension depends on JupyterLab
+packages, it should be compatible with the dependencies in the
+``jupyterlab/static/package.json`` file. Note that building will always use the latest JavaScript packages that meet the dependency requirements of JupyterLab itself and any installed extensions. If you wish to test against a
+specific patch release of one of the core JupyterLab packages you can
+temporarily pin that requirement to a specific version in your own
+dependencies.
+
+If you must install a extension into a development branch of JupyterLab, you have to graft it into the source tree of JupyterLab itself. This may be done using the command
+
+::
+
+ jlpm run add:sibling
+
+in the JupyterLab root directory, where ```` refers either
+to an extension npm package on the local file system, or a URL to a git
+repository for an extension npm package. This operation may be
+subsequently reversed by running
+
+::
+
+ jlpm run remove:package
+
+This will remove the package metadata from the source tree, but will
+**not** remove any files added by the ``addsibling`` script, which
+should be removed manually.
+
+The package should export EMCAScript 5 compatible JavaScript. It can
+import CSS using the syntax ``require('foo.css')``. The CSS files can
+also import CSS from other packages using the syntax
+``@import url('~foo/index.css')``, where ``foo`` is the name of the
+package.
+
+The following file types are also supported (both in JavaScript and
+CSS): ``json``, ``html``, ``jpg``, ``png``, ``gif``, ``svg``,
+``js.map``, ``woff2``, ``ttf``, ``eot``.
+
+If your package uses any other file type it must be converted to one of
+the above types or `include a loader in the import statement `__.
+If you include a loader, the loader must be importable at build time, so if
+it is not already installed by JupyterLab, you must add it as a dependency
+of your extension.
+
+If your JavaScript is written in any other dialect than
+EMCAScript 6 (2015) it should be converted using an appropriate tool.
+You can use Webpack to pre-build your extension to use any of it's features
+not enabled in our build config. To build a compatible package set
+``output.libraryTarget`` to ``"commonjs2"`` in your Webpack config.
+(see `this `__ example repo).
+
+If you publish your extension on ``npm.org``, users will be able to install
+it as simply ``jupyter labextension install ``, where ```` is
+the name of the published npm package. You can alternatively provide a
+script that runs ``jupyter labextension install`` against a local folder
+path on the user's machine or a provided tarball. Any valid
+``npm install`` specifier can be used in
+``jupyter labextension install`` (e.g. ``foo@latest``, ``bar@3.0.0.0``,
+``path/to/folder``, and ``path/to/tar.gz``).
+
+There are a number of helper functions in ``testutils`` in this repo (which
+is a public npm package called ``@jupyterlab/testutils``) that can be used when
+writing tests for an extension. See ``tests/test-application`` for an example
+of the infrastructure needed to run tests. There is a ``karma`` config file
+that points to the parent directory's ``karma`` config, and a test runner,
+``run-test.py`` that starts a Jupyter server.
+
+
+Mime Renderer Extensions
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Mime Renderer extensions are a convenience for creating an extension
+that can render mime data and potentially render files of a given type.
+We provide cookiecutters for Mime render extensions in
+`JavaScript `__ and
+`TypeScript `__.
+
+Mime renderer extensions are more declarative than standard extensions.
+The extension is treated the same from the command line perspective
+(``jupyter labextension install`` ), but it does not directly create
+JupyterLab plugins. Instead it exports an interface given in the
+`rendermime-interfaces `__
+package.
+
+The JupyterLab repo has an example mime renderer extension for
+`pdf `__
+files. It provides a mime renderer for pdf data and registers itself as
+a document renderer for pdf file types.
+
+The ``rendermime-interfaces`` package is intended to be the only
+JupyterLab package needed to create a mime renderer extension (using the
+interfaces in TypeScript or as a form of documentation if using plain
+JavaScript).
+
+The only other difference from a standard extension is that has a
+``jupyterlab`` key in its ``package.json`` with ``"mimeExtension"``
+metadata. The value can be ``true`` to use the main module of the
+package, or a string path to a specific module (e.g. ``"lib/foo"``).
+
+The mime renderer can update its data by calling ``.setData()`` on the
+model it is given to render. This can be used for example to add a
+``png`` representation of a dynamic figure, which will be picked up by a
+notebook model and added to the notebook document. When using
+``IDocumentWidgetFactoryOptions``, you can update the document model by
+calling ``.setData()`` with updated data for the rendered MIME type. The
+document can then be saved by the user in the usual manner.
+
+Themes
+~~~~~~
+
+A theme is a JupyterLab extension that uses a ``ThemeManager`` and can
+be loaded and unloaded dynamically. The package must include all static
+assets that are referenced by ``url()`` in its CSS files. Local URLs can
+be used to reference files relative to the location of the referring sibling CSS files. For example ``url('images/foo.png')`` or
+``url('../foo/bar.css')``\ can be used to refer local files in the
+theme. Absolute URLs (starting with a ``/``) or external URLs (e.g.
+``https:``) can be used to refer to external assets. The path to the
+theme asset entry point is specified ``package.json`` under the ``"jupyterlab"``
+key as ``"themePath"``. See the `JupyterLab Light
+Theme `__
+for an example. Ensure that the theme files are included in the
+``"files"`` metadata in package.json. Note that if you want to use SCSS, SASS, or LESS files,
+you must compile them to CSS and point JupyterLab to the CSS files.
+
+To quickly create a theme based on the JupyterLab Light Theme, follow
+the instructions in the `contributing
+guide `__ and
+then run ``jlpm run create:theme`` from the repository root directory.
+Once you select a name, title and a description, a new theme folder will
+be created in the current directory. You can move that new folder to a
+location of your choice, and start making desired changes.
+
+The theme extension is installed in the same way as a regular extension (see
+`extension authoring <#extension-authoring>`__).
+
+Standard (General-Purpose) Extensions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+JupyterLab's modular architecture is based around the idea
+that all extensions are on equal footing, and that they interact
+with each other through typed interfaces that are provided by ``Token`` objects.
+An extension can provide a ``Token`` to the application,
+which other extensions can then request for their own use.
+
+Core Tokens
+^^^^^^^^^^^
+
+The core packages of JupyterLab provide a set of tokens,
+which are listed here, along with short descriptions of when you
+might want to use them in your extensions.
+
+- ``@jupyterlab/application:ILayoutRestorer``: An interface to the application layout
+ restoration functionality. Use this to have your activities restored across
+ page loads.
+- ``@jupyterlab/application:IMimeDocumentTracker``: An instance tracker for documents
+ rendered using a mime renderer extension. Use this if you want to list and interact
+ with documents rendered by such extensions.
+- ``@jupyterlab/application:IRouter``: The URL router used by the application.
+ Use this to add custom URL-routing for your extension (e.g., to invoke
+ a command if the user navigates to a sub-path).
+- ``@jupyterlab/apputils:ICommandPalette``: An interface to the application command palette
+ in the left panel. Use this to add commands to the palette.
+- ``@jupyterlab/apputils:ISplashScreen``: An interface to the splash screen for the application.
+ Use this if you want to show the splash screen for your own purposes.
+- ``@jupyterlab/apputils:IThemeManager``: An interface to the theme manager for the application.
+ Most extensions will not need to use this, as they can register a
+ `theme extension <#themes>`__.
+- ``@jupyterlab/apputils:IWindowResolver``: An interface to a window resolver for the
+ application. JupyterLab workspaces are given a name, which are determined using
+ the window resolver. Require this if you want to use the name of the current workspace.
+- ``@jupyterlab/codeeditor:IEditorServices``: An interface to the text editor provider
+ for the application. Use this to create new text editors and host them in your
+ UI elements.
+- ``@jupyterlab/completer:ICompletionManager``: An interface to the completion manager
+ for the application. Use this to allow your extension to invoke a completer.
+- ``@jupyterlab/console:IConsoleTracker``: An instance tracker for code consoles.
+ Use this if you want to be able to iterate over and interact with code consoles
+ created by the application.
+- ``@jupyterlab/console:IContentFactory``: A factory object that creates new code
+ consoles. Use this if you want to create and host code consoles in your own UI elements.
+- ``@jupyterlab/coreutils:ISettingRegistry``: An interface to the JupyterLab settings system.
+ Use this if you want to store settings for your application.
+ See `extension settings <#extension-settings>`__ for more information.
+- ``@jupyterlab/coreutils:IStateDB``: An interface to the JupyterLab state database.
+ Use this if you want to store data that will persist across page loads.
+ See `state database <#state-database>`__ for more information.
+- ``@jupyterlab/docmanager:IDocumentManager``: An interface to the manager for all
+ documents used by the application. Use this if you want to open and close documents,
+ create and delete files, and otherwise interact with the file system.
+- ``@jupyterlab/filebrowser:IFileBrowserFactory``: A factory object that creates file browsers.
+ Use this if you want to create your own file browser (e.g., for a custom storage backend),
+ or to interact with other file browsers that have been created by extensions.
+- ``@jupyterlab/fileeditor:IEditorTracker``: An instance tracker for file editors.
+ Use this if you want to be able to iterate over and interact with file editors
+ created by the application.
+- ``@jupyterlab/imageviewer:IImageTracker``: An instance tracker for images.
+ Use this if you want to be able to iterate over and interact with images
+ viewed by the application.
+- ``@jupyterlab/inspector:IInspector``: An interface for adding variable inspectors to widgets.
+ Use this to add the ability to hook into the variable inspector to your extension.
+- ``@jupyterlab/launcher:ILauncher``: An interface to the application activity launcher.
+ Use this to add your extension activities to the launcher panel.
+- ``@jupyterlab/mainmenu:IMainMenu``: An interface to the main menu bar for the application.
+ Use this if you want to add your own menu items.
+- ``@jupyterlab/notebook:ICellTools``: An interface to the ``Cell Tools`` panel in the
+ application left area. Use this to add your own functionality to the panel.
+- ``@jupyterlab/notebook:IContentFactory``: A factory object that creates new notebooks.
+ Use this if you want to create and host notebooks in your own UI elements.
+- ``@jupyterlab/notebook:INotebookTracker``: An instance tracker for code consoles.
+ Use this if you want to be able to iterate over and interact with notebooks
+ created by the application.
+- ``@jupyterlab/rendermime:IRenderMimeRegistry``: An interface to the rendermime registry
+ for the application. Use this to create renderers for various mime-types in your extension.
+ Most extensions will not need to use this, as they can register a
+ `mime renderer extension <#mime-renderer-extensions>`__.
+- ``@jupyterlab/rendermime:ILatexTypesetter``: An interface to the LaTeX typesetter for the
+ application. Use this if you want to typeset math in your extension.
+- ``@jupyterlab/settingeditor:ISettingEditorTracker``: An instance tracker for setting editors.
+ Use this if you want to be able to iterate over and interact with setting editors
+ created by the application.
+- ``@jupyterlab/terminal:ITerminalTracker``: An instance tracker for terminals.
+ Use this if you want to be able to iterate over and interact with terminals
+ created by the application.
+- ``@jupyterlab/tooltip:ITooltipManager``: An interface to the tooltip manager for the application.
+ Use this to allow your extension to invoke a tooltip.
+
+Standard Extension Example
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For a concrete example of a standard extension, see :ref:`How to extend the Notebook plugin `.
+Notice that the mime renderer and themes extensions above use a limited,
+simplified interface to JupyterLab's extension system. Modifying the
+notebook plugin requires the full, general-purpose interface to the
+extension system.
+
+Storing Extension Data
+^^^^^^^^^^^^^^^^^^^^^^
+
+In addition to the file system that is accessed by using the
+``@jupyterlab/services`` package, JupyterLab offers two ways for
+extensions to store data: a client-side state database that is built on
+top of ``localStorage`` and a plugin settings system that provides for
+default setting values and user overrides.
+
+
+Extension Settings
+``````````````````
+
+An extension can specify user settings using a JSON Schema. The schema
+definition should be in a file that resides in the ``schemaDir``
+directory that is specified in the ``package.json`` file of the
+extension. The actual file name should use is the part that follows the
+package name of extension. So for example, the JupyterLab
+``apputils-extension`` package hosts several plugins:
+
+- ``'@jupyterlab/apputils-extension:menu'``
+- ``'@jupyterlab/apputils-extension:palette'``
+- ``'@jupyterlab/apputils-extension:settings'``
+- ``'@jupyterlab/apputils-extension:themes'``
+
+And in the ``package.json`` for ``@jupyterlab/apputils-extension``, the
+``schemaDir`` field is a directory called ``schema``. Since the
+``themes`` plugin requires a JSON schema, its schema file location is:
+``schema/themes.json``. The plugin's name is used to automatically
+associate it with its settings file, so this naming convention is
+important. Ensure that the schema files are included in the ``"files"``
+metadata in ``package.json``.
+
+See the
+`fileeditor-extension `__
+for another example of an extension that uses settings.
+
+Note: You can override default values of the extension settings by
+defining new default values in an ``overrides.json`` file in the
+application settings directory. So for example, if you would like
+to set the dark theme by default instead of the light one, an
+``overrides.json`` file containing the following lines needs to be
+added in the application settings directory (by default this is the
+``share/jupyter/lab/settings`` folder).
+
+.. code:: json
+
+ {
+ "@jupyterlab/apputils-extension:themes": {
+ "theme": "JupyterLab Dark"
+ }
+ }
+
+State Database
+``````````````
+
+The state database can be accessed by importing ``IStateDB`` from
+``@jupyterlab/coreutils`` and adding it to the list of ``requires`` for
+a plugin:
+
+.. code:: typescript
+
+ const id = 'foo-extension:IFoo';
+
+ const IFoo = new Token(id);
+
+ interface IFoo {}
+
+ class Foo implements IFoo {}
+
+ const plugin: JupyterFrontEndPlugin = {
+ id,
+ requires: [IStateDB],
+ provides: IFoo,
+ activate: (app: JupyterFrontEnd, state: IStateDB): IFoo => {
+ const foo = new Foo();
+ const key = `${id}:some-attribute`;
+
+ // Load the saved plugin state and apply it once the app
+ // has finished restoring its former layout.
+ Promise.all([state.fetch(key), app.restored])
+ .then(([saved]) => { /* Update `foo` with `saved`. */ });
+
+ // Fulfill the plugin contract by returning an `IFoo`.
+ return foo;
+ },
+ autoStart: true
+ };
+
+Context Menus
+^^^^^^^^^^^^^
+
+JupyterLab has an application-wide context menu available as
+``app.contextMenu``. See the Phosphor
+`docs `__
+for the item creation options. If you wish to preempt the
+application context menu, you can use a 'contextmenu' event listener and
+call ``event.stopPropagation`` to prevent the application context menu
+handler from being called (it is listening in the bubble phase on the
+``document``). At this point you could show your own Phosphor
+`contextMenu `__,
+or simply stop propagation and let the system context menu be shown.
+This would look something like the following in a ``Widget`` subclass:
+
+.. code:: javascript
+
+ // In `onAfterAttach()`
+ this.node.addEventListener('contextmenu', this);
+
+ // In `handleEvent()`
+ case 'contextmenu':
+ event.stopPropagation();
+
+.. |dependencies| image:: dependency-graph.svg
+
+
+
+.. _ext-author-companion-packages:
+
+Companion Packages
+^^^^^^^^^^^^^^^^^^
+
+If your extensions depends on the presence of one or more packages in the
+kernel, or on a notebook server extension, you can add metadata to indicate
+this to the extension manager by adding metadata to your package.json file.
+The full options available are::
+
+ "jupyterlab": {
+ "discovery": {
+ "kernel": [
+ {
+ "kernel_spec": {
+ "language": "",
+ "display_name": "" // optional
+ },
+ "base": {
+ "name": ""
+ },
+ "overrides": { // optional
+ "": {
+ "name": ""
+ }
+ },
+ "managers": [ // list of package managers that have your kernel package
+ "pip",
+ "conda"
+ ]
+ }
+ ],
+ "server": {
+ "base": {
+ "name": ""
+ },
+ "overrides": { // optional
+ "": {
+ "name": ""
+ }
+ },
+ "managers": [ // list of package managers that have your server extension package
+ "pip",
+ "conda"
+ ]
+ }
+ }
+ }
+
+
+A typical setup for e.g. a jupyter-widget based package will then be::
+
+ "keywords": [
+ "jupyterlab-extension",
+ "jupyter",
+ "widgets",
+ "jupyterlab"
+ ],
+ "jupyterlab": {
+ "extension": true,
+ "discovery": {
+ "kernel": [
+ {
+ "kernel_spec": {
+ "language": "^python",
+ },
+ "base": {
+ "name": "myipywidgetspackage"
+ },
+ "managers": [
+ "pip",
+ "conda"
+ ]
+ }
+ ]
+ }
+ }
+
+
+Currently supported package managers are:
+
+- ``pip``
+- ``conda``
diff --git a/docs/source/developer/filebrowser_example.png b/docs/source/developer/filebrowser_example.png
new file mode 100644
index 00000000..4f87a48f
Binary files /dev/null and b/docs/source/developer/filebrowser_example.png differ
diff --git a/docs/source/developer/filebrowser_source.png b/docs/source/developer/filebrowser_source.png
new file mode 100644
index 00000000..b4f77352
Binary files /dev/null and b/docs/source/developer/filebrowser_source.png differ
diff --git a/docs/source/developer/notebook.rst b/docs/source/developer/notebook.rst
new file mode 100644
index 00000000..6cc8afa7
--- /dev/null
+++ b/docs/source/developer/notebook.rst
@@ -0,0 +1,284 @@
+Notebook
+--------
+
+Background
+~~~~~~~~~~
+
+.. _architecture-walkthrough:
+
+A JupyterLab architecture walkthrough from June 16, 2016, provides an overview of the notebook architecture.
+
+.. raw:: html
+
+ `__
+constructs a new
+`NotebookPanel `__
+from a model and populates the toolbar with default widgets.
+
+Structure of the Notebook plugin
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Notebook plugin provides a model and widgets for dealing with
+notebook files.
+
+Model
+^^^^^
+
+The
+`NotebookModel `__
+contains an observable list of cells.
+
+A `cell
+model `__
+can be:
+
+- a code cell
+- a markdown cell
+- raw cell
+
+A code cell contains a list of **output models**. The list of cells and
+the list of outputs can be observed for changes.
+
+Cell operations
+'''''''''''''''
+
+The NotebookModel cell list supports single-step operations such as
+moving, adding, or deleting cells. Compound cell list operations, such
+as undo/redo, are also supported by the NotebookModel. Right now,
+undo/redo is only supported on cells and is not supported on notebook
+attributes, such as notebook metadata. Currently, undo/redo for
+individual cell input content is supported by the CodeMirror editor's
+undo feature. (Note: CodeMirror editor's undo does not cover cell
+metadata changes.)
+
+Metadata
+''''''''''''''''''''
+
+The notebook model and the cell model (i.e. notebook cells) support
+getting and setting metadata through an
+`IObservableJSON `__
+object. You can use this to get and set notebook/cell metadata,
+as well as subscribe to changes to it.
+
+Notebook widget
+^^^^^^^^^^^^^^^
+
+After the NotebookModel is created, the NotebookWidgetFactory constructs
+a new NotebookPanel from the model. The NotebookPanel widget is added to
+the DockPanel. The **NotebookPanel** contains:
+
+- a
+ `Toolbar `__
+- a `Notebook
+ widget `__.
+
+The NotebookPanel also adds completion logic.
+
+The **NotebookToolbar** maintains a list of widgets to add to the
+toolbar. The **Notebook widget** contains the rendering of the notebook
+and handles most of the interaction logic with the notebook itself (such
+as keeping track of interactions such as selected and active cells and
+also the current edit/command mode).
+
+The NotebookModel cell list provides ways to do fine-grained changes to
+the cell list.
+
+Higher level actions using NotebookActions
+''''''''''''''''''''''''''''''''''''''''''
+
+Higher-level actions are contained in the
+`NotebookActions `__
+namespace, which has functions, when given a notebook widget, to run a
+cell and select the next cell, merge or split cells at the cursor,
+delete selected cells, etc.
+
+Widget hierarchy
+''''''''''''''''
+
+A Notebook widget contains a list of `cell
+widgets `__,
+corresponding to the cell models in its cell list.
+
+- Each cell widget contains an
+ `InputArea `__,
+
+ - which contains n
+ `CodeEditorWrapper `__,
+
+ - which contains a JavaScript CodeMirror instance.
+
+A
+`CodeCell `__
+also contains an
+`OutputArea `__.
+An OutputArea is responsible for rendering the outputs in the
+`OutputAreaModel `__
+list. An OutputArea uses a notebook-specific
+`RenderMimeRegistry `__
+object to render ``display_data`` output messages.
+
+Rendering output messages
+'''''''''''''''''''''''''
+
+A **Rendermime plugin** provides a pluggable system for rendering output
+messages. Default renderers are provided for markdown, html, images,
+text, etc. Extensions can register renderers to be used across the
+entire application by registering a handler and mimetype in the
+rendermime registry. When a notebook is created, it copies the global
+Rendermime singleton so that notebook-specific renderers can be added.
+The ipywidgets widget manager is an example of an extension that adds a
+notebook-specific renderer, since rendering a widget depends on
+notebook-specific widget state.
+
+.. _extend-notebook-plugin:
+
+How to extend the Notebook plugin
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We'll walk through two notebook extensions:
+
+- adding a button to the toolbar
+- adding an ipywidgets extension
+
+Adding a button to the toolbar
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Start from the cookie cutter extension template.
+
+::
+
+ pip install cookiecutter
+ cookiecutter https://github.com/jupyterlab/extension-cookiecutter-ts
+ cd my-cookie-cutter-name
+
+Install the dependencies. Note that extensions are built against the
+released npm packages, not the development versions.
+
+::
+
+ npm install --save @jupyterlab/notebook @jupyterlab/application @jupyterlab/apputils @jupyterlab/docregistry @phosphor/disposable
+
+Copy the following to ``src/index.ts``:
+
+.. code:: typescript
+
+ import {
+ IDisposable, DisposableDelegate
+ } from '@phosphor/disposable';
+
+ import {
+ JupyterFrontEnd, JupyterFrontEndPlugin
+ } from '@jupyterlab/application';
+
+ import {
+ ToolbarButton
+ } from '@jupyterlab/apputils';
+
+ import {
+ DocumentRegistry
+ } from '@jupyterlab/docregistry';
+
+ import {
+ NotebookActions, NotebookPanel, INotebookModel
+ } from '@jupyterlab/notebook';
+
+
+ /**
+ * The plugin registration information.
+ */
+ const plugin: JupyterFrontEndPlugin = {
+ activate,
+ id: 'my-extension-name:buttonPlugin',
+ autoStart: true
+ };
+
+
+ /**
+ * A notebook widget extension that adds a button to the toolbar.
+ */
+ export
+ class ButtonExtension implements DocumentRegistry.IWidgetExtension {
+ /**
+ * Create a new extension object.
+ */
+ createNew(panel: NotebookPanel, context: DocumentRegistry.IContext): IDisposable {
+ let callback = () => {
+ NotebookActions.runAll(panel.content, context.session);
+ };
+ let button = new ToolbarButton({
+ className: 'myButton',
+ iconClassName: 'fa fa-fast-forward',
+ onClick: callback,
+ tooltip: 'Run All'
+ });
+
+ panel.toolbar.insertItem(0, 'runAll', button);
+ return new DisposableDelegate(() => {
+ button.dispose();
+ });
+ }
+ }
+
+ /**
+ * Activate the extension.
+ */
+ function activate(app: JupyterFrontEnd) {
+ app.docRegistry.addWidgetExtension('Notebook', new ButtonExtension());
+ };
+
+
+ /**
+ * Export the plugin as default.
+ */
+ export default plugin;
+
+Run the following commands:
+
+::
+
+ npm install
+ npm run build
+ jupyter labextension install .
+ jupyter lab
+
+Open a notebook and observe the new "Run All" button.
+
+The *ipywidgets* third party extension
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This discussion will be a bit confusing since we've been using the term
+*widget* to refer to *phosphor widgets*. In the discussion below,
+*ipython widgets* will be referred to as *ipywidgets*. There is no
+intrinsic relation between *phosphor widgets* and *ipython widgets*.
+
+The *ipywidgets* extension registers a factory for a notebook *widget*
+extension using the `Document
+Registry `__.
+The ``createNew()`` function is called with a NotebookPanel and
+`DocumentContext `__.
+The plugin then creates a ipywidget manager (which uses the context to
+interact the kernel and kernel's comm manager). The plugin then
+registers an ipywidget renderer with the notebook instance's rendermime
+(which is specific to that particular notebook).
+
+When an ipywidget model is created in the kernel, a comm message is sent
+to the browser and handled by the ipywidget manager to create a
+browser-side ipywidget model. When the model is displayed in the kernel,
+a ``display_data`` output is sent to the browser with the ipywidget
+model id. The renderer registered in that notebook's rendermime is asked
+to render the output. The renderer asks the ipywidget manager instance
+to render the corresponding model, which returns a JavaScript promise.
+The renderer creates a container *phosphor widget* which it hands back
+synchronously to the OutputArea, and then fills the container with the
+rendered *ipywidget* when the promise resolves.
+
+Note: The ipywidgets third party extension has not yet been released.
diff --git a/docs/source/developer/patterns.rst b/docs/source/developer/patterns.rst
new file mode 100644
index 00000000..88a3d784
--- /dev/null
+++ b/docs/source/developer/patterns.rst
@@ -0,0 +1,173 @@
+Design Patterns
+---------------
+
+There are several design patterns that are repeated throughout the
+repository. This guide is meant to supplement the `TypeScript Style
+Guide `__.
+
+TypeScript
+~~~~~~~~~~
+
+TypeScript is used in all of the source code. TypeScript is used because
+it provides features from the most recent EMCAScript 6 standards, while
+providing type safety. The TypeScript compiler eliminates an entire
+class of bugs, while making it much easier to refactor code.
+
+Initialization Options
+~~~~~~~~~~~~~~~~~~~~~~
+
+Objects will typically have an ``IOptions`` interface for initializing
+the widget. The use of this interface enables options to be later added
+while preserving backward compatibility.
+
+ContentFactory Option
+~~~~~~~~~~~~~~~~~~~~~
+
+| A common option for a widget is a ``IContentFactory``, which is used
+ to customize the child content in the widget.
+| If not given, a ``defaultRenderer`` instance is used if no arguments
+ are required. In this way, widgets can be customized without
+ subclassing them, and widgets can support customization of their
+ nested content.
+
+Static Namespace
+~~~~~~~~~~~~~~~~
+
+An object class will typically have an exported static namespace sharing
+the same name as the object. The namespace is used to declutter the
+class definition.
+
+Private Module Namespace
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The "Private" module namespace is used to group variables and functions
+that are not intended to be exported and may have otherwise existed as
+module-level variables and functions. The use of the namespace also
+makes it clear when a variable access is to an imported name or from the
+module itself. Finally, the namespace enables the entire section to be
+collapsed in an editor if desired.
+
+Disposables
+~~~~~~~~~~~
+
+| JavaScript does not support "destructors", so the ``IDisposable``
+ pattern is used to ensure resources are freed and can be claimed by
+ the Garbage Collector when no longer needed. It should always be safe
+ to ``dispose()`` of an object more than once. Typically the object
+ that creates another object is responsible for calling the dispose
+ method of that object unless explicitly stated otherwise.
+| To mirror the pattern of construction, ``super.dispose()`` should be
+ called last in the ``dispose()`` method if there is a parent class.
+ Make sure any signal connections are cleared in either the local or
+ parent ``dispose()`` method. Use a sentinel value to guard against
+ reentry, typically by checking if an internal value is null, and then
+ immediately setting the value to null. A subclass should never
+ override the ``isDisposed`` getter, because it short-circuits the
+ parent class getter. The object should not be considered disposed
+ until the base class ``dispose()`` method is called.
+
+Messages
+~~~~~~~~
+
+Messages are intended for many-to-one communication where outside
+objects influence another object. Messages can be conflated and
+processed as a single message. They can be posted and handled on the
+next animation frame.
+
+Signals
+~~~~~~~
+
+Signals are intended for one-to-many communication where outside objects
+react to changes on another object. Signals are always emitted with the
+sender as the first argument, and contain a single second argument with
+the payload. Signals should generally not be used to trigger the
+"default" behavior for an action, but to enable others to trigger
+additional behavior. If a "default" behavior is intended to be provided
+by another object, then a callback should be provided by that object.
+Wherever possible as signal connection should be made with the pattern
+``.connect(this._onFoo, this)``. Providing the ``this`` context enables
+the connection to be properly cleared by ``clearSignalData(this)``.
+Using a private method avoids allocating a closure for each connection.
+
+Models
+~~~~~~
+
+Some of the more advanced widgets have a model associated with them. The
+common pattern used is that the model is settable and must be set
+outside of the constructor. This means that any consumer of the widget
+must account for a model that may be ``null``, and may change at any
+time. The widget should emit a ``modelChanged`` signal to enable
+consumers to handle a change in model. The reason to enable a model to
+swap is that the same widget could be used to display different model
+content while preserving the widget's location in the application. The
+reason the model cannot be provided in the constructor is the
+initialization required for a model may have to call methods that are
+subclassed. The subclassed methods would be called before the subclass
+constructor has finished evaluating, resulting in undefined state.
+
+.. _getters-vs-methods:
+
+Getters vs. Methods
+~~~~~~~~~~~~~~~~~~~
+
+Prefer a method when the return value must be computed each time. Prefer
+a getter for simple attribute lookup. A getter should yield the same
+value every time.
+
+Data Structures
+~~~~~~~~~~~~~~~
+
+For public API, we have three options: JavaScript ``Array``,
+``IIterator``, and ``ReadonlyArray`` (an interface defined by
+TypeScript).
+
+Prefer an ``Array`` for:
+
+- A value that is meant to be mutable.
+
+Prefer a ``ReadonlyArray``
+
+- A return value is the result of a newly allocated array, to avoid the
+ extra allocation of an iterator.
+- A signal payload - since it will be consumed by multiple listeners.
+- The values may need to be accessed randomly.
+- A public attribute that is inherently static.
+
+Prefer an ``IIterator`` for:
+
+- A return value where the value is based on an internal data structure
+ but the value should not need to be accessed randomly.
+- A set of return values that can be computed lazily.
+
+DOM Events
+~~~~~~~~~~
+
+If an object instance should respond to DOM events, create a
+``handleEvent`` method for the class and register the object instance as
+the event handler. The ``handleEvent`` method should switch on the event
+type and could call private methods to carry out the actions. Often a
+widget class will add itself as an event listener to its own node in the
+``onAfterAttach`` method with something like
+``this.node.addEventListener('mousedown', this)`` and unregister itself
+in the ``onBeforeDetach`` method with
+``this.node.removeEventListener('mousedown', this)`` Dispatching events
+from the ``handleEvent`` method makes it easier to trace, log, and debug
+event handling. For more information about the ``handleEvent`` method,
+see the
+`EventListener `__
+API.
+
+Promises
+~~~~~~~~
+
+We use Promises for asynchronous function calls, and a shim for browsers
+that do not support them. When handling a resolved or rejected Promise,
+make sure to check for the current state (typically by checking an
+``.isDisposed`` property) before proceeding.
+
+Command Names
+~~~~~~~~~~~~~
+
+Commands used in the application command registry should be formatted as
+follows: ``package-name:verb-noun``. They are typically grouped into a
+``CommandIDs`` namespace in the extension that is not exported.
diff --git a/docs/source/developer/repo.rst b/docs/source/developer/repo.rst
new file mode 100644
index 00000000..142307de
--- /dev/null
+++ b/docs/source/developer/repo.rst
@@ -0,0 +1,74 @@
+.. _developer-guide:
+
+The JupyterLab Developer Guide is for developing JupyterLab extensions or developing JupyterLab itself.
+
+General Codebase Orientation
+----------------------------
+
+The ``jupyterlab/jupyterlab`` repository contains two packages:
+
+- an npm package indicated by a ``package.json`` file in the repo's
+ root directory
+- a Python package indicated by a ``setup.py`` file in the repo's root
+ directory
+
+The npm package and the Python package are both named ``jupyterlab``.
+
+See the `Contributing
+Guidelines `__
+for developer installation instructions.
+
+Directories
+~~~~~~~~~~~
+
+NPM package: ``src/``, ``lib/``, ``typings/``, ``buildutils/``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+- ``src/``: the source typescript files.
+
+ - ``jlpm run build`` builds the source files into javascript files
+ in ``lib/``.
+ - ``jlpm run clean`` deletes the ``lib/`` directory.
+
+- ``typings/``: type definitions for external libraries that typescript
+ needs.
+- ``buildutils/``: Utilities for managing the repo
+
+Examples: ``examples/``
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``examples/`` directory contains stand-alone examples of components,
+such as a simple notebook on a page, a console, terminal, and a
+filebrowser. The ``lab`` example illustrates a simplified combination of
+components used in JupyterLab. This example shows multiple stand-alone
+components combined to create a more complex application.
+
+Testing: ``test/``
+^^^^^^^^^^^^^^^^^^
+
+The tests are stored and run in the ``test/`` directory. The source
+files are in ``test/src/``.
+
+Notebook extension: ``jupyterlab/``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``jupyterlab/`` directory contains the Jupyter server extension.
+
+The server extension includes a private npm package in order to build
+the **webpack bundle** which the extension serves. The private npm
+package depends on the ``jupyterlab`` npm package found in the repo's
+root directory.
+
+Git hooks: ``git-hooks/``
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``git-hooks/`` directory stores some convenience git hooks that
+automatically rebuild the npm package and server extension every time
+you check out or merge (via pull request or direct push to master) in
+the git repo.
+
+Documentation: ``docs/``
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+After building the docs (``jlpm run docs``), ``docs/index.html`` is the
+entry point to the documentation.
diff --git a/docs/source/developer/terminology.rst b/docs/source/developer/terminology.rst
new file mode 100644
index 00000000..d40ecfc8
--- /dev/null
+++ b/docs/source/developer/terminology.rst
@@ -0,0 +1,20 @@
+Terminology
+-----------
+
+Learning to use a new technology and its architecture can be complicated
+by the jargon used to describe components. We provide this terminology
+guide to help smooth the learning the components.
+
+Terms
+~~~~~
+
+- Application - The main application object that hold the application
+ shell, command registry, and keymap registry. It is provided to all
+ plugins in their activate method.
+- Plugin - An object that provides a service and or extends the
+ application.
+- Phosphor - The JavaScript library that provides the foundation of
+ JupyterLab, enabling desktop-like applications in the browser.
+- Standalone example - An example in the ``examples/`` directory that
+ demonstrates the usage of one or more components of JupyterLab.
+- TypeScript - A statically typed language that compiles to JavaScript.
diff --git a/docs/source/developer/virtualdom.rst b/docs/source/developer/virtualdom.rst
new file mode 100644
index 00000000..f3167ab5
--- /dev/null
+++ b/docs/source/developer/virtualdom.rst
@@ -0,0 +1,25 @@
+Virtual DOM and React
+---------------------
+
+JupyterLab is based on `PhosphorJS `__
+of JupyterLab.
diff --git a/docs/source/developer/xkcd_extension_tutorial.rst b/docs/source/developer/xkcd_extension_tutorial.rst
new file mode 100644
index 00000000..3cdbbb62
--- /dev/null
+++ b/docs/source/developer/xkcd_extension_tutorial.rst
@@ -0,0 +1,866 @@
+.. _xkcd_extension_tutorial:
+
+Let's Make an xkcd JupyterLab Extension
+---------------------------------------
+
+.. warning::
+
+ The extension developer API is not stable and will evolve in JupyterLab
+ releases in the near future.
+
+JupyterLab extensions add features to the user experience. This page
+describes how to create one type of extension, an *application plugin*,
+that:
+
+- Adds a "Random `xkcd `__ comic" command to the
+ *command palette* sidebar
+- Fetches the comic image and metadata when activated
+- Shows the image and metadata in a tab panel
+
+By working through this tutorial, you'll learn:
+
+- How to setup an extension development environment from scratch on a
+ Linux or OSX machine.
+
+ - Windows users: You'll need to modify the commands slightly.
+
+- How to start an extension project from
+ `jupyterlab/extension-cookiecutter-ts `__
+- How to iteratively code, build, and load your extension in JupyterLab
+- How to version control your work with git
+- How to release your extension for others to enjoy
+
+|Completed xkcd extension screenshot|
+
+Sound like fun? Excellent. Here we go!
+
+Setup a development environment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Install conda using miniconda
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Start by installing miniconda, following
+`Conda's installation documentation `__.
+
+.. _install-nodejs-jupyterlab-etc-in-a-conda-environment:
+
+Install NodeJS, JupyterLab, etc. in a conda environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Next create a conda environment that includes:
+
+1. the latest release of JupyterLab
+2. `cookiecutter `__, the tool
+ you'll use to bootstrap your extension project structure
+3. `NodeJS `__, the JavaScript runtime you'll use to
+ compile the web assets (e.g., TypeScript, CSS) for your extension
+4. `git `__, a version control system you'll use to
+ take snapshots of your work as you progress through this tutorial
+
+It's best practice to leave the root conda environment, the one created
+by the miniconda installer, untouched and install your project specific
+dependencies in a named conda environment. Run this command to create a
+new environment named ``jupyterlab-ext``.
+
+.. code:: bash
+
+ conda create -n jupyterlab-ext -c conda-forge --override-channels nodejs jupyterlab cookiecutter git
+
+Now activate the new environment so that all further commands you run
+work out of that environment.
+
+.. code:: bash
+
+ conda activate jupyterlab-ext
+
+Note: You'll need to run the command above in each new terminal you open
+before you can work with the tools you installed in the
+``jupyterlab-ext`` environment.
+
+Create a repository
+~~~~~~~~~~~~~~~~~~~
+
+Create a new repository for your extension. For example, on
+`GitHub `__
+- `Opening the Web Console in
+ Firefox `__
+
+After you reload the page with the console open, you should see a message that says
+``JupyterLab extension jupyterlab_xkcd is activated!`` in the console.
+If you do, congrats, you're ready to start modifying the the extension!
+If not, go back, make sure you didn't miss a step, and `reach
+out `__ if you're stuck.
+
+Note: Leave the terminal running the ``jupyter lab --watch`` command
+open.
+
+Commit what you have to git
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Run the following commands in your ``jupyterlab_xkcd`` folder to
+initialize it as a git repository and commit the current code.
+
+.. code:: bash
+
+ git init
+ git add .
+ git commit -m 'Seed xkcd project from cookiecutter'
+
+Note: This step is not technically necessary, but it is good practice to
+track changes in version control system in case you need to rollback to
+an earlier version or want to collaborate with others. For example, you
+can compare your work throughout this tutorial with the commits in a
+reference version of ``jupyterlab_xkcd`` on GitHub at
+https://github.com/jupyterlab/jupyterlab_xkcd.
+
+Add an xkcd widget
+~~~~~~~~~~~~~~~~~~
+
+Show an empty panel
+^^^^^^^^^^^^^^^^^^^
+
+The *command palette* is the primary view of all commands available to
+you in JupyterLab. For your first addition, you're going to add a
+*Random xkcd comic* command to the palette and get it to show an *xkcd*
+tab panel when invoked.
+
+Fire up your favorite text editor and open the ``src/index.ts`` file in
+your extension project. Add the following import at the top of the file
+to get a reference to the command palette interface.
+
+.. code:: typescript
+
+ import {
+ ICommandPalette
+ } from '@jupyterlab/apputils';
+
+You will also need to install this dependency. Run the following command in the
+repository root folder install the dependency and save it to your
+`package.json`:
+
+.. code:: bash
+
+ jlpm add @jupyterlab/apputils
+
+Locate the ``extension`` object of type ``JupyterFrontEndPlugin``. Change the
+definition so that it reads like so:
+
+.. code:: typescript
+
+ /**
+ * Initialization data for the jupyterlab_xkcd extension.
+ */
+ const extension: JupyterFrontEndPlugin = {
+ id: 'jupyterlab_xkcd',
+ autoStart: true,
+ requires: [ICommandPalette],
+ activate: (app: JupyterFrontEnd, palette: ICommandPalette) => {
+ console.log('JupyterLab extension jupyterlab_xkcd is activated!');
+ console.log('ICommandPalette:', palette);
+ }
+ };
+
+The ``requires`` attribute states that your plugin needs an object that
+implements the ``ICommandPalette`` interface when it starts. JupyterLab
+will pass an instance of ``ICommandPalette`` as the second parameter of
+``activate`` in order to satisfy this requirement. Defining
+``palette: ICommandPalette`` makes this instance available to your code
+in that function. The second ``console.log`` line exists only so that
+you can immediately check that your changes work.
+
+Run the following to rebuild your extension.
+
+.. code:: bash
+
+ jlpm run build
+
+JupyterLab will rebuild after the extension does. You can
+see it's progress in the ``jupyter lab --watch`` window. After that
+finishes, return to the browser tab that opened when you
+started JupyterLab. Refresh it and look in the console. You should see
+the same activation message as before, plus the new message about the
+ICommandPalette instance you just added. If you don't, check the output
+of the build command for errors and correct your code.
+
+::
+
+ JupyterLab extension jupyterlab_xkcd is activated!
+ ICommandPalette: Palette {_palette: CommandPalette}
+
+Note that we had to run ``jlpm run build`` in order for the bundle to
+update, because it is using the compiled JavaScript files in ``/lib``.
+If you wish to avoid running ``jlpm run build`` after each change, you
+can open a third terminal, and run the ``jlpm run watch`` command from
+your extension directory, which will automatically compile the
+TypeScript files as they change.
+
+Now return to your editor. Add the following additional import to the
+top of the file.
+
+.. code:: typescript
+
+ import {
+ Widget
+ } from '@phosphor/widgets';
+
+Install this dependency as well:
+
+.. code:: bash
+
+ jlpm add @phosphor/widgets
+
+
+Then modify the ``activate`` function again so that it has the following
+code:
+
+.. code-block:: typescript
+
+ activate: (app: JupyterFrontEnd, palette: ICommandPalette) => {
+ console.log('JupyterLab extension jupyterlab_xkcd is activated!');
+
+ // Create a single widget
+ let widget: Widget = new Widget();
+ widget.id = 'xkcd-jupyterlab';
+ widget.title.label = 'xkcd.com';
+ widget.title.closable = true;
+
+ // Add an application command
+ const command: string = 'xkcd:open';
+ app.commands.addCommand(command, {
+ label: 'Random xkcd comic',
+ execute: () => {
+ if (!widget.isAttached) {
+ // Attach the widget to the main work area if it's not there
+ app.shell.add(widget, 'main');
+ }
+ // Activate the widget
+ app.shell.activateById(widget.id);
+ }
+ });
+
+ // Add the command to the palette.
+ palette.addItem({command, category: 'Tutorial'});
+ }
+
+The first new block of code creates a ``Widget`` instance, assigns it a
+unique ID, gives it a label that will appear as its tab title, and makes
+the tab closable by the user. The second block of code add a new command
+labeled *Random xkcd comic* to JupyterLab. When the command executes,
+it attaches the widget to the main display area if it is not already
+present and then makes it the active tab. The last new line of code adds
+the command to the command palette in a section called *Tutorial*.
+
+Build your extension again using ``jlpm run build`` (unless you are using
+``jlpm run watch`` already) and refresh the browser tab. Open the command
+palette on the left side by clicking on *Commands* and type *xkcd* in
+the search box. Your *Random xkcd comic*
+command should appear. Click it or select it with the keyboard and press
+*Enter*. You should see a new, blank panel appear with the tab title
+*xkcd.com*. Click the *x* on the tab to close it and activate the
+command again. The tab should reappear. Finally, click one of the
+launcher tabs so that the *xkcd.com* panel is still open but no longer
+active. Now run the *Random xkcd comic* command one more time. The
+single *xkcd.com* tab should come to the foreground.
+
+|Empty xkcd extension panel|
+
+If your widget is not behaving, compare your code with the reference
+project state at the `01-show-a-panel
+tag `__.
+Once you've got everything working properly, git commit your changes and
+carry on.
+
+.. code-block:: bash
+
+ git add .
+ git commit -m 'Show xkcd command on panel'
+
+Show a comic in the panel
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You've got an empty panel. It's time to add a comic to it. Go back to
+your code editor. Add the following code below the lines that create a
+``Widget`` instance and above the lines that define the command.
+
+.. code-block:: typescript
+
+ // Add an image element to the panel
+ let img = document.createElement('img');
+ widget.node.appendChild(img);
+
+ // Fetch info about a random comic
+ fetch('https:////egszlpbmle.execute-api.us-east-1.amazonaws.com/prod').then(response => {
+ return response.json();
+ }).then(data => {
+ img.src = data.img;
+ img.alt = data.title;
+ img.title = data.alt;
+ });
+
+The first two lines create a new HTML ``![]()
`` element and add it to
+the widget DOM node. The next lines make a request using the HTML
+`fetch `__
+API that returns information about a random xkcd comic, and set the
+image source, alternate text, and title attributes based on the
+response.
+
+Rebuild your extension if necessary (``jlpm run build``), refresh your
+browser tab, and run the *Random xkcd comic* command again. You should
+now see a comic in the xkcd.com panel when it opens.
+
+|Single xkcd extension panel|
+
+Note that the comic is not centered in the panel nor does the panel
+scroll if the comic is larger than the panel area. Also note that the
+comic does not update no matter how many times you close and reopen the
+panel. You'll address both of these problems in the upcoming sections.
+
+If you don't see a comic at all, compare your code with the
+`02-show-a-comic
+tag `__
+in the reference project. When it's working, make another git commit.
+
+.. code:: bash
+
+ git add .
+ git commit -m 'Show a comic in the panel'
+
+Improve the widget behavior
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Center the comic and add attribution
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Open ``style/index.css`` in our extension project directory for editing.
+Add the following lines to it.
+
+.. code-block:: css
+
+ .jp-xkcdWidget {
+ display: flex;
+ flex-direction: column;
+ overflow: auto;
+ }
+
+ .jp-xkcdCartoon {
+ margin: auto;
+ }
+
+ .jp-xkcdAttribution {
+ margin: 20px auto;
+ }
+
+The first rule stacks content vertically within the widget panel and
+lets the panel scroll when the content overflows. The other rules center
+the cartoon and attribution badge horizontally and space them out
+vertically.
+
+Return to the ``index.ts`` file. Note that there is already an import of
+the CSS file in the ``index.ts`` file. Modify the the ``activate``
+function to apply the CSS classes and add the attribution badge markup.
+The beginning of the function should read like the following:
+
+.. code-block:: typescript
+ :emphasize-lines: 9,13,16-23
+
+ activate: (app: JupyterFrontEnd, palette: ICommandPalette) => {
+ console.log('JupyterLab extension jupyterlab_xkcd is activated!');
+
+ // Create a single widget
+ let widget: Widget = new Widget();
+ widget.id = 'xkcd-jupyterlab';
+ widget.title.label = 'xkcd.com';
+ widget.title.closable = true;
+ widget.addClass('jp-xkcdWidget'); // new line
+
+ // Add an image element to the panel
+ let img = document.createElement('img');
+ img.className = 'jp-xkcdCartoon'; // new line
+ widget.node.appendChild(img);
+
+ // New: add an attribution badge
+ img.insertAdjacentHTML('afterend',
+ ``__.
+When everything is working as expected, make another commit.
+
+.. code:: bash
+
+ git add .
+ git commit -m 'Add styling, attribution'
+
+Show a new comic on demand
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``activate`` function has grown quite long, and there's still more
+functionality to add. You should refactor the code into two separate
+parts:
+
+1. An ``XkcdWidget`` that encapsulates the xkcd panel elements,
+ configuration, and soon-to-be-added update behavior
+2. An ``activate`` function that adds the widget instance to the UI and
+ decide when the comic should refresh
+
+Start by refactoring the widget code into the new ``XkcdWidget`` class.
+Add the following additional import to the top of the file.
+
+.. code-block:: typescript
+
+ import {
+ Message
+ } from '@phosphor/messaging';
+
+Install this dependency:
+
+.. code:: bash
+
+ jlpm add @phosphor/messaging
+
+
+Then add the class just below the import statements in the ``index.ts``
+file.
+
+.. code-block:: typescript
+
+ /**
+ * An xckd comic viewer.
+ */
+ class XkcdWidget extends Widget {
+ /**
+ * Construct a new xkcd widget.
+ */
+ constructor() {
+ super();
+
+ this.id = 'xkcd-jupyterlab';
+ this.title.label = 'xkcd.com';
+ this.title.closable = true;
+ this.addClass('jp-xkcdWidget');
+
+ this.img = document.createElement('img');
+ this.img.className = 'jp-xkcdCartoon';
+ this.node.appendChild(this.img);
+
+ this.img.insertAdjacentHTML('afterend',
+ ` = {
+ id: 'jupyterlab_xkcd',
+ autoStart: true,
+ requires: [ICommandPalette],
+ activate: activate
+ };
+
+Make sure you retain the ``export default extension;`` line in the file.
+Now build the extension again and refresh the JupyterLab browser tab.
+Run the *Random xkcd comic* command more than once without closing the
+panel. The comic should update each time you execute the command. Close
+the panel, run the command, and it should both reappear and show a new
+comic.
+
+If anything is amiss, compare your code with the
+`04-refactor-and-refresh
+tag `__
+to debug. Once it's working properly, commit it.
+
+.. code:: bash
+
+ git add .
+ git commit -m 'Refactor, refresh comic'
+
+Restore panel state when the browser refreshes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You may notice that every time you refresh your browser tab, the xkcd
+panel disappears, even if it was open before you refreshed. Other open
+panels, like notebooks, terminals, and text editors, all reappear and
+return to where you left them in the panel layout. You can make your
+extension behave this way too.
+
+Update the imports at the top of your ``index.ts`` file so that the
+entire list of import statements looks like the following:
+
+.. code-block:: typescript
+ :emphasize-lines: 2,6,9-11
+
+ import {
+ JupyterFrontEnd, JupyterFrontEndPlugin, ILayoutRestorer // new
+ } from '@jupyterlab/application';
+
+ import {
+ ICommandPalette, InstanceTracker // new
+ } from '@jupyterlab/apputils';
+
+ import {
+ JSONExt // new
+ } from '@phosphor/coreutils';
+
+ import {
+ Message
+ } from '@phosphor/messaging';
+
+ import {
+ Widget
+ } from '@phosphor/widgets';
+
+ import '../style/index.css';
+
+
+Install this dependency:
+
+.. code:: bash
+
+ jlpm add @phosphor/coreutils
+
+Then, add the ``ILayoutRestorer`` interface to the ``JupyterFrontEndPlugin``
+definition. This addition passes the global ``LayoutRestorer`` to the
+third parameter of the ``activate``.
+
+.. code:: typescript
+
+ const extension: JupyterFrontEndPlugin = {
+ id: 'jupyterlab_xkcd',
+ autoStart: true,
+ requires: [ICommandPalette, ILayoutRestorer],
+ activate: activate
+ };
+
+Finally, rewrite the ``activate`` function so that it:
+
+1. Declares a widget variable, but does not create an instance
+ immediately
+2. Constructs an ``InstanceTracker`` and tells the ``ILayoutRestorer``
+ to use it to save/restore panel state
+3. Creates, tracks, shows, and refreshes the widget panel appropriately
+
+.. code-block:: typescript
+
+ function activate(app: JupyterFrontEnd, palette: ICommandPalette, restorer: ILayoutRestorer) {
+ console.log('JupyterLab extension jupyterlab_xkcd is activated!');
+
+ // Declare a widget variable
+ let widget: XkcdWidget;
+
+ // Add an application command
+ const command: string = 'xkcd:open';
+ app.commands.addCommand(command, {
+ label: 'Random xkcd comic',
+ execute: () => {
+ if (!widget) {
+ // Create a new widget if one does not exist
+ widget = new XkcdWidget();
+ widget.update();
+ }
+ if (!tracker.has(widget)) {
+ // Track the state of the widget for later restoration
+ tracker.add(widget);
+ }
+ if (!widget.isAttached) {
+ // Attach the widget to the main work area if it's not there
+ app.shell.add(widget, 'main');
+ } else {
+ // Refresh the comic in the widget
+ widget.update();
+ }
+ // Activate the widget
+ app.shell.activateById(widget.id);
+ }
+ });
+
+ // Add the command to the palette.
+ palette.addItem({ command, category: 'Tutorial' });
+
+ // Track and restore the widget state
+ let tracker = new InstanceTracker({ namespace: 'xkcd' });
+ restorer.restore(tracker, {
+ command,
+ args: () => JSONExt.emptyObject,
+ name: () => 'xkcd'
+ });
+ };
+
+Rebuild your extension one last time and refresh your browser tab.
+Execute the *Random xkcd comic* command and validate that the panel
+appears with a comic in it. Refresh the browser tab again. You should
+see an xkcd panel appear immediately without running the command. Close
+the panel and refresh the browser tab. You should not see an xkcd tab
+after the refresh.
+
+Refer to the `05-restore-panel-state
+tag `__
+if your extension is misbehaving. Make a commit when the state of your
+extension persists properly.
+
+.. code:: bash
+
+ git add .
+ git commit -m 'Restore panel state'
+
+Congrats! You've implemented all of the behaviors laid out at the start
+of this tutorial. Now how about sharing it with the world?
+
+.. _publish-your-extension-to-npmjsorg:
+
+Publish your extension to npmjs.org
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+npm is both a JavaScript package manager and the de facto registry for
+JavaScript software. You can `sign up for an account on the npmjs.com
+site `__ or create an account from the
+command line by running ``npm adduser`` and entering values when
+prompted. Create an account now if you do not already have one. If you
+already have an account, login by running ``npm login`` and answering
+the prompts.
+
+Next, open the project ``package.json`` file in your text editor. Prefix
+the ``name`` field value with ``@your-npm-username>/`` so that the
+entire field reads ``"name": "@your-npm-username/jupyterlab_xkcd"`` where
+you've replaced the string ``your-npm-username`` with your real
+username. Review the homepage, repository, license, and `other supported
+package.json `__ fields while
+you have the file open. Then open the ``README.md`` file and adjust the
+command in the *Installation* section so that it includes the full,
+username-prefixed package name you just included in the ``package.json``
+file. For example:
+
+.. code:: bash
+
+ jupyter labextension install @your-npm-username/jupyterlab_xkcd
+
+Return to your terminal window and make one more git commit:
+
+.. code:: bash
+
+ git add .
+ git commit -m 'Prepare to publish package'
+
+Now run the following command to publish your package:
+
+.. code:: bash
+
+ npm publish --access=public
+
+Check that your package appears on the npm website. You can either
+search for it from the homepage or visit
+``https://www.npmjs.com/package/@your-username/jupyterlab_xkcd``
+directly. If it doesn't appear, make sure you've updated the package
+name properly in the ``package.json`` and run the npm command correctly.
+Compare your work with the state of the reference project at the
+`06-prepare-to-publish
+tag `__
+for further debugging.
+
+|Extension page on npmjs.com|
+
+You can now try installing your extension as a user would. Open a new
+terminal and run the following commands, again substituting your npm
+username where appropriate
+(make sure to stop the existing ``jupyter lab --watch`` command first):
+
+.. code:: bash
+
+ conda create -n jupyterlab-xkcd jupyterlab nodejs
+ conda activate jupyterlab-xkcd
+ jupyter labextension install @your-npm-username/jupyterlab_xkcd
+ jupyter lab
+
+You should see a fresh JupyterLab browser tab appear. When it does,
+execute the *Random xkcd comic* command to prove that your extension
+works when installed from npm.
+
+Learn more
+~~~~~~~~~~
+
+You've completed the tutorial. Nicely done! If you want to keep
+learning, here are some suggestions about what to try next:
+
+- Assign a hotkey to the *Random xkcd comic* command.
+- Make the image a link to the comic on https://xkcd.com.
+- Push your extension git repository to GitHub.
+- Give users the ability to pin comics in separate, permanent panels.
+- Learn how to write :ref:`other kinds of
+ extensions `.
+
+.. |Completed xkcd extension screenshot| image:: xkcd_tutorial_complete.png
+.. |Empty xkcd extension panel| image:: xkcd_tutorial_empty.png
+.. |Single xkcd extension panel| image:: xkcd_tutorial_single.png
+.. |Styled xkcd panel with attribution| image:: xkcd_tutorial_complete.png
+.. |Extension page on npmjs.com| image:: xkcd_tutorial_npm.png
diff --git a/docs/source/developer/xkcd_tutorial_complete.png b/docs/source/developer/xkcd_tutorial_complete.png
new file mode 100644
index 00000000..fae3fec9
Binary files /dev/null and b/docs/source/developer/xkcd_tutorial_complete.png differ
diff --git a/docs/source/developer/xkcd_tutorial_empty.png b/docs/source/developer/xkcd_tutorial_empty.png
new file mode 100644
index 00000000..38c91d29
Binary files /dev/null and b/docs/source/developer/xkcd_tutorial_empty.png differ
diff --git a/docs/source/developer/xkcd_tutorial_npm.png b/docs/source/developer/xkcd_tutorial_npm.png
new file mode 100644
index 00000000..4302c76a
Binary files /dev/null and b/docs/source/developer/xkcd_tutorial_npm.png differ
diff --git a/docs/source/developer/xkcd_tutorial_single.png b/docs/source/developer/xkcd_tutorial_single.png
new file mode 100644
index 00000000..6f1cb138
Binary files /dev/null and b/docs/source/developer/xkcd_tutorial_single.png differ
diff --git a/docs/source/getting_started/changelog.rst b/docs/source/getting_started/changelog.rst
new file mode 100644
index 00000000..51c4fbc0
--- /dev/null
+++ b/docs/source/getting_started/changelog.rst
@@ -0,0 +1,1078 @@
+.. _changelog:
+
+JupyterLab Changelog
+====================
+
+v1.0.0 (not released yet)
+-------------------------
+
+2019
+^^^^
+
+See the `JupyterLab
+1.0.0 `__
+milestone on GitHub for the full list of pull requests and issues closed.
+
+Features
+^^^^^^^^
+* Enable searching notebooks, code editors, and CSV files. (`#5795 `__, `#5937 `__)
+* Add Commands To Open The Main Menus So That They May Be Assigned Keyboard Shortcuts. (`#5910 `__, `#3074 `__)
+* Add Insertbefore And Insertafter To Toolbar (`#5896 `__, `#5894 `__)
+* Html Viewer (`#5855 `__, `#2369 `__)
+* Simplify Inspector. (`#5776 `__, `#5560 `__)
+* Allow Keyboard To Trigger Toolbar Button Action (`#5769 `__, `#5757 `__)
+* Code Folding (`#5761 `__, `#4083 `__)
+* Configure Terminal Font (`#5732 `__)
+* Links to CSV cells (`#5727 `__, `#5720 `__)
+* Follow File Path Between File Browser And Editor (`#5698 `__, `#4258 `__)
+* Add 'name' Flag To Workspaces Import Cli (`#5695 `__, `#5694 `__)
+* Creating new folder immediately edits its name (`#5667 `__, `#5666 `__)
+* Extension Manager Docs (`#5657 `__)
+* Add An Option To Toggle Document Scrolling Behavior (`#5652 `__, `#4429 `__)
+* Extension manager sort by composite registry score (`#5649 `__)
+* Allow "run All Code"/ "restart Kernel And Run All Code" When Editing Text File (`#5641 `__, `#5579 `__)
+* Remove Trust Notebook From Menu (`#5631 `__, `#5354 `__)
+* Improve Handling Of Uri Fragment Identifiers (`#5630 `__, `#5599 `__)
+* Css: Add Alert, Alert-Info And Alert-Warning Styles (`#5621 `__)
+* Add Scrollback As A Terminal Setting (`#5609 `__, `#3985 `__)
+* Drag Drop Console Cells Into Notebook (`#5585 `__, `#4847 `__)
+* Pressing Ctrl While Dragging Should Copy Files (`#5584 `__, `#3235 `__)
+* Add 'Scroll Past End' Notebook Setting (`#5581 `__, `#897 `__)
+* Drag and drop notebook cells to an editor (`#5571 `__, `#3732 `__)
+* Update Documentation For Terminal Copy/paste (`#5541 `__, `#4143 `__)
+* Codemirror: Add Config Options To Style Selection (`#5529 `__, `#5528 `__)
+* Add "go To Line" And "find" Capabilities To Csvviewer (`#5523 `__)
+* Add Statusbar (`#5508 `__, `#5352 `__, `#5514 `__, `#5577 `__, `#5525 `__)
+* Add 'new Folder' Item To Filebrowser Context Menu (`#5447 `__)
+
+
+Bugs Fixed
+^^^^^^^^^^
+* Fix Focus Issues When Focusing Away From A Notebook In Edit Mode. (`#5925 `__)
+* Start A New Terminal If Connecting To An Old One Fails. (`#5917 `__)
+* Remove Initialcommand From Args Of Terminal Creation. (`#5916 `__)
+* Once More With Carriage Returns (`#5907 `__, `#4822 `__)
+* Update Launcher On Specs Change (`#5904 `__, `#5676 `__)
+* Fix Bug Output View Not Closing With Associated Window (`#5882 `__, `#5873 `__)
+* Fix Navigate Behavior (`#5880 `__)
+* When A Session Is Disposed, Also Unset Any Busy Status. (`#5853 `__, `#5244 `__)
+* Account For Tree Urls When There Is A Workspace Collision. (`#5830 `__, `#5214 `__)
+* Keep Autoscroll Behavior When Clearing Cell Output. (`#5817 `__, `#4028 `__)
+* Show Correct File Type For Reload And Revert Dialogs (`#5746 `__)
+* Reject Instancetracker#add() If Added Widget Is Already Disposed. (`#5724 `__)
+* Don't Display Any Output If Javascript Output Is Empty (`#5706 `__, `#5404 `__)
+* Completer Feature Parity (`#5858 `__, `#4305 `__, `#4165 `__, `#2360 `__)
+* Honor Body Data Upon First Call To Pageconfig.getoption() (`#5800 `__, `#5799 `__)
+* Relative Non File Paths (`#5814 `__)
+* Make Jupyterlab Default Ui When Running Jupyter-Labhub (`#5865 `__)
+* Clean Up Schemas, Setting Editor Toolbar. (`#5820 `__, `#5372 `__)
+* Passing 'noopener' To Window.open() Always Returns Null, Breaking Exporting (`#5771 `__)
+* Find Editor Widgets (`#5758 `__)
+* Add scrolling to cell tools (`#5707 `__, `#5685 `__)
+* Optimize Editor Refresh On Notebook Show (`#5700 `__, `#4292 `__, `#2639 `__)
+* Properly Dispose Of Text Model On Disposal. (`#5686 `__, `#5664 `__)
+* Fix Doc Links (`#5677 `__, `#5602 `__)
+* [Html] External Links Should Add Rel="noopener" (`#5656 `__, `#5655 `__)
+* Remove Download Link For Directories (`#5637 `__, `#1816 `__)
+* Menu Entries Highlight On Mouse Over (`#5629 `__, `#5509 `__)
+* Fix code snippet highlighting in markdown lists (`#5628 `__, `#5616 `__)
+* Fix Linecol Functionality (`#5625 `__)
+* Css: Make Ansi "inverse" Work On Dark Theme (`#5623 `__)
+* Retain Windows file line endings (`#5622 `__, `#4464 `__, `#3901 `__, `#3706 `__)
+* Change File Mod Time Hover To Use Local/locale Time Format (`#5567 `__)
+* Commandpalette Highlight Fix (`#5565 `__, `#5561 `__)
+* Fix _changekernel Bug When Session Dead (`#5551 `__)
+* Clear ``*`` Prompt From Console Cells That Are Not Going To Be Executed (`#5550 `__, `#4916 `__)
+* Fix Alignment Of Latex/mathjax Output Cells (`#5547 `__, `#5276 `__)
+* Make Dom Ids Begin With Prefix 'id-' (`#5539
JupyterLab assets not detected, please rebuild
+ + {% endblock h1_error %} + + +{% endblock %} + + + + diff --git a/dev_mode/templates/partial.html b/dev_mode/templates/partial.html new file mode 100644 index 00000000..673b9c52 --- /dev/null +++ b/dev_mode/templates/partial.html @@ -0,0 +1,12 @@ + + + {% block favicon %} + + + {% endblock %} diff --git a/dev_mode/templates/template.html b/dev_mode/templates/template.html new file mode 100644 index 00000000..3661c53e --- /dev/null +++ b/dev_mode/templates/template.html @@ -0,0 +1,36 @@ + + + + +
+ {{ _('Jupyter') }}
+
+ |
+
+
+
+
+
+
+The most complicated plugin included in the **JupyterLab application**
+is the **Notebook plugin**.
+
+The
+`NotebookWidgetFactory
+
+ 
+
+
`
+ );
+
+ // Keep all the remaining fetch and command lines the same
+ // as before from here down ...
+
+Build your extension if necessary (``jlpm run build``) and refresh your
+JupyterLab browser tab. Invoke the *Random xkcd comic* command and
+confirm the comic is centered with an attribution badge below it. Resize
+the browser window or the panel so that the comic is larger than the
+available area. Make sure you can scroll the panel over the entire area
+of the comic.
+
+|Styled xkcd panel with attribution|
+
+If anything is misbehaving, compare your code with the reference project
+`03-style-and-attribute
+tag
+
+
+
+
+
+
`
+ );
+ }
+
+ /**
+ * The image element associated with the widget.
+ */
+ readonly img: HTMLImageElement;
+
+ /**
+ * Handle update requests for the widget.
+ */
+ onUpdateRequest(msg: Message): void {
+ fetch('https://egszlpbmle.execute-api.us-east-1.amazonaws.com/prod').then(response => {
+ return response.json();
+ }).then(data => {
+ this.img.src = data.img;
+ this.img.alt = data.title;
+ this.img.title = data.alt;
+ });
+ }
+ };
+
+You've written all of the code before. All you've done is restructure it
+to use instance variables and move the comic request to its own
+function.
+
+Next move the remaining logic in ``activate`` to a new, top-level
+function just below the ``XkcdWidget`` class definition. Modify the code
+to create a widget when one does not exist in the main JupyterLab area
+or to refresh the comic in the exist widget when the command runs again.
+The code for the ``activate`` function should read as follows after
+these changes:
+
+.. code-block:: typescript
+
+ /**
+ * Activate the xckd widget extension.
+ */
+ function activate(app: JupyterFrontEnd, palette: ICommandPalette) {
+ console.log('JupyterLab extension jupyterlab_xkcd is activated!');
+
+ // Create a single widget
+ let widget: XkcdWidget = new XkcdWidget();
+
+ // Add an application command
+ const command: string = 'xkcd:open';
+ app.commands.addCommand(command, {
+ label: 'Random xkcd comic',
+ execute: () => {
+ if (!widget.isAttached) {
+ // Attach the widget to the main work area if it's not there
+ app.shell.add(widget, 'main');
+ }
+ // Refresh the comic in the widget
+ widget.update();
+ // Activate the widget
+ app.shell.activateById(widget.id);
+ }
+ });
+
+ // Add the command to the palette.
+ palette.addItem({ command, category: 'Tutorial' });
+ };
+
+Remove the ``activate`` function definition from the
+``JupyterFrontEndPlugin`` object and refer instead to the top-level function
+like so:
+
+.. code-block:: typescript
+
+ const extension: JupyterFrontEndPlugin
+
+