Warning: mysql_real_escape_string(): No such file or directory in /home/jcarlson/methodknowledgy.com/wp-content/plugins/easy-google-syntax-highlighter/easy-google-syntax-highlighter.php on line 50

Warning: mysql_real_escape_string(): A link to the server could not be established in /home/jcarlson/methodknowledgy.com/wp-content/plugins/easy-google-syntax-highlighter/easy-google-syntax-highlighter.php on line 50Rendering Media in Project: Apollo | MethodKnowledgy

My proverbial "shed" for all things code

Main menu

Post navigation

Rendering Media in Project: Apollo

Just wanted to document a few nuances that I ran into while working on some of the UI features in Project: Apollo.

Flash movies must be visible

I was hoping to use CSS to set the <embed> element for a Flash movie to something like:

embed {
display: none;
}

As it turns out, a Flash movie that isn’t displayed isn’t rendered at all; the plugin control is killed off it becomes invisible. This may not be the case in all browsers, but it is the case in FireFox. As an aside, you can set the visibility to “hidden”, but the Flash object will generally still participate in DOM layout.

This was a problem because for audio visualization or video playback as I wanted to have the player hidden until the visuals were requested by the user. Unfortunately, in this case, playback does not occur.

The solution to this problem was to use absolute or fixed positioning to station the visuals where I wanted them. When not wanted, I positioned the element somewhere off-screen.

There may be some fudgery necessary to keep the window from unnecessarily adding scroll bars, but I am using GWT’s LayoutPanel so this was not an issue (or at least, accounted for automatically).

This also had the side effect of complicating my thoughts around a skinnable UI. Because of this visibility bug, I can’t depend on the skin to manage the container for the MediaControl. To do so would expose too much risk of a skin setting the Widget invisible or otherwise running amuck.

Instead, I relied on a less-pretty-but-more-reliable approach of providing limited access to a managed container in the DOM. The skin can never remove this element from the DOM and so the risk of runamuckery is greatly reduced. My managed container exposes just the functions of LayoutPanel I want exposed to the skin. If the need arises, I may switch this to a singleton interface, but for now, static methods suffice.

As another aside, a fully functional and fleshed out technical demo of the ControlBar is coming soon. Just have a few more items to wrap up.