fluid-work IRC Logs-2012-02-16

[08:56:12 CST(-0600)] <avtar> anastasiac, michelled: any idea if that mac mini near your desks will be used in the near future?

[08:56:56 CST(-0600)] <avtar> or did it get moved to the collaboration room?

[09:04:52 CST(-0600)] <michelled> avtar: it's in the collab room

[09:05:03 CST(-0600)] <michelled> we use it for the daily meeting

[09:05:13 CST(-0600)] <michelled> avtar: do you need it for something?

[09:05:32 CST(-0600)] <avtar> not the mini itself, just the power adapter

[09:06:12 CST(-0600)] <avtar> i need to bring back a mini from the data centre but would prefer not to unplug its cables due to the way everything is set up

[09:06:32 CST(-0600)] <avtar> i'm waiting to hear back from bert to see if he has extra power adapters at the office

[09:08:07 CST(-0600)] <avtar> the mini in the collab room doesn't get used after the morning meetings?

[09:26:44 CST(-0600)] <michelled> colinclark, anastasiac: I think we've been having some miscommunication regarding the menu button and what we should do with it.

[09:27:00 CST(-0600)] <colinclark> ok

[09:27:02 CST(-0600)] <michelled> colinclark: anastasiac and I just talked in person and I wanted to let you know what we are currently planning to do

[09:27:04 CST(-0600)] <colinclark> let's chat about it

[09:27:11 CST(-0600)] <colinclark> cool

[09:27:12 CST(-0600)] <colinclark> lay it on me

[09:27:47 CST(-0600)] <michelled> anastasiac has a branch where the caption button has been refactored in response to the code review that Bosmon gave at the community code review session

[09:28:03 CST(-0600)] <michelled> in her branch, the button works a lot better than what we've got in master and the code is cleaner

[09:28:36 CST(-0600)] <michelled> I'm thinking given our time constraints, we'll go with that branch for the upcoming demo and change to using a menu button later

[09:29:08 CST(-0600)] <anastasiac> The one thing not yet working right is hiding the captions menu when focus moves elsewhere, as discussed last night

[09:29:25 CST(-0600)] <anastasiac> I'm going to spend a short amount of time investigating using an anchor instead of a button

[09:29:31 CST(-0600)] <michelled> the refactoring that was done is a step in the right direction and eventually we'll rip out our home baked menu button and use the query ui one

[09:29:32 CST(-0600)] <anastasiac> if I can do that quickly, we'll go with that

[09:29:55 CST(-0600)] <anastasiac> the jquery ui menu will need some of the work I've done already, since it doesn't have all the interactions we want

[09:30:28 CST(-0600)] <michelled> it'll require an upgrade to the version of jquery that we use which we want to do for infusion anyway so there will be some coming together of goals

[09:30:57 CST(-0600)] <colinclark> Okay

[09:31:03 CST(-0600)] <colinclark> Go for it

[09:31:08 CST(-0600)] <colinclark> Button -> anchor

[09:31:10 CST(-0600)] <colinclark> and off we go

[09:31:14 CST(-0600)] <michelled> yep

[09:31:21 CST(-0600)] <colinclark> I'd like to make sure we check in a bit more closely when we make decisions like this

[09:31:39 CST(-0600)] <colinclark> This is exactly the kind of decision that involves a lot of judgement

[09:31:42 CST(-0600)] <colinclark> a lot of critical thinking

[09:31:44 CST(-0600)] <colinclark> we've been here before

[09:31:50 CST(-0600)] <colinclark> When to use a widget, when to roll our own

[09:32:04 CST(-0600)] <colinclark> I would like us to get to a point where we're moving very fast in our development of the Video Player

[09:32:08 CST(-0600)] <colinclark> but at no point are we rushing

[09:32:15 CST(-0600)] <colinclark> just trying to make things "work"

[09:32:23 CST(-0600)] <colinclark> Does that seem reasonable?

[09:32:28 CST(-0600)] <anastasiac> yep

[09:32:33 CST(-0600)] <michelled> yes

[09:32:48 CST(-0600)] <colinclark> I would appreciate it if we could surface these kinds of decisions, before they're made and code is written, in a public forum

[09:32:52 CST(-0600)] <colinclark> be it the channel or the list

[09:33:47 CST(-0600)] <anastasiac> will do

[09:33:55 CST(-0600)] <colinclark> And I think that in the cases where we do choose to write our own widget, which is totally cool, it's imperative that we're well informed

[09:34:00 CST(-0600)] <colinclark> that we've surveyed the others out there

[09:34:09 CST(-0600)] <colinclark> not just at the level of functionality, but knowing the design decisions they made

[09:34:22 CST(-0600)] <colinclark> i.e. have read the code and understand what went into them

[09:34:57 CST(-0600)] <colinclark> I'm done now

[09:35:32 CST(-0600)] <michelled>

[11:06:58 CST(-0600)] <anastasiac> michelled, I've issued a pull request for FLUID-4589 (#23), the caption controls refactoring. Should I move on FLUID-4598, the styling of the captions pop-up menu?

[11:15:03 CST(-0600)] <anastasiac> michelled, I'll move on to styling the caption menu popup

[11:15:20 CST(-0600)] <michelled> thx anastasiac - sounds good

[11:32:42 CST(-0600)] <michelled> colinclark: I just opened a pull request for the mammals demo - can you take a look at it please?

[11:32:55 CST(-0600)] <michelled> https://github.com/fluid-project/videoPlayer/pull/24

[11:33:01 CST(-0600)] <colinclark> probably not likely to get a review in today, michelled

[11:33:02 CST(-0600)] <colinclark>

[11:33:36 CST(-0600)] <michelled> ok, I'll bug Bosmon when he wakes up

[13:43:41 CST(-0600)] <michelled> cindyli: something's still wrong with my merge

[13:43:50 CST(-0600)] <michelled> the time interval tests are breaking

[13:43:56 CST(-0600)] <michelled> can you take a look when you get a chance?

[13:44:51 CST(-0600)] <michelled> anastasiac: your high fidelity branch doesn't merge cleanly - any chance you can merge master into it and push that?

[13:45:04 CST(-0600)] <anastasiac> absolutely!

[13:46:07 CST(-0600)] <cindyli> michelled: which test in what platform? it's a known issue that the integration test for interval component fails on IE9

[13:46:30 CST(-0600)] <michelled> it's the integration test but it's failing in FF

[13:46:34 CST(-0600)] <michelled> the master passes

[13:46:38 CST(-0600)] <cindyli> ok, i will take a look

[13:46:39 CST(-0600)] <michelled> it only fails in my branch

[13:46:43 CST(-0600)] <cindyli> i see

[13:50:09 CST(-0600)] <anastasiac> michelled: high-fidelity branch merged and pushed

[13:50:19 CST(-0600)] <michelled> thx

[13:54:55 CST(-0600)] <jhung> justin_o: i've updated some of the styling. Update when you have a chance. I'm going to work on disabled button styles now.

[13:55:20 CST(-0600)] <Justin_o> jhung: okay, thanks

[14:05:03 CST(-0600)] <michelled> anastasiac: I'm thinking that instead of changing the theme name from fl-videoPlayer-theme to fl-theme we should just get rid of the scoping for default styling

[14:05:23 CST(-0600)] <michelled> that way the video player will have some default colours even when a fluid theme is not present

[14:05:33 CST(-0600)] <anastasiac> ok, makes sense. Should I create a JIRA for that?

[14:05:46 CST(-0600)] <michelled> well, the theme name change is part of a current pull request

[14:05:55 CST(-0600)] <michelled> it seems like it should just happen there

[14:06:08 CST(-0600)] <michelled> https://github.com/fluid-project/videoPlayer/pull/23

[14:06:27 CST(-0600)] <anastasiac> gotcha. I'll make the change and push it up

[14:13:13 CST(-0600)] <anastasiac> michelled, fl-theme removed and pushed

[14:13:24 CST(-0600)] <michelled> thx

[14:15:55 CST(-0600)] <michelled> anastasiac: it looks like you changed the captions API in that pull request

[14:16:17 CST(-0600)] <anastasiac> yes, that was what Bosmon recommended

[14:17:30 CST(-0600)] <michelled> I guess it doesn't quite match up with the changes that will likely happen in the captionator branch

[14:18:57 CST(-0600)] <anastasiac> we'll have to sync those up

[14:19:09 CST(-0600)] <anastasiac> I know the idea behind the changes is the same: list the captions in an array

[14:19:40 CST(-0600)] <anastasiac> michelled, I'm sure alexn and I can work together to resolve that merge, whenever it happens

[14:21:46 CST(-0600)] <cindyli> michelled: the integration test for interval component has been fixed and pushed into your branch.

[14:21:54 CST(-0600)] <alexn1> this captions change is very challenging especially for me. Since once I change currentTrack for the key in the captions hash to an integer it would break my branch completely since controllers part would not work at all

[14:21:57 CST(-0600)] <michelled> thanks cindyli

[14:22:20 CST(-0600)] <cindyli> np

[14:22:26 CST(-0600)] <anastasiac> michelled, just realized I forgot to remove the theme name from the html - give me a sec

[14:22:37 CST(-0600)] <michelled> ok

[14:23:22 CST(-0600)] <michelled> alexn1: sounds like you and anastasiac should sync up now - perhaps we can make the API change once

[14:23:36 CST(-0600)] <alexn1> I was thinking about changing captions uispec. There is a high possibility that I would need to wait until videoControls work with the new schema first and only then apply it to my captionator branch.

[14:25:23 CST(-0600)] <anastasiac> michelled, I've pushed the html fl-theme change. And fyi, I've pushed the same changes to the high-fidelity branch

[14:25:38 CST(-0600)] <michelled> thx anastasiac

[14:25:52 CST(-0600)] <michelled> anastasiac: do you want to pair up with alexn1 to take a look at that API change?

[14:25:54 CST(-0600)] <anastasiac> alexn1, you should have a look at the form I used for the caption controls

[14:25:57 CST(-0600)] <anastasiac>

[14:25:58 CST(-0600)] <alexn1> by the way, I did not see any reply on my email about new caption schema which was sent to the list earlier today

[14:26:00 CST(-0600)] <michelled> I'd rather see it happen once

[14:26:11 CST(-0600)] <alexn1> so i have no idea on what was decided

[14:26:13 CST(-0600)] <anastasiac> alexn1, haven't seen the email yet - checking now

[14:26:41 CST(-0600)] <alexn1> unless you guys have decided on the schema already and I left out in the darkness

[14:27:34 CST(-0600)] <anastasiac> alexn1, no, I just made a minor change to convert the captions object into an array, as Bosmon had suggested - nothing drastic

[14:28:22 CST(-0600)] <anastasiac> I think I missed the part about pulling video and sources out of the model

[14:58:11 CST(-0600)] <colinclark> alexn1: I got half way through second response to you this afternoon and then was disrupted by a meeting

[14:58:38 CST(-0600)] <colinclark> In short, I have a quick opinion and a longer thought about this issue

[14:59:17 CST(-0600)] <colinclark> the short answer is that I see no reason why the options structure for the Video Player shouldn't be analogous to the markup of a media element

[14:59:47 CST(-0600)] <colinclark> In other words, nesting both "source" and "captions" as siblings within a "video" container

[15:00:41 CST(-0600)] <alexn1> which is the first example in my email

[15:00:46 CST(-0600)] <alexn1> I think...

[15:00:52 CST(-0600)] <colinclark> I think it was your second

[15:00:57 CST(-0600)] <colinclark> The longer thought involves musing on the nature of schemas and the fact that they're less fixed or important in a world of JSON where structure can easily be transformed to suit the needs of a particular implementation

[15:01:02 CST(-0600)] <colinclark> but I think I'll save that for another day

[15:01:59 CST(-0600)] <alexn1> *double checked yes it is the second example where we keep the same structure as we have today but just moving it outside of the model

[15:02:13 CST(-0600)]

[15:02:16 CST(-0600)] <colinclark> seems perfectly reasonable

[15:03:06 CST(-0600)] <colinclark> and then the model will store an index into the captions array as its current caption state

[15:03:19 CST(-0600)] <colinclark> Can anyone think of why this is not a reasonable enough approach?

[15:03:38 CST(-0600)] <alexn1> which would be the only one thing other subcomponents will be listening to

[15:04:56 CST(-0600)] <anastasiac> when we add transcripts and audio descriptions, they'd become siblings of captions?

[15:06:10 CST(-0600)] <anastasiac> model will have "currentCaption" and "currentTranscript" etc

[15:06:11 CST(-0600)] <alexn1> colinclark: I totally agree with this approach unless there is some completely weird case where user wants to modify captions dynamically during the lifetime of the component. Like having a video on the screen and then uploading or modifying captions right on the page.

[15:06:50 CST(-0600)] <colinclark> anastasiac: I guess that depends on whether or not the transcripts end up being distinct from the captions (in aggregate)

[15:07:10 CST(-0600)] <anastasiac> ah, good question

[15:07:16 CST(-0600)] <colinclark> If transcripts do end up taking a first class form, then likely that is the case, yes

[15:07:50 CST(-0600)] <colinclark> alexn1: I'm pretty sure any use case that involves dynamically modifying captions would be pretty far out

[15:07:56 CST(-0600)] <colinclark> as in, "far out, dude"

[15:07:56 CST(-0600)] <anastasiac> audio descriptions are obviously their own beast

[15:08:11 CST(-0600)] <colinclark> anastasiac: I wonder if it is so obvious

[15:08:13 CST(-0600)] <colinclark> In one form, yes

[15:08:21 CST(-0600)] <colinclark> Like if they're a recording of someone speaking

[15:08:31 CST(-0600)] <colinclark> I can actually imagine synthesized video descriptions

[15:08:50 CST(-0600)] <colinclark> where we use something like Speak.js to self-voice "captions"

[15:09:06 CST(-0600)] <colinclark> i.e. blobs of text that cover an interval of time

[15:09:13 CST(-0600)] <colinclark> Some Day

[15:09:23 CST(-0600)] <Bosmon> Ah, it's all happening

[15:09:31 CST(-0600)] <colinclark> oh hello

[15:09:40 CST(-0600)] <colinclark> what's new?

[15:09:45 CST(-0600)] <alexn1> colinclark: haha sure. I was just thinking about the caption creator who creates different versions of caption files on the fly since he wants to get the best captions there…

[15:09:52 CST(-0600)] <Bosmon> I finally worked through enough emails to realise there was a discussion going on in the channel

[15:09:56 CST(-0600)] <colinclark> lol

[15:10:15 CST(-0600)] <colinclark> alexn1: There's also the use case of real-time captioning

[15:10:22 CST(-0600)] <colinclark> but I think it's solved by a very different means anyway

[15:10:35 CST(-0600)] <cindyli> michelled: i just sent a pull request (https://github.com/fluid-project/videoPlayer/pull/25) to fix the interval component's integration test in IE9. only 2 lines are changed in the pull request. Could you review it?

[15:10:45 CST(-0600)] <Bosmon> It looks like anastasiac has lighted upon the point I was going to make, that all the suggestions in emails so far have an options structure which has lost a bit of information, the fact that "currentTrack" used to be inside the "captions" structure

[15:11:22 CST(-0600)] <colinclark> I presume you mean "lost in a good way"

[15:11:35 CST(-0600)] <Bosmon> Well, not entirely in a good way

[15:11:59 CST(-0600)] <Bosmon> To me, it isn't clear now that "track" refers to a "captions track"

[15:12:52 CST(-0600)] <colinclark> I'm not sure what that means

[15:13:05 CST(-0600)] <colinclark> Certainly there's some vague notion of a category of "tracks"

[15:13:14 CST(-0600)] <colinclark> hence the HTML5 spec's use of the <track> tag

[15:13:25 CST(-0600)] <colinclark> but I think they're fairly distinct in terms of their nature

[15:13:49 CST(-0600)] <colinclark> so what are you saying, Bosmon? I'm sure I'm just not quite understanding

[15:14:10 CST(-0600)] <Bosmon> The former structure used to read like this:

[15:14:18 CST(-0600)] <Bosmon> captions: {

[15:14:22 CST(-0600)] <Bosmon> ....

[15:14:27 CST(-0600)] <Bosmon> currentTrack

[15:14:29 CST(-0600)] <Bosmon> }

[15:14:35 CST(-0600)] <Bosmon> Within the model

[15:14:52 CST(-0600)] <alexn1> yup

[15:15:24 CST(-0600)] <Bosmon> In the new model, as well as pulling out the "non-model" material out of model, "currentTrack" has also been pulled up one level within the model out of "captions"

[15:15:26 CST(-0600)] <alexn1> captions: { sources: {}, currentTrack: something }

[15:15:34 CST(-0600)] <Bosmon> I wanted to confirm that we thought this loss of information was reasonable

[15:15:59 CST(-0600)] <Bosmon> Since at least to me, it isn't clear that the model state named "currentTrack" specifically refers to captions

[15:16:17 CST(-0600)] <alexn1> Bosmon: we were thinking to rename it to currentCaption

[15:16:30 CST(-0600)] <alexn1> since there might be currentAudioTrack

[15:16:34 CST(-0600)] <Bosmon> colinclark - looking at the HTML5 spec, it seems that the track element is indeed not specific to captions, "This element is used to specify subtitles, caption files or other files containing text, that should be visible when the media is playing."

[15:16:42 CST(-0600)] <Bosmon> So I am not clear what your confusion is about

[15:16:46 CST(-0600)] <Bosmon> Can you explain your confusion?

[15:16:58 CST(-0600)] <Bosmon> alexn1 - sounds like a good suggestion

[15:17:17 CST(-0600)] <colinclark> whatevs

[15:17:24 CST(-0600)] <colinclark> sounds like you guys have it under control

[15:17:32 CST(-0600)] <colinclark> i'm crawling back under my rock

[15:18:03 CST(-0600)] <Bosmon> Please excuse me for quoting from a w3schools page...

[15:18:09 CST(-0600)] <Bosmon> I didn't mean to do it!

[15:18:47 CST(-0600)] <colinclark> nice job

[15:19:00 CST(-0600)] <colinclark> "The track element allows authors to specify explicit external timed text tracks for media elements. It does not represent anything on its own."

[15:19:07 CST(-0600)] <colinclark> that's what the W3C spec says

[15:19:20 CST(-0600)] <colinclark> much more 733t to quote specs than w3schools

[15:20:08 CST(-0600)] <Bosmon> It is possible more than one track might be active at a time?

[15:20:21 CST(-0600)] <colinclark> for sure

[15:20:27 CST(-0600)] <colinclark> even of the same type

[15:20:27 CST(-0600)] <Bosmon> ok

[15:20:45 CST(-0600)] <colinclark> we most definitely will find ourselves in a situation where we support multiple simultaneous caption tracks

[15:21:32 CST(-0600)] <Bosmon> Ok

[15:21:33 CST(-0600)] <alexn1> colinclark: funny enough but I talked to jameswy about it and he confirmed negative about multiple simultaneous caption tracks

[15:21:40 CST(-0600)] <Bosmon> In that case I make a different suggestion

[15:22:00 CST(-0600)] <colinclark> alexn1: jameswy was likely talking about now

[15:22:05 CST(-0600)] <Bosmon> That we revert the name back to "currentTrack" but have its value to be one or more EL paths into the options structure which refer to tracks

[15:22:17 CST(-0600)] <Bosmon> For example, a possible value for currentTrack might be "captions.0"

[15:22:19 CST(-0600)] <colinclark> we will undoubtedly support multiple simultaneous caption tracks some day, alexn1

[15:22:32 CST(-0600)] <Bosmon> Or alternatively, ["captions.0", "audioDescriptions.1"]

[15:22:35 CST(-0600)] <alexn1> colinclark: ok awesome!

[15:23:24 CST(-0600)] <colinclark> Bosmon: I guess the point I was getting at earlier is that the generic notion of a track may not actually be practically useful

[15:23:47 CST(-0600)] <colinclark> and that a concrete distinction between, say, captions and video descriptions is actually useful

[15:24:36 CST(-0600)] <Bosmon> Do you think that that disctinction is made suitably, in what I just proposed?

[15:25:01 CST(-0600)] <colinclark> not really

[15:25:21 CST(-0600)] <Bosmon> How could it be improved?

[15:25:39 CST(-0600)] <colinclark> By what means could a thing which is interested in, say, audio descriptions, be informed of its need to do something when that list of current tracks changes?

[15:26:17 CST(-0600)] <Bosmon> Ok... so, we need to make it more changeApplier friendly

[15:26:41 CST(-0600)] <Bosmon> model: {

[15:26:58 CST(-0600)] <Bosmon> currentTrack: {

[15:27:02 CST(-0600)] <colinclark> yeah

[15:27:03 CST(-0600)] <Bosmon> captions: 0

[15:27:07 CST(-0600)] <Bosmon> }

[15:27:08 CST(-0600)] <colinclark> that looks about right

[15:27:22 CST(-0600)] <alexn1> almost captions: [0]

[15:27:25 CST(-0600)] <Bosmon> Which just leaves the name of "currentTrack" up for grabs

[15:27:34 CST(-0600)] <colinclark> "currentTracks," I suppose

[15:27:35 CST(-0600)] <alexn1> if we want to support multiple concurrent captions

[15:27:41 CST(-0600)] <colinclark> activeTracks

[15:27:45 CST(-0600)] <colinclark> something to that effect

[15:28:13 CST(-0600)] <Bosmon> It sounded like you werent completely happy with the "generic notion of a track" - but was that only to the extent that we couldn't address activity of different kinds of track separately?

[15:28:35 CST(-0600)] <colinclark> I suppose my unhappiness was largely abstract

[15:28:39 CST(-0600)] <Bosmon> OK, so we have model: {

[15:28:44 CST(-0600)] <Bosmon> currentTracks: {

[15:28:50 CST(-0600)] <Bosmon> captions: [0]

[15:28:53 CST(-0600)] <Bosmon> }

[15:28:54 CST(-0600)] <Bosmon> }

[15:28:59 CST(-0600)] <colinclark> it seems quite sufficient

[15:29:03 CST(-0600)] <Bosmon> cool

[15:29:13 CST(-0600)] <alexn1> so if we have currentAudioTrack does it go inside of currentTracks ?

[15:29:16 CST(-0600)] <colinclark> and we can imagine that the ChangeApplier will allow the "thing that does stuff" with a given type of track...

[15:29:27 CST(-0600)] <Bosmon> Yes

[15:29:28 CST(-0600)] <colinclark> to be completely decoupled, save for listening to changes at a particular model path

[15:29:37 CST(-0600)] <Bosmon> It will allow a component to listen to currentTracks.captions.* etc.

[15:29:51 CST(-0600)] <colinclark> exactly, yes

[15:30:18 CST(-0600)] <anastasiac> so when we support multiples of everything, it might look like this?

[15:30:20 CST(-0600)] <anastasiac> currentTracks: {

[15:30:20 CST(-0600)] <anastasiac> captions: [0, 2],

[15:30:20 CST(-0600)] <anastasiac> transcripts[1],

[15:30:20 CST(-0600)] <anastasiac> audioDescriptions [0]

[15:30:21 CST(-0600)] <anastasiac> }

[15:30:28 CST(-0600)] <colinclark> yup

[15:30:32 CST(-0600)] <anastasiac> cool

[15:31:24 CST(-0600)] <colinclark> So I guess there's the question of how this actually gets done now

[15:31:37 CST(-0600)] <colinclark> we've got, what, two conflicting implementations now in two different branches?

[15:32:00 CST(-0600)] <colinclark> and anastasiac's point that this will change several points within the code base

[15:33:16 CST(-0600)] <alexn1> it is a pretty big change which would take effect on almost every single subcomponent of the videoPlayer

[15:34:15 CST(-0600)] <colinclark> So is this a good opportunity to file a JIRA, create a new branch, and pair program on a working impl?

[15:34:57 CST(-0600)] <anastasiac> it probably makes sense to make the change to master, and then merge that change into our individual branches

[15:35:08 CST(-0600)] <anastasiac> I think

[15:35:17 CST(-0600)] <anastasiac> but I'm still thinking, so I could be wrong

[15:35:18 CST(-0600)] <Bosmon> Well, another option is to do it the other way round

[15:35:24 CST(-0600)] <alexn1> or maybe make a branch then merge it to the master and then merge master to our branches

[15:35:26 CST(-0600)] <Bosmon> TO make the new work an attempt to merge the branches

[15:36:25 CST(-0600)] <anastasiac> Bosmon, you mean merge the branches, and them merge the single merged branch back into master?

[15:36:41 CST(-0600)] <Bosmon> anastasiac - yes, that's what I mean

[15:36:54 CST(-0600)] <anastasiac> hm

[15:36:54 CST(-0600)] <Bosmon> As alexn1 says, there may be various intermediate operations of keeping the branches up with master mixed in there

[15:37:06 CST(-0600)] <Bosmon> But it sounds like "fixing the model" and "reconciling the branches" is work that should be done at the same time

[15:37:16 CST(-0600)] <Bosmon> Otherwise it seems to me that there will be a fair amount of duplicated work

[15:37:36 CST(-0600)] <colinclark> Bosmon: The question is how keen we'll be to review one big branch

[15:37:41 CST(-0600)] <colinclark> with many apparently unrelated changes in them

[15:37:43 CST(-0600)] <anastasiac> yes, but by merging three major changes into a single branch, there's a fair amount of code review

[15:37:59 CST(-0600)] <anastasiac> michelled can speak to how hard that is

[15:38:19 CST(-0600)] <colinclark> we have been trying to encourage a model whereby we take "baby steps"

[15:38:21 CST(-0600)] <Bosmon> I guess I'd prefer to review one big branch that reflected the way we wanted things to be, rather than review two branches that were individually some way off

[15:38:42 CST(-0600)] <Bosmon> But I haven't seen the "other branch"

[15:38:47 CST(-0600)] <anastasiac> I think Bosmon's volunteering to review the uber-branch

[15:38:51 CST(-0600)] <Bosmon> Sure, I'll review it

[15:39:13 CST(-0600)] <colinclark> Cool, problem solved

[15:39:27 CST(-0600)] <colinclark> But don't let this serve as a precedent, please

[15:39:41 CST(-0600)] <michelled> I haven't been keeping up with this conversation but I just wanted to say that we need to be careful about being able to deliver

[15:39:57 CST(-0600)] <michelled> if uber branch means we don't know when it'll get done then we should avoid it

[15:40:02 CST(-0600)] <colinclark> If you don't know what you're doing very, very clearly, you need to break it down into smaller chunks

[15:40:04 CST(-0600)] <colinclark> michelled: ha!

[15:40:09 CST(-0600)] <colinclark> I guess I owe you a beer

[15:40:22 CST(-0600)] <colinclark> since we just said the same thing

[15:40:23 CST(-0600)] <michelled> I don't know why but I'll take it

[15:40:30 CST(-0600)] <michelled> ah, good

[15:40:34 CST(-0600)] <colinclark> you know, like "jinx, you owe me a beer"

[15:40:49 CST(-0600)] <michelled> I like it better when you owe me a beer

[15:41:05 CST(-0600)] <Bosmon> Yes - that's good advice

[15:41:23 CST(-0600)] <colinclark> I owe you all a beer if we get this freaking demo looking hot in the next 10 days

[15:41:25 CST(-0600)] <Bosmon> I think that this work is justifiable, since the model change work is in theory only a small advance on the two separate branches

[15:41:50 CST(-0600)] <Bosmon> And the two branches have been separately quite well reviewed already

[15:43:06 CST(-0600)] <alexn1> well not sure about the branches but there are lots of code being involved. for example VideoPlayer_media.js this file did not have too many changes recently but it will be changed a lot. and there are lots of places - especially test files

[15:43:50 CST(-0600)] <alexn1> saying not to scare people, just to remind that there will be lots of changes outside of my and anastasiac branches since almost everything is using current model schema

[15:44:35 CST(-0600)] <Bosmon> I think we can handle it

[15:44:45 CST(-0600)] <alexn1> I think the same

[15:44:54 CST(-0600)] <anastasiac> yes, the model changes will require changes in just about everything. We'll just need to be careful

[15:45:07 CST(-0600)] <Bosmon> Luckily... we have LOTS OF TEST CASES!

[15:45:30 CST(-0600)] <anastasiac> And of course, we'll update the test cases before we modify the code

[15:47:05 CST(-0600)] <colinclark> so it sounds like alexn1 and anastasiac are going to pair up

[15:47:07 CST(-0600)] <colinclark> and get this done

[15:48:00 CST(-0600)] <anastasiac> sounds good. We should probably work in alexn1's branch, as opposed to mine, since I'm only here one more day

[15:48:23 CST(-0600)] <alexn1> sounds exciting and at the same time adventurous

[15:50:41 CST(-0600)] <Bosmon> Well, a mini-adventure

[15:50:48 CST(-0600)] <Bosmon> We are just tidying up a bit of model structure : P

[15:54:38 CST(-0600)] <alexn1> we should be fine

[15:54:53 CST(-0600)] <anastasiac> I'm going to create a JIRA for the model-restructuring work, and and capture these decisions. The uber-branch will use all three JIRA numbers in it.

[15:56:55 CST(-0600)] <Bosmon> I'd prefer that the name of the new branch was just named after this new JIRA number : P

[15:57:05 CST(-0600)] <Bosmon> I found myself a bit offput by michelled's branch that was named after 6 JIRAs

[15:57:16 CST(-0600)] <anastasiac> Bosmon, we can do that

[15:57:22 CST(-0600)] <Bosmon> Luckily I didn't have to type its name more than a couple of times

[15:57:41 CST(-0600)] <colinclark> Bosmon: Is there a declarative way to specify a prototree in the options of a renderer component?

[15:57:44 CST(-0600)] <colinclark> I'm sure there must be

[15:57:48 CST(-0600)] <Bosmon> colinclark - yes

[15:57:55 CST(-0600)] <Bosmon> You can see it in yura's demo file frmo Wednesday

[15:58:04 CST(-0600)] <alexn1> Bosmon: you should start using git autocompletion

[15:58:11 CST(-0600)] <Bosmon> You just write it as the option named "protoTree"

[15:58:19 CST(-0600)] <colinclark> yes, that's what I had thought

[15:58:39 CST(-0600)] <Bosmon> Surely you are not contemplating another excursion with this thing which should be burned to the ground? : P

[15:58:52 CST(-0600)] <Bosmon> alexn1 - I'm not 100% sure how I would install that under windows

[15:59:27 CST(-0600)] <alexn1> I think you can if you use cygwin or git bash

[15:59:39 CST(-0600)] <Bosmon> ok

[15:59:42 CST(-0600)] <Bosmon> I do

[15:59:56 CST(-0600)] <Bosmon> But I remember the last time I messed with that stuff, I lost a full day figuring out how to get cut and paste working

[16:00:53 CST(-0600)] <anastasiac> Bosmon, alexn1, colinclark: http://issues.fluidproject.org/browse/FLUID-4608 Please have a look and check if I've captured things properly

[16:01:23 CST(-0600)] <colinclark> anastasiac: is there a reason you placed your tree within a produceTree function here? https://github.com/fluid-project/videoPlayer/pull/23/files#L4R586

[16:02:45 CST(-0600)] <anastasiac> good point, colinclark - that's all declarative. It could be put in the options

[16:03:33 CST(-0600)] <colinclark> Should we have some ARIA of some kind for our menu?

[16:03:51 CST(-0600)] <colinclark> and, indeed, for the button that has the menu attached to it?

[16:04:07 CST(-0600)] <anastasiac> ah, yes, we should Are you putting these comments on the pull request?

[16:04:52 CST(-0600)] <michelled> Bosmon: I was trying to make a point with that branch with 6 JIRA names I was hoping people would be offput

[16:05:19 CST(-0600)] <Bosmon> Well, there's no reason to deliberately offput people

[16:05:35 CST(-0600)] <Bosmon> You could have offput them more by adding the further 6 JIRAs that the branch addressed : P

[16:05:57 CST(-0600)] <michelled> yes, and honestly the issue was one of not getting review early enough to get the branches in early

[16:06:12 CST(-0600)] <michelled> that was a yes to not off-putting people

[16:06:34 CST(-0600)] <Bosmon> colinclark - anastasiac's reason is probably the EL construction operation here: "

[16:06:34 CST(-0600)] <Bosmon> + controlledBy: that.options.modelPath + ".list","

[16:06:55 CST(-0600)] <colinclark> anastasiac: I was more attempting to have a conversation than doing a code review

[16:06:56 CST(-0600)] <Bosmon> Although in theory that could be made to go away

[16:07:08 CST(-0600)] <colinclark> but I certainly can put comments onto the pull request

[16:07:38 CST(-0600)] <anastasiac> colinclark, sorry - michelled just pulled me off all things VideoPlayer to help with the IDLH, so I don't want to lose track of these excellent points, that's all

[16:07:54 CST(-0600)] <colinclark> But I will admit that I'm perplexed how there even is a pull request if we haven't made basic consideration of what ARIA is appropriate here

[16:08:17 CST(-0600)] <anastasiac> that was an oversight on my part, I apologize

[16:08:19 CST(-0600)] <colinclark> especially after our conversation yesterday evening about looking at what others have done and considering why

[16:08:28 CST(-0600)] <colinclark> I'm just completely confused

[16:09:13 CST(-0600)] <colinclark> Why are we making a Video Player?

[16:09:21 CST(-0600)] <colinclark> If not to make one that is wildly accessible?

[16:10:28 CST(-0600)] <colinclark> "Wildly accessible" is our bread and butter

[16:10:32 CST(-0600)] <colinclark> it's why we exist

[16:11:08 CST(-0600)] <Bosmon> Did Tuesday's design discussion on keyboard a11y for the videoPlayer come to a close?

[16:13:02 CST(-0600)] <colinclark> I believe it needed a bit more discussion before we had definitive next steps

[16:13:11 CST(-0600)] <colinclark> we can check in with James about it at some point

[16:13:14 CST(-0600)] <Bosmon> cool

[16:13:35 CST(-0600)] <Bosmon> Is the plan that we schedule that work to come after the merging of the "uber branch"?

[16:13:55 CST(-0600)] <Bosmon> I assume whatever keyboard mapping the two branches have, they do it the same way

[16:14:58 CST(-0600)] <colinclark> for sure

[16:15:07 CST(-0600)] <colinclark> we need to untangle all these things a bit

[16:15:41 CST(-0600)] <colinclark> We're not doing a good enough job of doing one thing at a time and getting it done and in

[16:17:22 CST(-0600)] <Bosmon> Well, I have to take some of the blame for that

[16:17:41 CST(-0600)] <Bosmon> I could have OK'ed alexn's branch when it no longer had direct implementation comments

[16:17:56 CST(-0600)] <Bosmon> But I felt I was unwilling to have it go in with its model structured inappropriately

[16:19:08 CST(-0600)] <Bosmon> I think it does actually have a bug though... in that the code does seem to have the model material expected at two different places in the options structure

[16:24:59 CST(-0600)] <michelled> anastasiac: please feel free to have conversations about the code I just wanted to make sure the james and jess get what they need in terms of adding to the ILDH

[16:38:38 CST(-0600)] <anastasiac> colinclark, I'm refreshing my memory on the development process for the handbook. We have the mediawiki instance in github, with master and development branches. We obviously have a deployment of master at handbook.floeproject.org. I recall that dev.handbook.floeproject.org is a deployment of the development branch - do you recall if that's correct?

[16:39:01 CST(-0600)] <anastasiac> and if so, do you recall the process for getting dev and/or master redeployed?

[16:40:59 CST(-0600)] <anastasiac> I don't remember us having an automated process, but I could be wrong. Aaron was helping us at that stage, I believe

[16:46:32 CST(-0600)] <colinclark> It likely requires shell access to the box

[16:46:40 CST(-0600)] <colinclark> and a "git pull" or two

[16:47:45 CST(-0600)] <anastasiac> yes, that's what avtar was just theorizing. Ok, I'll talk to james and jess tomorrow about what, exactly, they need, and we'll work out the details of the process

[16:47:53 CST(-0600)] <anastasiac> thanks, colinclark