Impress.js: Community contributions is so much fun!

During June-July I had pretty much completed adding the features that I myself had in mind impress.js (as you might have read on this blog back then). Some of those features of course had been asked for multiple times by others as well, in particular the ability to define slide positions relative to the previous slide, was a popular request, with several pull requests proposing it as well. Now that I've added such a plugin, I have to say it is indeed much more convenient way of authoring presentations.

So in August I turned my focus onto the backlog of upstream impress.js pull requests and issues. Many of those github tickets have been open for 3-4 years now, without any attention from the upstream maintainers. But since I had implemented the long discussed plugin api in my fork, I was now finally ready to merge stuff!

Especially with pull requests merging community contributions is super rewarding! The work is already done by somebody else, you just add it to the repo. Then they are thankful to you for doing that, even if they did the work to begin with. Of course in this case the upstream repo has been stagnant for years, so that probably factors into the sentiment.

Also with the issues (i.e. feature requests) I processed, although I wrote the code myself, it was still very easy to do. For example the Stop plugin is literally like 1 line of code (minus the standard plugin api code). And for such small amount of work the person who filed the issue becomes happy, and of course impress.js itself becomes better!

Giving credit to the original author of a patch is important

The pull requests written years ago, of course don't know about the plugin api. My approach to picking up old patches is to not go back to the original contributor and ask them to rewrite the patch. After all, they might have lost interest in their patch when having to wait so long, and that would be totally understandable. So I've done the work to refactor the patch to use the new plugin architecture. But then I still use git --author to credit the original author of the patch. That's why the git log in my repo now has other authors than myself, even if it was me who actually did the commits. (In some cases I started from a pull requests, but ended up rewriting it so that not a single line from the original patch survived. In this case of course attributing my code to someone else would have been inappropriate.)

List of new features

Except for a couple cases that I postponed into the future, and one where I had a question to the author of the patch, I've now processed and merged everything in the backlog that I thought was meaningful to add. (In some cases there were pull requests to add a feature that could already be done with just normal use of CSS, in which case I responded to the tickets to help the person who had filed the issue/ticket.)

This is the list of features that was added from the backlog of community patches and requests:

Wow, that was quite a list! Didn't even realize how many features I'd added/merged until I wrote it into a list.

There's been a lot of interest in impress.js over the years, but it seems to have dwindled a bit as the project was not active. I hope merging all the pull requests and responding to issues will re-invigorate those who want to hack on it and add features. While upstream still has no plugin api or code changes committed, at least my repo is open: just do it as a plugin, add tests, and send pull requests!

Many of the above features, such as the progress bar and an interactive form with input elements, have been added to the Classic Slides demo.

A short TODO list

I mentioned there were 2 pull tickets I'm still interested in merging or implementing, but didn't do so yet. They are:

  • Support sub-steps. This feature is straight out of powerpoint, but boring as it may be, it can be added as a plugin. The good thing with plugin architecture is that if you don't want to use some feature, just don't. The plugin will not get in your way if you just ignore it.
  • 2D navigation: instead of just supporting moving to previous and next steps, it could be possible to extend the new Goto plugin so that, for example, you could define a different next slide for each of the arrow keys. IMO this is a great idea and plays into the 3D spatial nature of impress.js presentation. Who's to say what is the next or previous slide, let the presenter move in any direction he wants!

I have however already been working on another impress.js related project, which has been to explore and better understand the 3D space to create really stunning presentations in 3D. That will be the topic of my next blog post.

You're welcome Thierry! Thanks for visiting my site!

Regarding the PR #143, it isn't high priority for me, but has been on my radar. In the ticket I've asked for sample presentations that I could use for testing, but there was no response.

I never tried the "follow svg path" myself, but I did use hovercraft in the beginning and am aware of it. I think it would be really cool to have and hopefully someone one day will develop it. When developing the plugin API, I did keep in mind that it should be possible to develop such a positioning plugin as one example.

If you're interested, the relevant files to look at and copy from would be:
https://github.com/henrikingo/impress.js/blob/myfork/src/plugins/README… (of course)
https://github.com/henrikingo/impress.js/tree/myfork/src/plugins/rel (relative positioning plugin)

Basically, it would do the same as this rel plugin, just reading the SVG part is the challenge, but that has nothing to do with impress.js.

Add new comment

The content of this field is kept private and will not be shown publicly. Cookie & Privacy Policy
  • No HTML tags allowed.
  • External and mailto links in content links have an icon.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • Each email address will be obfuscated in a human readable fashion or, if JavaScript is enabled, replaced with a spam resistent clickable link. Email addresses will get the default web form unless specified. If replacement text (a persons name) is required a webform is also required. Separate each part with the "|" pipe symbol. Replace spaces in names with "_".
About the bookAbout this siteAcademicAccordAmazonBeginnersBooksBuildBotBusiness modelsbzrCassandraCloudcloud computingclsCommunitycommunityleadershipsummitConsistencycoodiaryCopyrightCreative CommonscssDatabasesdataminingDatastaxDevOpsDistributed ConsensusDrizzleDrupalEconomyelectronEthicsEurovisionFacebookFrosconFunnyGaleraGISgithubGnomeGovernanceHandlerSocketHigh AvailabilityimpressionistimpressjsInkscapeInternetJavaScriptjsonKDEKubuntuLicensingLinuxMaidanMaker cultureMariaDBmarkdownMEAN stackMepSQLMicrosoftMobileMongoDBMontyProgramMusicMySQLMySQL ClusterNerdsNodeNoSQLodbaOpen ContentOpen SourceOpenSQLCampOracleOSConPAMPPatentsPerconaperformancePersonalPhilosophyPHPPiratesPlanetDrupalPoliticsPostgreSQLPresalespresentationsPress releasesProgrammingRed HatReplicationSeveralninesSillySkySQLSolonStartupsSunSybaseSymbiansysbenchtalksTechnicalTechnologyThe making ofTransactionsTungstenTwitterUbuntuvolcanoWeb2.0WikipediaWork from HomexmlYouTube