New testing version: 2014.2.6.2.
Changes from ver. 2013.12.9.0:
I almost removed everything that was working. You heard me right, I rolled back. I just want to re-write it so that everything is better organized and easier to understand, hopefully.
Some files are re-named. Many files have been commented out. I might add some of them back but I think most likely I’ll just re-write all of them.
Now the ‘main.js’ is replaced by the ‘content_document_start.js’, which I think has a better name. 🙂
So what has been done in this brand new version? Well, very little.
But I did added something I think useful. I brought 4 new libraries of mine in to enrich the features. The PQUEUE, SETRACE and UNIQUE-IT are just small tools to help with coding, but the iNotiC could be something more interesting to the users; it’s a notification-center-like logging system!
Previously I only used console logs to give feedbacks to myself and some caring users. Then it got to the point there were just too many logs, mixed along with errors and warnings from Youtube page itself! Catching one specific log line got harder and harder. Also when Chrome is re-rendering the DOM (when there are changes in the DOM structure) and the Inspector is activated, things will slow down, if not freeze up, badly because Chrome needs to do tons of updates in the Inspector as well. Well now I put this new logging system in, it looks, at least I think, much better!
The way this iNotiC library helps is that I’m using it to prompt critical messages, and even in a good-looking way! Here are some snapshots:
See those red/gray blocks top right? They are prompted by ushout plugin through iNotiC. Don’t they look nice? 😀
So with that, what I’ve finished so far, that really is related with the ushout project itself, are the follows:
- Detection of push state. Youtube is using html5 push state to change the url while NOT reloading the page, but only use ajax to load the new page. Successful detecting new states being pushed is crucial to knowing user is getting to another page and therefore the plugin needs to reset whatever changes it has done to the page and prepare to modify the new one.
- Detection of youtubePlayerReady. It’s only safe to request Youtube Player APIs when youtubePlayerReady is detected.
- A code structure for the outer most loop of logic of the plugin. This is done with the help of PQUEUE.
Plan for next?
Now that I know exactly when the user is on a page watching a video, I know when the plugin needs to make modifications to the video player. Maybe I’ll add a ‘full-window’ button first (because I really want one) but before adding any other controllers, I need to make sure I can detect all the events happening during a video such as buffering, pausing, playing, ad playing, stopping, seeking, etc.
I’ll see what I can do over this weekend.
Now I need to head to my bed!