Chrome extension development #1

this actually started right after i got my second monitor(1600x900 more pixels of fun!)  and noticed the ghastly look of the horizontal whitespace on google's search results. normally i'd just copy pasta bits of code from here and there and hack together something useful, but this time i'm actually committed to code this from scratch. although it's partly the result of the lack of development in chrome's extensions community.

(the finished product is over at: https://chrome.google.com/extensions/detail/hcoffdchjckinjfjgekdiljgihnpmdoe)

writing a chrome extension is actually easier than i thought. the entire extension 'is controlled by a JSON serializeable object which has several parts working/communicating with each other. almost all extensions have a background page(written in html, javascript), which is the entity of the extension itself. only one instance will be running at once, and it's usually the center that controls everything. then you have a couple minions working for the background page. in my case there was only a contentscript(a javascript file), which is injected into the page that matches the pattern. the contentscript first sends a message seemingly to no particular receiver, asking for its fate:

//send request to bg page for the state of the injection
chrome.extension.sendRequest({request: "state"},function(response){
state = response.state;
if(state == "true"){
        searchw();//function to start the shit up
}
});

The background page, hearing the distress of the contentscript, responds based on whether the plugin is enabled or not:

chrome.extension.onRequest.addListener(
function(request, sender, sendResponse) {
if(sender.id = extensionID){
      sendResponse({state: localStorage["state"]});//retrieve the state from settings, and send it back
}
else
      sendResponse({});//it's not our script calling, ignore
});

once the contentscript gets the go ahead from the background page, it starts doing it's work.

when i started coding this plugin i had 2 goals in mind: 1. the plugin must be aesthetically pleasing. This is obvious because the point of the plugin is so that a more useable state is derived from a less useable state.

and 2. the plugin must be non obtrusive. which meant that the plugin must be minimalistic and efficient, so the user would not notice a drop in performance(of the browser)

1. is fairly simple to achieve. the difficulty lies in achieving 1. while achieving 2.

to achieve my second goal i had to make 2 sacrifices: no local txt/html will be used. using DOM to dynamically generate the html would shave off the time reading from the hard drive. in addition, no local images will be used. again, generating the graphics procedurally means lower load time.