Hm... I need to see a fuller proposal to decide if that makes sense. The point of moving less-used stuff out of <view> to a mixin would be to lighten most views (and subclasses), so if we always mix it in to <view> we will have achieved nothing. I think we might want to take the opportunity in 5.0 to say that if you need the multi-frame capability of <view> you have to add the mixin (or we provide a pre-mixed tag, say <mediaview>).
On 2011-01-09, at 17:07, Max Carlson wrote: > We can move media playback to a mixin, but the base view will still include > it for back-compatibility. > > Can't you just override view.play/stop() to match the HTML5 API? > > On 1/9/11 1:43 PM, Henry Minsky wrote: >> >> >> I would be in favor of deprecating the lz.view.play() method, because I >> think it would be good >> to try to separate out media playback from the core view functions. Max >> suggested having a playback >> mixin for view. >> >> The <html5mediaview> component that I'm working on has a "play()" >> method, which follows the HTML5 spec, (also a "pause()" and "load()" >> method) and I would be happy to see it's play method not have to be >> arglist compatible with lz.view.play(). >> >> The HTML5 media element has both a "onplay" and "onplaying" event. As >> best I can understand the >> spec, "onplay" is sent when you call the play method or when autoplay >> starts the thing playing. But it doesn't guarantee the video is actually >> playing for the user. If the network hasn't gotten the data yet or >> something, the video might not really be visible yet. Whereas >> "onplaying" is sent when the system really believes the video to be >> playing. At least that's how I interpret it. I'm relaying both of those >> events from the HTML element up to the lzx component. So >> <html5videoview> will send both "onplay" and "onplaying". >> >> >> >> >> >> On Sun, Jan 9, 2011 at 3:03 PM, P T Withington <[email protected] >> <mailto:[email protected]>> wrote: >> >> Henry needs to weigh in here, because he has some concerns about the >> different `play` API's for a multi-frame <view> vs. a <video> (which >> presumably is a subclass of <view> so needs to have a coherent >> method signature to subclass). >> >> On 2011-01-09, at 14:23, Max Carlson wrote: >> >> > Change maxcarlson-20110109-O0R by maxcarl...@friendly on >> 2011-01-09 11:03:54 PST >> > in /Users/maxcarlson/openlaszlo/trunk-clean >> > for http://svn.openlaszlo.org/openlaszlo/trunk >> > >> > Summary: Deprecate view.play/onplay/onstop in favor of >> view.playing attribute >> > >> > Bugs Fixed: LPP-7273 - <view> `play` attribute should be >> deprecated, replace with `playing` (and make that read/write) >> > >> > Technical Reviewer: ptw >> > QA Reviewer: [email protected] <mailto:[email protected]> >> > >> > Details: LzSprite - Use resourceevent() to set playing attribute. >> > >> > LaszloView - Update docs on playing attribute to be read/write, >> add onplaying event. Deprecate onplay/onstop. Add deprecated >> warning to view.play virtual setter. >> > >> > Tests: test/lfc/legals/multiframeresource.lzx runs like before >> across all runtimes >> > >> > Files: >> > M WEB-INF/lps/lfc/kernel/swf/LzSprite.as >> > M WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js >> > M WEB-INF/lps/lfc/kernel/swf9/LzSprite.as >> > M WEB-INF/lps/lfc/views/LaszloView.lzs >> > >> > Changeset: >> http://svn.openlaszlo.org/openlaszlo/patches/maxcarlson-20110109-O0R.tar >> >> >> >> >> -- >> Henry Minsky >> Software Architect >> [email protected] <mailto:[email protected]> >> >>
