Tickets, tickets, & more tickets - Butter.js & Popcorn.js

This week at CDOT was quite a productive one, as I was able to get quite a few things done in both Butter.js and Popcorn.js.  In the past 2 weeks butter has come quite a long way from when I first saw it, which is quite astounding.  All of us have been working on different portions of the code and its all finally starting to come togethor.  Scott Downe has been working on a trackliner to replace the currently existing one, which used canvases and really limited a lot of potential with the previous code.  Scott changed it so the code would be using div's as well as other HTML elements in order to provide us with more control over the track/track events.  In doing so quite a few possibilities have come forward, such as having the ability to move trackEvents from one track to another, dragging and dropping trackEvents onto a track and having it appear where the user released a click (an early version of this was done by Chris DeCairos and was consumed by Scott's code, I think).  This was a huge step forward for butter and really leaves a lot of room for improvement.  Mohammed Buttu on the other hand has been working on getting a final cut pro plugin for butter up and running.  He is currently working on a prototype that should be done soon and by the sounds of it he has been making some pretty good progress over the course of the week.


As for myself I have been working on a wide range of things in both butter and popcorn.  In butter I have been working on quite a few tickets which centered around making the display much cleaner looking as well as re-arranging some of the elements on the page.  I removed the accordion from the side panel on the west side of the page and tore out both the help and project details and threw them into buttons on the top toolbar.  I then removed the video-srouce input box and also threw that into the project details.  These tickets were not particularly difficult but definately presented challenges.  One of these was triggering a save and having the fields update accordingly when the video source was changed.  Since I tore all of this out of the accordion and moved it somewhere else on the page, namely inside of a jquery dialog, it stoppped me from using the previous buttons and such.  After going through the code a bit, I was able to bind the save functionality to the new buttons that I created inside the jquery dialog's.  I also changed the size of the div that display's a quick preview of the currently targeted plugin when the video is played.  Previously, the div was very small and numerous plugins were displayed at the same time in really small divs.  We moved away from this approach and went for a larger div that displayed a single plugin. I also fixed some small issues that arose with the players that I got working last week.


Google Feed Script Error:

Yesterday we triaged all of the 0.7 tickets for popcorn and all of us received ownership for numerous tickets.  A few of my tickets were bug fixes to existing tickets so I decided to try and get those out of the way first, so that is where I began my day today.  The first ticket I worked on was fixing an issue with a plugin that I wrote a while back, the Google Feed plugin.  This plugin allows the user to display a scrolling blog feed, either horizontally or vertically, which is pretty cool.  The issue was that I was loading two different scripts and was only using a callback/doing any checking for 1 of the scripts.  For some reason past-me thought that this was exceptable, while obviously it isn't.  There was a ticket filed that the script was no being loaded sometimes in chrome, and since I knew the code quite well I took this one on.  After thinking about a solution for a bit, I realized that the best solution was to make one scripts callback function call the other script and then make that scripts callback function set the global flag that I had set up.  The fix worked and I threw it up for review and moved on.   The next ticket was fixing the baseplayers timing issues.

Baseplayer timing issue & Moustache script issue:

The baseplayer currently incremented its time by using a setTimeout that added 0.015 seconds itself, which was less then optimal.  This would cause issues as even tho the setTimeout is set to trigger every 15 milliseconds, in reality this time is not exact.  The solution I came up with was using javascripts Date objects and comparing 2 date objects between one another every time it passed through the timeout.  This worked but then I was screwing around with it, trying to break my own code, and what do you know I did.  I found that if I paused the baseplayer, the timing got all screwed up.  I found out that this was because upon baseplayer instantiation I was setting one of the variables to a new Date(), but never updated it.  This would be fine if it was never paused, because the time would just continue to update.  I needed to create a new date object when the baseplayer began playing again to obtain a new reference time to base the current updating time off of.  I implemented this and cleaned up the code a bit and voila, it worked.  Threw this ticket up for review and moved on to fixing another script loading problem with the mustache plugin which was very similar to the google feed fix.  I also got this one finished and SR+'ed today, which was nice.

The 2 hour or so of my day have been spent starting up some old work I did on a timeline plugin and getting that code ready for our 0.7 release which is in just over 2 weeks.  All in all I accomplished quite a bit over the course of the week and I'm stoked to continue busting out tickets all next week in order to get popcorn ready for release.   Another awesome week down!