Adds heart.system namespace functions, corresponding to love.system

[00dani]

This changeset implements all but love.system.getProcessorCount(), because that particular function can't be done cleanly in JS without pulling in an external library https://github.com/oftn/core-estimator . Whether pulling in that library to enable one, likely rarely-used LÖVE function is worth it is up for debate.

All the functions work to some extent in all the browsers, but due to security restrictions a lot of it does not work as nicely as one would wish. Also, the HTML5 Battery Status API is not available in browsers other than Firefox yet, and there is no other way to access that information; fortunately that API will soon be implemented in Chrome (it's already in WebKit itself).

[00dani]

As well as the processor-count-estimation library to enable heart.system.getProcessorCount(), we may be able to pull in a library to make the clipboard functions work better, such as http://zeroclipboard.org/ ?

[darkf]

(Really sorry for not getting back to you sooner!)

Change itself looks good, but I wonder how much of this would be really useful to have, and how much of it we should put in an extras module. I think at some point having libraries for things like state and sprite-based animation would be useful, and things like this (OS detection, power stuff, etc) could go in there as well.

Any thoughts on this?

[00dani]

Honestly, the whole heart.system namespace is probably not very useful in general. My strategy for pull requests is less "stuff that might be useful" and more "stuff that happens to exist in LÖVE"; I'd like a heart.system for mere consistency, but it indeed really wouldn't have much actual use.

Splitting up heart.js into multiple files and/or modules would be a good idea, in the long run, since otherwise as namespaces are ported from LÖVE that file's gonna get really big. I don't think an "extras" additional module is really the best idea, though? Modules that correspond to the namespaces on heart, like a heart/system.js, might be preferable.

[darkf]

Alright. That seems sensible for core modules. The only thing I'm worried about is timer and graphics stuff not being accessible just from including heart.js - which is a big win for me since I can just reference it from an HTML file and start writing code without using some module system to include the dependencies for me. Maybe have core stuff in heart.js then factor some stuff (like system, some of the more obscure parts of graphics, etc) out to other modules would be cool.

[00dani]

One option would be to split all the namespaces out into separate files, then have the browser-globals mode in the heart.js file inject <script> tags to load up the most common namespaces automatically. I'm not sure how well that actually works, though. (I believe the Crafty game library uses this approach?)

[darkf]

That's probably how libraries providing browser-based require work. I wouldn't really be adverse to that, but it is still quite a bit more clunky than requiring what you use, IMHO.

[00dani]

Well, the browser-based requires I know of (browserify and webpack) both work by statically analysing the source for require() calls and bundling all dependencies into one file, so that require() can then just be synchronously loading different parts of the same file.

Hmm. One possible setup for heart.js would be to use separate modules for each namespace, then have a main file kind of like this:

var heart = module.exports = {
  graphics: require('./graphics'),
  physics: require('./physics'),
  system: require('./system'),
  // etc
};

Then use a bundler, like Browserify, to build a single heart.js file that bundles up all the modules? That's rather CommonJS-biased, though, so if you're more partial to using browser globals most of the time that may be undesirable. (In actual use, the single heart.js file would work much the same as the current version, though.) Thoughts?