geansai gorm

Archive for the 'javascript' Category

try it out - you need to log in to get a proper feel for it.

New items: a metronome, external tabs are shown in an iframe (makes it easier to use with the metronome and keeps the song within the context of the site), you can edit the songs you added and you can add a video of the song being played.

In the backend, I have a few architectural improvements (better class structure, etc), and the beginnings of the rating system which will eventually be able to figure out how difficult songs are in comparison with each other.

The metronome was very simple to create - I used the sound manager 2 library to manage the sound production, and a very small piece of javascript to do the timing. There are minor hiccups in the timing, but I think that’s due to the interaction between JavaScript and Flash (and JS is probably not supposed to be used for precision timing anyway).

stand-alone demo of the metronome, source files

Anyway - please try the guitar application - I know it’s a bit bare at the moment, but whenever I get the time, I add to it, and the more people use it, the more complete it will appear. feature requests and bug reports go here.

FCKeditor

If your project uses FCKeditor, then you may need to re-think how the FCKeditor instance is attached to the page - Firefox 3 has changed something (I’m not sure what) which causes FCKeditor to fail in some cases (not all).

The cause is not absolutely clear (the first bug mentioned above states that it relates to loading file:/// URIs, but in my case, that’s not true), but I have managed to fix a few cases by avoiding the dynamic method of on-the-fly initialising FCKeditor (var o=new FCKeditor('blah');o.ReplaceTextarea();, etc) and instead creating the required IFrames and hidden inputs manually. This is a hack - not a true solution, so hopefully someone at the source (FCKeditor) will fix the problem soon.

This bug in their Trac is probably the exact problem I’m experiencing. Note that that bug was “confirmed” by a member of the dev team 9 months ago, and has since been ignored by them.

LCD vertical lines

A few months back, my Acer Travelmate 2420 started developing vertical lines. It would have been expensive to replace the screen, so I instead opted to go for a new machine. I gave the machine to my son Jareth, who doesn’t complain too much about it.

Yesterday, while troubleshooting a sound problem, I noticed that if the screen was twisted /just so/, then the lines vanished. After a bit of experimentation, I found that pressure applied in a certain spot at the back of the screen would clear the lines.

So, there was no other option - I needed to fix it. I got my screwdrivers out, took the screen apart, and MacGyvered a solution together with some paper I had lying around - fold it into a thin strip, then fold one end of it down to form a bulky part, then slot that into place between the screen and the back cover so the bulky part is at the pressure point. When the cover was replaced, the vertical lines were gone.

I have no idea how long the solution will work for, and I am guessing that the solution is causing stress to parts of the screen which may cause a more complete failure at some point in the future, but for now, Jareth is very happily watching a DVD on his machine (Bear In The Big Blue House - Shapes, Sounds And Colours on Fedora 9, KDE4, for those interested).

Missing sound

As stated, Jareth’s laptop had a sound problem - as in lack of sound. this was eventually traced to pulseaudio simply not starting. The solution was to add pulseaudio --system & to /etc/rc.local so the sound engine would start when the machine started.

I’m currently working on removing MooTools from KFM. While doing that, I’m also trying to speed up KFM as much as possible. The reason I’m removing MooTools is that I feel that it is inefficient in some things, and I don’t like how it tries to attach itself to everything in the document - if you retrieve an element with ID ‘test1′ using $('test1'), then inspect the element, you’ll find that MooTools has added itself to the element. This happens a lot. They call it a feature.

I’m replacing it with jQuery. jQuery has a strong community and a database of plugins. I like it. While it is still possible to write inefficient jQuery code, I feel it is a bit more difficult than in MooTools.

change your events code

John Resig’s tutorial recommends adding events to objects using something like this:

$j('#the_element').click(eventToHandleClicks);

While that is very neat, and perfectly fine in most cases, it’s not very efficient when you’re adding it to hundreds of elements on a page when the elements are built up using functions as happens in KFM. (ie; the elements are added ad-hoc, and the events are added at the same time as the element creation)

The method I would recommend is this:

$j.event.add(document.getElementById('the_element'),'click',eventToHandleClicks);

In this case, we avoid the internal stuff that happens in $j() by replacing it with the fast browser function document.getElementById(), and we also jump straight to the addition of the event with the static $j.event.add() instead of $j().click() which is meant to work on an arbitrary number of elements and is therefore slightly slower.

The same applies to generic addEvent() code:

$j('#the_element').addEvent('mouseover',mouseOverEvent);

Again, replace that with:

$j.event.add(document.getElementById('the_element'),'mouseover',mouseOverEvent);

defer creation of events

Let’s say you have a hundred elements to create. Each element has a mouseover, click and mouseout event to be added. That’s 300 operations.

function inLink(){
  window.status='in link';
}
function outLink(){
  window.status='out of link';
}
function clickLink(){
  window.status='link clicked';
}
var i,el;
for(i=0; i<100; ++i){
  el=document.getElementById('link'+i);
  $j.event.add(el,'mouseover',inLink);
  $j.event.add(el,'mouseout',outLink);
  $j.event.add(el,'click',clickLink);
}

This is a very common piece of code. However, it is inefficient, both speed- and memory-wise. If you have 100 links, and are likely to only click one, then why bother adding the mouseout and click events to the rest?

The answer is to add those events upon mouseover and make sure they’re only added once.

function inLink(){
  window.status='in link';
  if(this.eventsAdded)return;
  $j.event.add(this,'mouseout',outLink);
  $j.event.add(this,'click',clickLink);
  this.eventsAdded=true;
}
function outLink(){
  window.status='out of link';
}
function clickLink(){
  window.status='link clicked';
}
var i,el;
for(i=0; i<100; ++i){
  el=document.getElementById('link'+i);
  $j.event.add(el,'mouseover',inLink);
}

I don't have a geansai gorm, but if I did, I might sometimes wear it.

geansai gorm