mattwestcott

That's probably down to the 128K Spectrums having a slightly faster clock speed than the original 16/48K model (3.5469MHz versus 3.5 exactly). I knew this would cause the timings to drift (hence the need for the RasPi to provide a time source) but I overlooked the effect this would have on pitch...

(On the other hand - since the BEEP routine was being called from BASIC, adding in a pitch adjustment calculation may well have slowed things down enough to throw the timing off again :-) )

I see in no way how a BSD License is free.

The FSF are quite happy to describe it as a free software licence https://www.gnu.org/licenses/license-list.html#ModifiedBSD - not sure who else's definition you'd rather use...?

It's not quite possible yet, but that's a frequently requested feature, and we're most of the way there. The wysiwyg component we're using, http://hallojs.org/, supports defining extra buttons via plugins, and Wagtail provides a hook mechanism for passing in custom JS/CSS to the editor - we're just missing a bit of glue to connect the two.

I'm cautious about overloading the rich text editor with too many features - things like tables, say, would be better handled as an explicit part of the page model / template rather than kept in an opaque blob of HTML - but I can appreciate the need for more formatting options.

xaritas has hit the nail on the head with the key differences...

As I see it, Django CMS's philosophy is to pass on as much flexibility as possible to the editor in terms of page layout. Wagtail takes a more 'prescriptive' approach where the page content has to fit a particular data model (such as an event page that has a start/end date, list of speakers and so on) - which means a little less freedom for editors, but on the flipside, it gives the site creator a lot more control over page layout and design, makes it easier to repurpose that data, and goes a long way to making the editor UI friendlier (since it's a case of 'fill in the gaps' rather than a blank canvas).

On the 'framework on top of the framework' point - one thing we've aimed to do with Wagtail is to preserve Django's approach to models, templates and so on, rather than falling into the 'inner platform' trap and building a totally new system that just happens to use Django under the hood. So, for example, page layout is still done with Django's template system, and new page types are just Django models with some additions. As a result, using Wagtail is actually not massively different to the DIY route, at a functional level - but you get the extra bells and whistles like revision tracking and workflow as well.

There's an 'unofficial' online demo (with some limitations - image / file uploads aren't supported) courtesy of Wagtail contributor Serafeim Papastefanos here: http://gentle-refuge-2590.herokuapp.com/

Yes, multiple sites are supported - there's a single tree for all pages in the system, and any number of sites can be 'rooted' at different points in the tree. (Currently this is configured in Django's own admin interface, but we'll be moving this into the Wagtail interface proper.)

There are some https://github.com/torchbox/wagtail/blob/master/wagtail/wagt... - but not enough, we know. We're on it!

oops, hazards of working off a live Git repo there :-) Fixed now - please run a git pull / pip install -r requirements/dev.txt and try again!

Agreed, proper test coverage is absolutely something we want to achieve. We're working on it as we speak... https://github.com/torchbox/wagtail/blob/master/wagtail/wagt...

- Matt (lead Wagtail dev)

I had it as one tall column originally, but it turns out that one particular browser (Firefox, I think it was) refuses to render 44200px-high images.

"(or use a css sprite)"

You mean like this one... http://smyfaceimages.s3.amazonaws.com/moods_orange.png ?

(yes, it's a bit of a mammoth image, but that's animation for you...)