Introduce plugin framework
* Source files are under src/ * js/impress.js is now generated, but remains part of the repo (so it just works) * npm run build * build.js uses buildify node module * Break out navigation and resize plugins from core src/impress.js file
This commit is contained in:
Henrik Ingo
407
src/plugins/README.md
Normal file
407
src/plugins/README.md
Normal file
@@ -0,0 +1,407 @@
|
||||
Impress.js Plugins documentation
|
||||
================================
|
||||
|
||||
The default set of plugins
|
||||
--------------------------
|
||||
|
||||
A lot of impress.js features are and will be implemented as plugins. Each plugin
|
||||
has user documentation in a README.md file in [its own directory](./).
|
||||
|
||||
The plugins in this directory are called default plugins, and - unsurprisingly -
|
||||
are enabled by default. However, most of them won't do anything by default,
|
||||
rather require the user to invoke them somehow. For example:
|
||||
|
||||
* The *navigation* plugin waits for the user to press some keys, arrows, page
|
||||
down, page up, space or tab.
|
||||
* The *autoplay* plugin looks for the HTML attribute `data-autoplay` to see
|
||||
whether it should do its thing.
|
||||
* The *toolbar* plugin looks for a `<div>` element to become visible.
|
||||
|
||||
Extra addons
|
||||
------------
|
||||
|
||||
Yet more features are available in presentations that enable
|
||||
[extra addons](../../extras/). Extra addons are 3rd party plugins integrated
|
||||
into impress.js to provide convenient and standardized access to them. However,
|
||||
they are not activated by default, rather must be included with a `<script>`
|
||||
tag.
|
||||
|
||||
Note: The enabled extra addons are automatically initialized by the *extras*
|
||||
plugin.
|
||||
|
||||
Example HTML and CSS
|
||||
--------------------
|
||||
|
||||
Generally plugins will do something sane, or nothing, by default. Hence, no
|
||||
particular HTML or CSS is required. The README file of each plugin documents the
|
||||
HTML and CSS that you can use with that plugin.
|
||||
|
||||
For your convenience, below is some sample HTML and CSS code covering all the
|
||||
plugins that you may want to use or adapt.
|
||||
|
||||
### Sample HTML to enable plugins and extra addons
|
||||
|
||||
<head>
|
||||
<!-- CSS files if using Highlight.js or Mermaid.js extras. -->
|
||||
<link rel="stylesheet" href="../../extras/highlight/styles/github.css">
|
||||
<link rel="stylesheet" href="../../extras/mermaid/mermaid.forest.css">
|
||||
</head>
|
||||
<body>
|
||||
<div id="impress" data-autoplay="10">
|
||||
<div class="step"
|
||||
data-autoplay="15"
|
||||
data-rel-x="1000"
|
||||
data-rel-y="1000">
|
||||
|
||||
<h1>Slide content</h1>
|
||||
|
||||
<ul>
|
||||
<li class="substep">Point 1</li>
|
||||
<li class="substep">Point 2</li>
|
||||
</ul>
|
||||
|
||||
<div class="notes">
|
||||
Speaker notes are shown in the impressConsole.
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="impress-toolbar"></div>
|
||||
<div class="impress-progressbar"><div></div></div>
|
||||
<div class="impress-progress"></div>
|
||||
<div id="impress-help"></div>
|
||||
|
||||
<script type="text/javascript" src="../../extras/highlight/highlight.pack.js"></script>
|
||||
<script type="text/javascript" src="../../extras/mermaid/mermaid.min.js"></script>
|
||||
<script type="text/javascript" src="../../extras/markdown/markdown.js"></script>
|
||||
<script type="text/javascript" src="../../extras/mathjax/MathJax.js?config=TeX-AMS_CHTML"></script>
|
||||
</body>
|
||||
|
||||
### Sample CSS related to plugins and extra addons
|
||||
|
||||
/* Using the substep plugin, hide bullet points at first, then show them one by one. */
|
||||
#impress .step .substep {
|
||||
opacity: 0;
|
||||
}
|
||||
|
||||
#impress .step .substep.substep-visible {
|
||||
opacity: 1;
|
||||
transition: opacity 1s;
|
||||
}
|
||||
/*
|
||||
Speaker notes allow you to write comments within the steps, that will not
|
||||
be displayed as part of the presentation. However, they will be picked up
|
||||
and displayed by impressConsole.js when you press P.
|
||||
*/
|
||||
.notes {
|
||||
display: none;
|
||||
}
|
||||
|
||||
/* Toolbar plugin */
|
||||
.impress-enabled div#impress-toolbar {
|
||||
position: fixed;
|
||||
right: 1px;
|
||||
bottom: 1px;
|
||||
opacity: 0.6;
|
||||
z-index: 10;
|
||||
}
|
||||
.impress-enabled div#impress-toolbar > span {
|
||||
margin-right: 10px;
|
||||
}
|
||||
.impress-enabled div#impress-toolbar.impress-toolbar-show {
|
||||
display: block;
|
||||
}
|
||||
.impress-enabled div#impress-toolbar.impress-toolbar-hide {
|
||||
display: none;
|
||||
}
|
||||
/* If you disable pointer-events (like in the impress.js official demo), you need to re-enable them for the toolbar. */
|
||||
.impress-enabled #impress-toolbar { pointer-events: auto }
|
||||
/* Progress bar */
|
||||
.impress-enabled .impress-progressbar {
|
||||
position: absolute;
|
||||
right: 318px;
|
||||
bottom: 1px;
|
||||
left: 118px;
|
||||
border-radius: 7px;
|
||||
border: 2px solid rgba(100, 100, 100, 0.2);
|
||||
}
|
||||
.impress-enabled .impress-progressbar DIV {
|
||||
width: 0;
|
||||
height: 2px;
|
||||
border-radius: 5px;
|
||||
background: rgba(75, 75, 75, 0.4);
|
||||
transition: width 1s linear;
|
||||
}
|
||||
.impress-enabled .impress-progress {
|
||||
position: absolute;
|
||||
left: 59px;
|
||||
bottom: 1px;
|
||||
text-align: left;
|
||||
opacity: 0.6;
|
||||
}
|
||||
.impress-enabled #impress-help {
|
||||
background: none repeat scroll 0 0 rgba(0, 0, 0, 0.5);
|
||||
color: #EEEEEE;
|
||||
font-size: 80%;
|
||||
position: fixed;
|
||||
left: 2em;
|
||||
bottom: 2em;
|
||||
width: 24em;
|
||||
border-radius: 1em;
|
||||
padding: 1em;
|
||||
text-align: center;
|
||||
z-index: 100;
|
||||
font-family: Verdana, Arial, Sans;
|
||||
}
|
||||
.impress-enabled #impress-help td {
|
||||
padding-left: 1em;
|
||||
padding-right: 1em;
|
||||
}
|
||||
|
||||
|
||||
For developers
|
||||
==============
|
||||
|
||||
The vision for impress.js is to provide a compact core library doing the
|
||||
actual presentations, with a collection of plugins that provide additional
|
||||
functionality. A default set of plugins are distributed together with the core
|
||||
impress.js, and are located in this directory. They are called *default plugins*
|
||||
because they are distributed and active when users use the [js/impress.js](../../js/impress.js)
|
||||
in their presentations.
|
||||
|
||||
Building js/impress.js
|
||||
-----------------------
|
||||
|
||||
The common way to use impress.js is to link to the file
|
||||
[js/impress.js](../../js/impress.js). This is a simple concatenation of the
|
||||
core impress.js and all plugins in this directory. If you edit or add code
|
||||
under [src/](../), you can run `node build.js` to recreate the distributable
|
||||
`js/impress.js` file. The build script also creates a minified file, but this
|
||||
is not included in the git repository.
|
||||
|
||||
### Tip: Build errors
|
||||
|
||||
If your code has parse errors, the `build.js` will print a rather unhelpful
|
||||
exception like
|
||||
|
||||
/home/hingo/hacking/impress.js/js/impress.js
|
||||
|
||||
/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:271
|
||||
throw new JS_Parse_Error(message, line, col, pos);
|
||||
^
|
||||
Error
|
||||
at new JS_Parse_Error (/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:263:18)
|
||||
at js_error (/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:271:11)
|
||||
at croak (/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:733:9)
|
||||
at token_error (/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:740:9)
|
||||
at unexpected (/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:746:9)
|
||||
at Object.semicolon [as 1] (/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:766:43)
|
||||
at prog1 (/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:1314:21)
|
||||
at simple_statement (/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:906:27)
|
||||
at /home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:814:19
|
||||
at block_ (/home/hingo/hacking/impress.js/node_modules/uglify-js/lib/parse-js.js:1003:20)
|
||||
|
||||
You will be pleased to know, that the concatenation of the unminified file
|
||||
[js/impress.js](../../js/impress.js) has already succeeded at this point. Just
|
||||
open a test in your browser, and the browser will show you the line and error.
|
||||
|
||||
|
||||
### Structure, naming and policy
|
||||
|
||||
Each plugin is contained within its own directory. The name of the directory
|
||||
is the name of the plugin. For example, imagine a plugin called *pluginA*:
|
||||
|
||||
src/plugins/plugina/
|
||||
|
||||
The main javascript file should use the directory name as its root name:
|
||||
|
||||
src/plugins/plugina/plugina.js
|
||||
|
||||
For most plugins, a single `.js` file is enough.
|
||||
|
||||
Note that the plugin name is also used as a namespace for various things. For
|
||||
example, the *autoplay* plugin can be configured by setting the `data-autoplay="5"`
|
||||
attribute on a `div`.
|
||||
|
||||
As a general rule ids, classes and attributes within the `div#impress` root
|
||||
element, may use the plugin name directly (e.g. `data-autoplay="5"`). However,
|
||||
outside of the root element, you should use `impress-pluginname` (e.g.
|
||||
`<div id="impress-toolbar">`. The latter (longer) form also applies to all
|
||||
events, they should be prefixed with `impress:pluginname`.
|
||||
|
||||
You should use crisp and descriptive names for your plugins. But
|
||||
sometimes you might optimize for a short namespace. Hence, the
|
||||
[Relative Positioning Plugin](rel/rel.js) is called `rel` to keep html attributes
|
||||
short. You should not overuse this idea!
|
||||
|
||||
Note that for default plugins, which is all plugins in this directory,
|
||||
**NO css, html or image files** are allowed.
|
||||
|
||||
Default plugins must not add any global variables.
|
||||
|
||||
### Testing
|
||||
|
||||
The plugin directory should also include tests, which should use the *QUnit* and
|
||||
*Syn* libraries under [test/](../../test). You can have as many tests as you like,
|
||||
but it is suggested your first and main test file is called `plugina_tests.html`
|
||||
and `plugina_tests.js` respectively. You need to add your test `.js` file into
|
||||
[/qunit_test_runner.html](../../qunit_test_runner.html), and the `.js` file
|
||||
should start by loading the test `.html` file into the
|
||||
`iframe#presentation-iframe`. See [navigation-ui](navigation-ui) plugin for an
|
||||
example.
|
||||
|
||||
You are allowed to test your plugin whatever way you like, but the general
|
||||
approach is for the test to load the [js/impress.js](../../js/impress.js) file
|
||||
produced by build.js. This way you are testing what users will actually be
|
||||
using, rather than the uncompiled source code.
|
||||
|
||||
HowTo write a plugin
|
||||
--------------------
|
||||
|
||||
### Encapsulation
|
||||
|
||||
To avoid polluting the global namespace, plugins must encapsulate them in the
|
||||
standard javascript anonymous function:
|
||||
|
||||
/**
|
||||
* Plugin A - An example plugin
|
||||
*
|
||||
* Description...
|
||||
*
|
||||
* Copyright 2016 Firstname Lastname, email or github handle
|
||||
* Released under the MIT license.
|
||||
*/
|
||||
(function ( document, window ) {
|
||||
|
||||
// Plugin implementation...
|
||||
|
||||
})(document, window);
|
||||
|
||||
|
||||
### Init plugins
|
||||
|
||||
We categorize plugins into various categories, based on how and when they are
|
||||
called, and what they do.
|
||||
|
||||
An init plugin is the simplest kind of plugin. It simply listens for the
|
||||
`impress().init()` method to send the `impress:init` event, at which point
|
||||
the plugin can initialize itself and start doing whatever it does, for example
|
||||
by calling methods in the public api returned by `impress()`.
|
||||
|
||||
Both [Navigation](navigation/navigation.js) and [Autoplay](autoplay/autoplay.js)
|
||||
are init plugins.
|
||||
|
||||
To provide end user configurability in your plugin, a good idea might be to
|
||||
read html attributes from the impress presentation. The
|
||||
[Autoplay](autoplay/autoplay.js) plugin does exactly this, you can provide
|
||||
a default value in the `div#impress` element, or in each `div.step`.
|
||||
|
||||
A plugin must only use html attributes in its designated namespace, which is
|
||||
|
||||
data-pluginName-*="value"
|
||||
|
||||
For example, if *pluginA* offers config options `foo` and `bar`, it would look
|
||||
like this:
|
||||
|
||||
<div id="impress" data-plugina-foo="5" data-plugina-bar="auto" >
|
||||
|
||||
|
||||
### Pre-init plugins
|
||||
|
||||
Some plugins need to run before even impress().init() does anything. These
|
||||
are typically *filters*: they want to modify the html via DOM calls, before
|
||||
impress.js core parses the presentation. We call these *pre-init plugins*.
|
||||
|
||||
A pre-init plugin must be called synchronously, before `impress().init()` is
|
||||
executed. Plugins can register themselves to be called in the pre-init phase
|
||||
by calling:
|
||||
|
||||
impress.addPreInitPlugin( plugin [, weight] );
|
||||
|
||||
The argument `plugin` must be a function. `weight` is optional and defaults to
|
||||
`10`. Plugins are ordered by weight when they are executed, with lower weight
|
||||
first.
|
||||
|
||||
The [Relative Positioning Plugin](rel/rel.js) is an example of a pre-init plugin.
|
||||
|
||||
### Pre-StepLeave plugins
|
||||
|
||||
A *pre-stepleave plugin* is called synchronously from impress.js core at the
|
||||
beginning of `impress().goto()`.
|
||||
|
||||
To register a plugin, call
|
||||
|
||||
impress.addPreStepLeavePlugin( plugin [, weight] );
|
||||
|
||||
When the plugin function is executed, it will be passed an argument
|
||||
that resembles the `event` object from DOM event handlers:
|
||||
|
||||
`event.target` contains the current step, which we are about to leave.
|
||||
|
||||
`event.detail.next` contains the element we are about to transition to.
|
||||
|
||||
`event.detail.reason` contains a string, one of "next", "prev" or "goto",
|
||||
which tells you which API function was called to initiate the transition.
|
||||
|
||||
`event.detail.transitionDuration` contains the transitionDuration for the
|
||||
upcoming transition.
|
||||
|
||||
A pre-stepleave plugin may alter the values in `event.detail` (except for
|
||||
`reason`), and this can change the behavior of the upcoming transition.
|
||||
For example, the `goto` plugin will set the `event.detail.next` to point to
|
||||
some other element, causing the presentation to jump to that step instead.
|
||||
|
||||
|
||||
### GUI plugins
|
||||
|
||||
A *GUI plugin* is actually just an init plugin, but is a special category that
|
||||
exposes visible widgets or effects in the presentation. For example, it might
|
||||
provide clickable buttons to go to the next and previous slide.
|
||||
|
||||
Note that all plugins shipped in the default set **must not** produce any visible
|
||||
html elements unless the user asks for it. A recommended best practice is to let
|
||||
the user add a div element, with an id equaling the plugin's namespace, in the
|
||||
place where he wants to see whatever visual UI elements the plugin is providing:
|
||||
|
||||
<div id="impress-plugina"></div>
|
||||
|
||||
Another way to show the elements of a UI plugin might be by allowing the user
|
||||
to explicitly press a key, like "H" for a help dialog.
|
||||
|
||||
[Toolbar plugin](toolbar/README.md) is an example of a GUI plugin. It presents
|
||||
a toolbar where other plugins can add their buttons in a centralized fashion.
|
||||
|
||||
Remember that for default plugins, even GUI plugins, no html files, css files
|
||||
or images are allowed. Everything must be generated from javascript. The idea
|
||||
is that users can theme widgets with their own CSS. (A plugin is of course welcome
|
||||
to provide example CSS that can be copypasted :-)
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
If *pluginB* depends on the existence of *pluginA*, and also *pluginA* must run
|
||||
before *pluginB*, then *pluginB* should not listen to the `impress:init` event,
|
||||
rather *pluginA* should send its own init event, which *pluginB* listens to.
|
||||
|
||||
Example:
|
||||
|
||||
// pluginA
|
||||
document.addEventListener("impress:init", function (event) {
|
||||
// plugin A does it's own initialization first...
|
||||
|
||||
// Signal other plugins that plugin A is now initialized
|
||||
var root = document.querySelector( "div#impress" );
|
||||
var event = document.createEvent("CustomEvent");
|
||||
event.initCustomEvent("impress:plugina:init', true, true, { "plugina" : "data..." });
|
||||
root.dispatchEvent(event);
|
||||
}, false);
|
||||
|
||||
// pluginB
|
||||
document.addEventListener("impress:init", function (event) {
|
||||
// plugin B implementation
|
||||
}, false);
|
||||
|
||||
A plugin should use the namespace `impress:pluginname:*` for any events it sends.
|
||||
|
||||
In theory all plugins could always send an `init` and other events, but in
|
||||
practice we're adding them on an as needed basis.
|
||||
Reference in New Issue
Block a user