David Scotson

This is a general question as I've been looking into online video recently and there's something I just can't find a simple answer for:

What is the point of "streaming" for asychronous files?

As far as I can tell, just putting the audio or video file on a website is fine unless:

• it's happening live and people would rather drop quality than fall behind
• you're trying to make it harder for people to copy your files

Youtube for example has progressive downloads (start watching before it's all loaded) and you can skip forward to points within a file--even if it's not already buffered--but it's just a file download. (Though I believe they use the 'fake streaming' approach built into lighttpd which is the same as the PHP based streaming scripts you get that let you jump ahead of your buffer and start downloading again from a later point in the file)

At my university video has always been handled by a "streaming server" (Windows to be precise, bah!) but no one can actually tell me why we'd want to use that rather than simply putting a .flv file on a server and linking to it through Moodle.

You guys seem to know what you're talking about so if someone could answer my question above in simple language, or point me to an appropriate resource, I'd appreciate it.

(One note, I can perhaps see a reason why for very long files streaming could be seen as an answer, but again I think a playlist of files broken up with "chapter marks" makes more sense to me)

As soon as I typed that, I thought someone's going to pick me up about it! That's what I get for being lazy and not going back to edit.

GIFs support 1-bit transparency so it works, sort of, for simple squarish bitmap art like most of the the standard Moodle icons. But you need png for alpha-transparency which will blend things into the background regardless of its color.

That's why the current help icon doesn't look particularly smooth. If you blend it in with the background then you need to pick a color in advance. That's what was done for the Nuvola iconset (you can see the sample with a white background attached) but then if the background isn't the same color as the one you chose you get either a box or with a bit extra work a less noticeable 'halo' effect. It may seem like a minor thing but it basically stops you changing the background color either in different places within a theme or even just creating a dark theme without a lot of work. All the little things add up.

And while I'm correcting small misunderstandings, there was talk earlier about CSS being cached. While the main .css files are cached, I was pointing out the amount of CSS that is inline with the HTML and outputted with every page view. As well as not being cached it mucks up the CSS cascade as it overrides the .css files.

And once last thing, I don't particularly think there's an amazing amount of work that needs to be done to make Moodle very themeable. It's just that the work that does need to be done will disrupt both developers and themers and also requires that they work in concert to a certain degree and so really needs to be done with consensus and a plan for how to get from here to there so that everyone is "singing from the same songsheet" as it were.

Stealth help image

Nuvola help image

Sorry for the confusion. I'd actually come looking in the forums to see if there was any work being done on refactoring the themeing code so I had a bit of a one track mind. Any more info on those proposed changes you mention?

The main reason I posted was I don't think it's possible to create a theme like Garland for Moodle at the moment and didn't want to see anyone getting set up with false expectations of what a student could produce.

As long as the student concentrates on the bits that are actually themeable (the header, footer and background mainly, blocks to a lesser extent) you can make some good early progress. It just becomes an uphill struggle once you move onto the fiddlier bits because of the things I listed above (which were what I was wanting to see if anyone was fixing for 2.0), amongst others and I thought that was worth flagging up.

Taking a look at this selection of themes (using the selector on the top right) that I found the other day gives you an idea of what can and can't be changed easily.

http://www.newschoollearning.com/moodle/?&theme=convertible_colored_pencils

You can get a similar idea from looking at themes in general but note that it looks like he's put a fair bit of effort into covering up the gaps and pushing the boundaries e.g. for the black theme ("stealth") he's gone through and added a black background to all the icons because they're gifs not pngs so you can't just use transparency. Or rounding the corners in the banner image so it looks nicer but it's not as easy to replace.

Getting back on topic, for themes that allow users to select colours/images you might want to automate such image manipulation in PHP with gd (as I believe the Garland theme does).

You might also be interested in the challenge of building an automated palette choosing tool like this:

http://blog.dabbledb.com/2007/04/white--or-green.html

It fits in with the idea that most educational organisations already have a 'look' or theme of their own.

Having that I still think that refactoring the themes especially the first three bullet points would make a good summer of code task. I've seen some pretty advanced stuff being suggested for other projects and those aren't exactly rocket science, more on the boring drudgery that no-one wants to do side of things to be honest. But as you say, it wouldn't be available for 1.9 since it would involve touching a lot of different parts of the code.

It would be good if the project was to create 2 very different themes. In fact it probably fits the summer of code better if 2 (or even 3) existing themes were ported from a blog or CMS system so that you're not relying on someone having artistic vision as well as image editing, css/html and PHP codings skills.

The core of the project would then be to create the hooks (like multiple containers) necessary to hang different themes on which would hopefully generalise to all themes. Sub-tasks would probably include:

• splitting the $meta, $menu, $navigation etc. in the header and footer into something like echo print_css($css) so that the theme developer can decide when, where and if each individual element gets shown and also mess with the raw data before it gets passed into the print function rather than have to replace or deconstruct the HTML output to make changes (which I was doing yesterday to add a category to the navigation breadcrumb)
• doing a grep -r "style=\"" and replacing the 1000 or so hits with either a semantic HTML tag, an #id, one or more .class names, or a mixture of the above as appropriate. This is a task that would be done much better by someone actually trying to port 2 or more actual themes at the same time so they wouldn't just be working in a vacuum. Particularly if one of the ported themes was something like The Sandbox
  
• similarly removing all the embedded img tags in the code and moving them to the CSS. This would probably have the biggest visual impact for the least work.
• If they're feeling bold they could move all the javascript into the header, and then into external libraries and replace the user, course and category themes with a CSS based equivalent (maybe next summer for that one)
  

I think Zoe got slightly mixed up when updating your example, the .file goes on the other side of the html tagname.

I think what you actually want is .book_content pre.listing

That is more specific than .book_content pre so anything you put in that selector will add to or overrule what has been specified in the current one.

That should get you going but, without wanting to confuse you further, you should really be putting the code inside <code> tags and only adding <pre> tags around those if you want to format one or more lines as a separate block/paragraph.That means you can use single variable names in a sentence with similar formatting.

And if you have two different types of code (one for the command line and one for file listings you should really have two classes:

In that case you'd use as many of these as you need:

   .book_content
   .book_content pre.file /* for things that affect the whole block of file listings e.g. the color of the box border that goes round the whole block
   .book_content pre.shell /* for things that affect the whole block of shell interaction
   .book_content code /* for things that affect the code text e.g. font selection, font color  
   .book_content pre.file code /* for things that only affect text in files e.g. use a different text color