[08:12:57 CST(-0600)] <yzen> Justin_o, cindyli1, jhung good morning. do you have time now to chat about UIO ?

[08:13:12 CST(-0600)] <cindyli1> sure, yzen

[08:13:14 CST(-0600)] <Justin_o> yzen: sure

[08:15:02 CST(-0600)] <yzen> cindyli1: Justin_o ill skype you in

[08:15:09 CST(-0600)] <cindyli1> ok, yzen

[08:15:37 CST(-0600)] <Justin_o> yzen: okay.. just logging in now

[08:17:00 CST(-0600)] <jhung> gimme a sec yzen

[08:17:29 CST(-0600)] <yzen> jhung: let me know ill skype you in then

[10:36:57 CST(-0600)] <yzen> fluid-everyone: hi sorry my battery is dying right now, Ill give an update here. Cindy, Jon, Justin and I met today and we have our initial iteration steps defined: http://wiki.fluidproject.org/display/fluid/User+Interface+Options+Iteration+Planning . Ill make JIRA's by the end of the day. Otherwise investigating GPII production failure from A5 test cases

[12:35:21 CST(-0600)] <jhung> justin_o, anastasiac, michelled: I just found 2 bugs that affect Windows only, and it can't be reproduced inside a VM.

[12:35:41 CST(-0600)] <Justin_o> jhung: really

[12:35:43 CST(-0600)] <anastasiac> can't be reproduced in a VM? well, that's going to make debugging difficult

[12:35:57 CST(-0600)] <Justin_o> jhung: what are the issues

[12:36:06 CST(-0600)] <jhung> yeah. I'm going to check on a Win7 machine now (I'm on Win8).

[12:36:14 CST(-0600)] <jhung> Keyboard scrubbing is broken-ish.

[12:36:46 CST(-0600)] <jhung> In FF, you scrub about 5 seconds of video and then it loses focus.

[12:37:13 CST(-0600)] <jhung> In Chrome, you scrub a few seconds, the video turns blank and playing the video starts at the beginning.

[12:37:31 CST(-0600)] <jhung> None of this happens on Mac, or Windows 7 in VM.

[12:37:33 CST(-0600)] <Justin_o> jhung: so could be related to Win 8?

[12:37:44 CST(-0600)] <jhung> Yeah. I'm going to check a Win 7 machine now.

[12:37:58 CST(-0600)] <Justin_o> jhung: i have a win 8 vm here at home.. i'll try to reproduce it there

[12:38:06 CST(-0600)] <jhung> okay.

[12:38:24 CST(-0600)] <Justin_o> jhung: is this scrubbing while the video is playing or paused?

[12:39:01 CST(-0600)] <jhung> Paused in both cases.

[12:39:05 CST(-0600)] <jhung> Using keyboard to scrub.

[12:39:17 CST(-0600)] <Justin_o> jhung: okay… i'll go check now

[12:39:33 CST(-0600)] <jhung> In Chrome, the blank image / video restart only happens if you've played the video a little bit first, and then attempted to scrub using the keyboard.

[12:47:04 CST(-0600)] <Justin_o> jhung: i couldn't reproduce the issue, but i'll try with the instructions you just gave

[12:48:43 CST(-0600)] <jhung> justin_o: keyboard scrubbing works fine in FF on Win 7. Checking chrome now.

[12:49:04 CST(-0600)] <Justin_o> jhung: i still couldn't reproduce it, but will try restarting my vm and trying again

[12:49:18 CST(-0600)] <Justin_o> jhung: could it have been something to do with the video buffering?

[12:50:27 CST(-0600)] <jhung> justin_o: possibly. Seems okay in Win 7.

[12:52:27 CST(-0600)] <Justin_o> jhung: okay after restarting the vm i was able to reproduce the FF issue, but still couldn't reproduce the chrome one.. was there a specific point you had to play to before you paused and started scrubbing?

[12:53:20 CST(-0600)] <jhung> I just played the video until I heard "Eeny". Paused it. Pressed tab 2 to focus scrubber, then pressed and held the right arrow.

[12:54:32 CST(-0600)] <Justin_o> jhung: can't reproduce that one still

[12:54:46 CST(-0600)] <jhung> okay.

[12:55:46 CST(-0600)] <jhung> I guess we'll test with a Win 7 and Win 8 machine in the office when we get a chance.

[14:04:43 CST(-0600)] <cindyli1> hi, Bosmon

[14:04:57 CST(-0600)] <Bosmon> Hi cindyli1

[14:05:13 CST(-0600)] <cindyli1> do you have a minute to take a look on my implementation of the showhide grade?

[14:05:15 CST(-0600)] <cindyli1> https://github.com/cindyli/videoPlayer/blob/FLUID-4853/js/VideoPlayer_showHide.js

[14:06:56 CST(-0600)] <cindyli1> the unit test that shows how to use it: https://github.com/cindyli/videoPlayer/blob/FLUID-4853/tests/js/VideoPlayerShowHideTests.js

[14:07:21 CST(-0600)] <cindyli1> Bosmon: ^

[14:08:13 CST(-0600)] <Bosmon> Hi cindyli1 - it's interesting that it only works for the overall container of the component

[14:08:21 CST(-0600)] <Bosmon> Rather than, in addition, being able to use any selector held in the DOM binder

[14:08:31 CST(-0600)] <Bosmon> Also, you should use a more robust means of composing EL paths

[14:08:38 CST(-0600)] <cindyli1> I did it that way after a chat with michelled

[14:08:53 CST(-0600)] <Bosmon> Well, chat again

[14:09:33 CST(-0600)] <Bosmon> The fact that "modelCollectionName" is hard-coded is also peculiar

[14:09:34 CST(-0600)] <cindyli1> she brought up a good point that if one part of a component needs to be show/hidden at a different timing with different logic, it's worthwhile to make it a separate component

[14:09:49 CST(-0600)] <cindyli1> makes good sense, i think

[14:09:52 CST(-0600)] <Bosmon> cindyli1 - I don't think that's true in general

[14:10:15 CST(-0600)] <Bosmon> There are many cases where, for example, a component has been rendered using the renderer, where things accessible via selectors are not separate components and never will be

[14:10:29 CST(-0600)] <Bosmon> So it doesn't seem reasonable to force the user to make something into a component just so it can be shown/hidden : P

[14:10:59 CST(-0600)] <Bosmon> So, I think about 3 issues in total

[14:11:07 CST(-0600)] <Bosmon> You can take a look in DataBinding.js for functions like fluid.pathUtil.composePath

[14:11:16 CST(-0600)] <michelled> Bosmon: that was cindyli1's opinion too - it was me who felt it would be more clear to have hide/show be in charge of one thing

[14:11:40 CST(-0600)] <Bosmon> In general we don't like to just slap strings together to make EL paths

[14:12:13 CST(-0600)] <cindyli1> ok, what's the more robust way to make EL paths then, might be a silly question.

[14:12:21 CST(-0600)] <Bosmon> cindyli1 - I referred you to a utility just then

[14:12:42 CST(-0600)] <cindyli1> ya, the indirectReader, Bosmon

[14:12:43 CST(-0600)] <Bosmon> michelled - it seems to kill a lot of the value behind having the DOM binder, if we don't accept it can bind onto things which are not components

[14:12:50 CST(-0600)] <colinclark> hi GUYZ!

[14:12:54 CST(-0600)] <colinclark> whatcha talking about?

[14:13:03 CST(-0600)] <Bosmon> cindyli1 - [13:11] <Bosmon> You can take a look in DataBinding.js for functions like fluid.pathUtil.composePath

[14:13:24 CST(-0600)] <cindyli1> oh, thanks, didn't see that

[14:15:54 CST(-0600)] <cindyli1> colinclark: we are talking about the implementation of a showHide grade component that can be attached onto any video player component to perform the show/hide functionality by simply firing a model change request

[14:15:56 CST(-0600)] <michelled> Bosmon: the code that cindyli1 showed me earlier had two arrays that she needed to keep coordinated - one of selectors and one of the parts of the model that she was interested in. it seemed to me to be a lot of work for the hide/show component

[14:16:58 CST(-0600)] <michelled> colinclark: showHide is actually a pattern we continually see in things we build

[14:17:22 CST(-0600)] <colinclark> ok

[14:17:28 CST(-0600)] <colinclark> that seems fairly prudent to do

[14:17:32 CST(-0600)] <colinclark> how will you do it?

[14:17:33 CST(-0600)] <michelled> so this component should be generally useful

[14:17:35 CST(-0600)] <colinclark> seems pretty interesting

[14:20:23 CST(-0600)] <michelled> colinclark: Bosmon and I talked about it a little the other day and I commented on cindyli1's pull request: https://github.com/fluid-project/videoPlayer/pull/109#issuecomment-12245984

[14:20:38 CST(-0600)] <michelled> but I'm not convinced I understood the full picture

[14:20:48 CST(-0600)] <michelled> so I'm curious to hear what Bosmon and cindyli1 talked about

[14:21:04 CST(-0600)] <colinclark> Can you describe the full picture to me, michelled?

[14:21:20 CST(-0600)] <colinclark> That is, what aspects of it that are on your mind?

[14:23:18 CST(-0600)] <michelled> well, I guess foremost is how we use hideShow - I thought it would be used on each thing we hide and show, but it sounds like Bosmon and cindyli1 see this differently and I'm trying to understand it.

[14:23:40 CST(-0600)] <cindyli1> Bosmon: does this look more robust in terms of composing EL paths - https://github.com/cindyli/videoPlayer/commit/b24f85d7be0712ed49edcdf1688194969a4b5cde

[14:23:42 CST(-0600)] <michelled> Bosmon, cindyli1: are you envisioning a single hideShow for the videoPlayer that would be used to hide and show different things?

[14:23:57 CST(-0600)] <cindyli1> yes, michelled

[14:25:08 CST(-0600)] <michelled> what's the API for using it?

[14:25:12 CST(-0600)] <cindyli1> the way I'm thinking is, since each component on the video player tree is unique, we can fire the model request by providing a path to the showHide grade. that path is the component nickname or this sort

[14:26:24 CST(-0600)] <michelled> what does the model look like?

[14:26:30 CST(-0600)] <michelled> and what sort of change do you make?

[14:26:48 CST(-0600)] <cindyli1> the only trick to use it is that, when this grade is attached onto a component, the component needs to define an option which is the path, or the nickname of that component

[14:27:04 CST(-0600)] <cindyli1> my unit test might explain better: https://github.com/cindyli/videoPlayer/blob/FLUID-4853/tests/js/VideoPlayerShowHideTests.js

[14:27:36 CST(-0600)] <cindyli1> seems i'm missing some messages, i hear the new msg alerting sound, but no new msg coming up on the screen

[14:27:42 CST(-0600)] <cindyli1> let me open the channel backup

[14:28:26 CST(-0600)] <Bosmon> Hi cindyli1 - that looks better, yes

[14:29:09 CST(-0600)] <cindyli1> cool, Bosmon and michelled, now the only issue left is whether we should show/hide by selectors

[14:29:18 CST(-0600)] <Bosmon> michelled - in response to your earlier comment about it being a lot of work - it's certainly less work than having to derive new Fluid components for every one of the entries that were in that table

[14:37:50 CST(-0600)] <cindyli1> michelled: do you have a response to Bosmon's comments?

[14:38:06 CST(-0600)] <cindyli1> come on, guys, we need to make a decision

[14:38:11 CST(-0600)] <michelled> sorry, yzen and I are looking at a pull request

[14:38:17 CST(-0600)] <cindyli1> oh, well

[14:49:00 CST(-0600)] <michelled> Bosmon: in your pullrequst for FLUID-4886, you removed 'fetchTemplate' from jqUnit - is that because we no longer use it?

[14:49:40 CST(-0600)] <Bosmon> michelled - we have never used it, to my knowledge

[14:50:13 CST(-0600)] <Bosmon> And the purpose for having it in the testing framework has always been fundamentally obscure

[14:50:50 CST(-0600)] <Bosmon> Are you guys Skyping together?

[14:52:06 CST(-0600)] <michelled> yes, we are sky ping

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

[14:53:05 CST(-0600)] <michelled> so, it looks to me, Bosmon, that you've removed the (annoying to be sure) global namespace pollution that Qunit has

[14:53:15 CST(-0600)] <Bosmon> michelled - that's right

[14:53:29 CST(-0600)] <michelled> but what that means is that if someone uses jqUnit, they can't expect to have the Qunit API available

[14:53:37 CST(-0600)] <Bosmon> It is available under QUnit.*

[14:53:45 CST(-0600)] <Bosmon> Otherwise jqUnit couldn't work!

[15:05:24 CST(-0600)] <michelled> Bosmon: I noticed that you've added a 'sortTree' function "to facilitate comparison with deepEq". We used to use Qunit's deepEqual - are we no longer using that?

[15:06:02 CST(-0600)] <Bosmon> michelled - if you are looking at the most recent version of the pull, you can see that we are now forwarding to QUnit's new "propEqual" method

[15:06:15 CST(-0600)] <Bosmon> Although the method still has the same name as far as jqUnit is concerned

[15:06:39 CST(-0600)] <Bosmon> The usage of sortTree remains unchanged - it is a piece of preprocessing which is done before sending the tree to whatever equality comparison method you are using

[15:07:02 CST(-0600)] <Bosmon> Which, ironically, is all that QUnit's own "propEqual" does........

[15:07:42 CST(-0600)] <michelled> hmmm… I don't see 'sortTree' in the master repo - am I missing something?

[15:08:21 CST(-0600)] <Bosmon> These were all taken from the now destroyed files TestUtils.js

[15:08:40 CST(-0600)] <Bosmon> I took the opportunity to fold these into the main implementation given it now seemed ok to give jqUnit a dependence on Fluid.js

[15:08:57 CST(-0600)] <michelled> ah, that makes a lot more sense

[15:08:58 CST(-0600)] <michelled> thx

[15:09:23 CST(-0600)] <michelled> so, why did it seem ok to give jqUnit a dependence on Fluid.js?

[15:09:55 CST(-0600)] <Bosmon> Because I think it is now perfectly clear that we have no expectation of interesting anyone outside the Fluid community in it

[15:10:06 CST(-0600)] <Bosmon> And it makes the implementation quite annoying if we don't

[15:10:20 CST(-0600)] <Bosmon> Especially figuring out how to get code-loading to work sensibly in node.js

[15:10:47 CST(-0600)] <Bosmon> If we can just defer to Fluid.js own "registerNamespace" mechanics, it makes it a lot clearer how the code can be expected to be loaded

[15:11:49 CST(-0600)] <michelled> I think we'd better check in with the community. I agree that jqUnit is for us, but that wasn't what we had originally decided on. could you send something to list so KING sees it?

[15:12:13 CST(-0600)] <Bosmon> ok

[15:18:57 CST(-0600)] <michelled> Bosmon: it's a bit hard to tell what has changed in terms of things that have moved around from TestUtils into jqUnit - did you make any actual changes to those functions?

[15:19:12 CST(-0600)] <Bosmon> michelled - no, there is no implementation change

[15:19:36 CST(-0600)] <Bosmon> All of the usages of them in the framework could be handled by simply renaming the use from fluid.testUtils.* to jqUnit.*

[15:19:46 CST(-0600)] <michelled> cool

[15:19:51 CST(-0600)] <Bosmon> Although there was a lot more complexity with the functions that were found to be special to the reorderer

[15:20:02 CST(-0600)] <michelled> in terms of the jqUnit-browser file - is there anything new in there?

[15:20:13 CST(-0600)] <Bosmon> It turns out that the key simulation functions actually had a dependence on reorderer from jqUnit!!

[15:20:25 CST(-0600)] <Bosmon> So there was a more fundamental refactoring there

[15:20:32 CST(-0600)] <Bosmon> Yes, those functions ended up in jqUnit-browser

[15:20:39 CST(-0600)] <Bosmon> They still offer the same functionality, but differently packaged

[15:21:18 CST(-0600)] <Bosmon> jqUnit.bindKeySimulator allows clients to supply a "key code map" from the outside, creating a package of related simulation functions which have closed over it

[15:21:29 CST(-0600)] <Bosmon> In this way we could get rid of the awful dependency on Reorderer.js

[15:23:47 CST(-0600)] <Bosmon> Given there was so much refactoring in this area I took the opportunity at the same time to get rid of the awful file UnorderedListTestConstants.js .....

[15:26:28 CST(-0600)] <michelled> Bosmon: did you run those tests in all the target browsers?

[15:26:57 CST(-0600)] <Bosmon> No, I only ran them in Firefox and Chrome

[16:06:33 CST(-0600)] <michelled> Bosmon: we are looking at ReordererTestUtils.js and are wondering why you are packaging up 'keyEvent' and 'ctrlKeyEvent' in the object returned by 'bindReorderer'

[16:06:55 CST(-0600)] <Bosmon> Just for convenience

[16:07:08 CST(-0600)] <Bosmon> It is annoying for the user to type a long global name every time he uses it....

[16:07:52 CST(-0600)] <michelled> fair enough

Browser not supported