Media panel integration ready for assessment
michelled33 at gmail.com
Thu Mar 1 16:12:00 UTC 2012
Thanks Antranig! This is looking a lot better. As you expected, there are some bugs and I'm going to do some more testing and add them to the planning page. We talked about it in the channel and we decided that despite the bugs it would be better to merge these improvements into the demo branch since it adds some of the basic functionality that we'd like to show. After the daily meeting today, we'll take a closer look at where we are at and update the 'red list' again.
On 2012-03-01, at 5:52 AM, Antranig Basman wrote:
> I've pushed to my branch (amb26/demo-integration-sketch) a seemingly working version of our media panel integration... it correctly broadcasts events relating to volume, language and transcript settings.
> There has been significant rewriting of the logic of the related parts of the video player, mostly simplifying them. In particular, all updates to the video volume are handled directly through the model, which seems to have been set up to be shared across all subcomponents in any case. "Backwash protection" avoiding infinite loops between reads and writes of the volume state by UI components is helped by some utility functions, which right now are in VideoPlayer_controllers.js, but will be shortly pushed out into the core framework -
> fluid.hasChangeSource - assesses whether a change event came from a particular source
> fluid.addSourceGuardedListener - adds a change listener that only fires for changes not from a source
> fluid.fireSourcedChange - fires a change event with a particular source noted.
> This kind of scheme should be our preferred one for various other kinds of updates, removing the need for dedicated named events relating to each kind of update (which, after all, was the purpose of the ChangeApplier in the first place). In future, we will be also able to separate the models sent to different components in a set, by means of something like the "relay" system which is currently used to connect UIOptions with VideoPlayer. These will all find their way into the framework relatively soon with some suitable declarative syntax - in the meantime the utilities are free to use.
> I took the opportunity to knock off a number of other very annoying bugs - for example toolbar 4. "selecting the already select option does not hide the menu for transcripts and captions", various superfluous code was removed from the MenuBar to enable this
> "volume slider needs a background - too easy to have it disappear when trying to change the volume" and
> "volume slider should be above scrubbing handle" set by CSS rules on ".fl-videoPlayer-volumeControl"
> "multiple quick hovers cause ghosting of appearance/disappearance of controls" fixed by appropriate use of jQuery.stop()
> I've only given this branch light testing so far - in particular, I haven't tested captions or keyboard-a11y very much and so may have missed a few facilities during simplification work. Please take a look and supply fixes/comments - more tomorrow, assuming no bigger problems, I'll next turn to "mute should move the volume slider to the bottom and sliding the volume to the bottom change the icon to mute" as well as ensuring that the MyInfusion.js can be produced by means of some reasonable kind of framework build. It depends on two fixes for which there are currently pull requests as well as various other changes to UIOptions and ChangeApplier utility functions.
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work