I had threatened to do something truly evil on day 666, but I lack maniacal imagination. Well, that and I think that I have exhausted my evilness quotient for the week with the now complete draft of a chapter on object oriented programming in 3D Game Programming for Kids. Instead, I think it time to get back to some hacking on my fork of Mr Doob's code editor, which I call the ICE Code Editor in the book.
There are a couple of annoyances that have been cropping up as I use it. Those annoyances are only going to compound as more readers get involved. Also, I know that Mr.doob has made improvements on the original so revisiting the code can get me ready for evaluating those changes.
First up, I would like to delay updates to the Three.js visualization after making updates in the code layer. I think that the delay is sub-second currently and it feels sometimes as though I am racing to type continuously or quickly so that nothing breaks.
This turns out to be quite easy. The ACE code editor, which serves as the actual in-browser editor in my code-editor fork, exposes an on-change callback. In there, I simply up the duration between checks to be one and a half seconds instead of 300 milliseconds:
ace.getSession().on( "change", function () { save(); if ( documents[ 0 ].autoupdate === false ) return; clearTimeout( interval ); interval = setTimeout( update, 1.5 * 1000 ); });Lest I forget, since this is an application cache application (for offline usage), I need to ensure that I remove the manifest attribute from the HTML document:
<!DOCTYPE html> <html manifest="editor.appcache"> <head> <title>code editor</title> ...If I leave that in place, then I will not actually see any of the changes that I make—instead my browser will continue to use the old, application cache version. With that, I do indeed see a more leisurely 1.5 second delay in between the last change that I make and the Three.js layer updating itself. I wonder if that should be even higher for kids who may be significantly slower at typing. I will table that until I run this version through another couple of hackathons.
Anyhow, with that change in place, I am ready for another. I would like the various dialogs that I use in the editor to support enter-to-submit. I find it very annoying to have to hit the Save button. Thankfully, this is just DOM event coding:
var newProjectField = document.createElement( 'input' );
// ...
newProjectField.addEventListener('keypress', function(event) {
if (event.keyCode != 13) return;
createProject(newProjectField.value, templateField.value);
closeNewDialog();
}, false);
After doing the same elsewhere, I am ready to tackle an annoyance with the ACE Code Editor. The default tab size seems to be 4. I do not recall why I left it this way, but I am constantly re-editing text to get back to the normal 2 spaces per tab in the code.Thanks to the very excellent API documentation for ACE, I find that I simple need the
setTabSize()
method, which is part of the editor session:var ace = ace.edit("editor"); ace.setTheme("ace/theme/chrome"); ace.getSession().setMode("ace/mode/javascript"); ace.getSession().setUseWrapMode(true); ace.getSession().setUseSoftTabs(true); ace.getSession().setTabSize(2); // ...With that, I have cleared three fairly annoying behaviors from my TODO list. I am somewhat hesitant to push the change into production now that I have a bunch of active users. I will probably give it a few days of local use before pushing these changes into general use.
Day #666
No comments:
Post a Comment