Monday, February 18, 2013

Doing Good on Day 666

‹prev | My Chain | next›

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