S5Project.org
Published 18 years, 5 months pastOver the past year-plus-a-half, S5 has grown from a small hack of a compact slide show script written by Tantek Çelik into a relatively complex bit of work. In the beginning, there was simply a way to take a single document and turn it into a series of slides. I added basic keyboard controls, a navigation menu, and the ability to have the navigation controls show and hide, and then threw it out into the public eye. People loved it, and with a lot of help from a lot of people, all manner of features were added: slide bookmarks, much better keyboard controls, incremental progress, a notes view, and more.
Despite all this community involvement, though, the code base was in a single set of hands: mine. Anything that was added to the “official” S5 code was done by me, as time and understanding allowed. As anyone could have predicted, this has slowed the advancement of S5 over time, and of late it’s brought advancement to a near standstill as I’ve struggled to keep up with other demands. The only thing I’ve added since 1.2a2 is the ability to blank the screen by hitting the “B” key, and that change has yet to become public.
Of course, the code is explicitly in the public domain, so anyone can add to S5—and many have. ZohoShow, for example, outputs S5 1.1 code. I’ve seen S5 used for product tours of medical software and board games. Jonathon Snook added a “live preview” version of the notes view, which I totally want to see in the primary code base. David Goodger made a bunch of useful Docutils-compatibility additions that I never managed to fold in. I also know of four different implementations of remote-control functionality, where one person runs a slide show and changes are reflected in remote copies. This is a feature perfect for distance learning, corporate netconferences, and other situations.
And all this time, there was still no way to have those enhancements, or any others, “come home” to the source of S5 unless I did it myself. Until now.
Thanks to Ryan King, we now have S5 Project, which will be the official home of S5. Besides the blog and mailing list S5-discuss, there will be a wiki, a source code repository, and a bug-and-feature-request tracking system. If you’re an S5 hacker, or even a frequent user, please do join the mailing list (I know, I know—another one?) or at least subscribe to the S5Project RSS feed to keep track of what’s going on. I expect the mailing list to become the place for coders to talk about additions they want to make and bugs they’re trying to squash, even after the bug-tracking software gets set up, and it will be a primary source of content for the wiki-to-come.
While it’s been the case that anyone may add to S5 in their own way, for whatever purpose they see fit, now there will truly be community access to what’s always been a community project. I hope you’ll join us there!
Comments (10)
Frankly speaking, I don’t like the JavaScript code. The last time I came across S5, it wasn’t even object orientated, there was just a big bunch of global functions. I’m glad this has changed. Yet, after looking at some random lines, I noticed some things I would consider harmful:
this.slides;— doesn’t do anything unless you assign something. But anyway, why not use the prototype object for properties, too?element.nodeName == 'BODY'— won’t work in XHTML.In general, that’s not very practical:
S5.prototype.foo1 = function() {};S5.prototype.foo2 = function() {};
S5.prototype.foo3 = function() {};
Instead I would suggest:
S5.prototype = {foo1 : function() {},
foo2 : function() {},
foo3 : function() {}
}
I know I was looking at pre-alpha code. I also know this whole S5Project.org idea is about contributing rather than ranting in your comments section. I just don’t have more time right now, so that’s it …
“Frankly speaking, I don”t like the JavaScript code. The last time I came across S5, it wasn”t even object orientated, there was just a big bunch of global functions.”
Frankly speaking, I do like the code, but then I wrote it. I’m old school, and I like global functions because they make sense to me and they work. Still, I will admit that S5 isn’t object-oriented for two primary reasons:
1. Programmers I know well and trust implicitly have told me that OO code can often be monstrously slow, whereas the kind of code I wrote can be faster. Please note that I do not claim both observations are always true in all cases on all computers for all languages. I’m just passing along a general observation from people who know way more about programming than I do. Then again, the one OO version of S5 I did find time to play with seemed pig-slow.
2. I don’t know how to write good OO code. I don’t even really know how to write my own OO code. Never have. So sue me.
That said, if others want to “clean up” the code, that’s always been an option. When it comes to the S5Project.org repository, though, I will very strongly advocate keeping any OO conversions of S5 to a separate branch of the code until they can be definitively shown to be equal or better to the original non-OO code in terms of speed.
Of course, for that to happen, someone(s) will have to invest the time and expertise to do the conversion and show that it yields superior performance for the user. With the new site, the door is wide open. All that remains is to walk through it.
Good point.
Now I don’t know what I was actually looking at, but it made use of prototyping. I thought this would become the next version.
I don’t think that wrapping the functions and variables you have (basically objects sitting in the window object) into a S5 object would slow things down. It would make S5 act more like a library, e.g. without interfering with other JS stuff that could be used in a presentation.
Yes, I’ll probably do that, later.
Finally S5 is going forward… :)
The feature I really really am somehow desperate to have in S5 is the ability to use SVGs natively embbeded into my presentation. I just hate converting my vector-based diagrams into a png and not having them fit into my screen/projector resolution… Oh, and some MathML too.
So my question is, when does S5 will be based on pure XHTML (as in strict) ?
Anyway, good work Eric!
@everyone-
There’s already a repository set up at http://hg.s5project.org/ . I’ve chosen to use Mercurial, as it seems to do very well for distributed, open source development.
@Dao-
Why would you prefer object literal syntax over prototype syntax?
I’m not an expert javascript programmer, and I know a lot of experts prefer the object literal syntax (I know by reading their code), but I don’t quite get it. Is it just fashion?
“why not use the prototype object for properties”
I dunno, I guess I hadn’t gotten to that.
@rui-
The standard answer is “write a patch”. Or, at least, describe to me what needs to be done to make it work.
-ryan
@Ryan,
from another post from Eric he states:
I wonder, as someone already has a patch for it, it should definitely be integrated into S5’s main trunk. :)
There’s actually no prototype syntax. The question is if you build the prototype object at once or step-by-step. And just loot at the example, all in one is shorter. The compactness is the major reason for JSON‘s appeal, thus it’s also fashion.
@Dao-
Indeed, it is a bit shorter, but I guess I’ve just never gotten accustomed to it. I’m willing to be convinced to change it, though :D.
-ryan
I absolutely adore S5, especially in combination with rst2s5. Thank you, Tantek and Eric!!!
Being a Debian user who doesn’t want to install KDE, I am left with the gecko rendering engines in Firefox, Epiphany, and Kazekahase. In all three browsers, S5 makes my browser crawl. Slide transitions can take up to 10 seconds (this is on a very speedy system), and the browsers are just generally uncooperative.
Does anyone have the same problem? Is there an easy solution, or does someone know of a way to debug this?
Whatever happened to s5project.org? It is still registered, but does not resolve anymore.