fluid-work IRC Logs-2013-09-06

[08:01:52 CDT(-0500)] <jessm> http://justgetflux.com/

[08:15:28 CDT(-0500)] <Justin_o> jessm: does that work?

[08:15:52 CDT(-0500)] <jessm> Justin_o: i installed it and so far it seems to do nothing

[08:16:00 CDT(-0500)] <jessm> i look forward to going to a darker place soon to see

[08:16:17 CDT(-0500)] <jessm> but it's interesting that something like this is getting attention on Wired and that it exists

[08:16:36 CDT(-0500)] <Justin_o> jessm: yes.. interesting take on contextualized settings

[08:16:52 CDT(-0500)] <jessm> http://www.wired.com/gadgetlab/2013/09/flux-eyestrain/

[08:21:54 CDT(-0500)] <Justin_o> jessm: i wonder if this would benefit or hinder someone who needs to work with colours on their monitor.. e.g. for photography post processing, drawing, and etc.

[08:22:27 CDT(-0500)] <jessm> Justin_o: good question. it definitely introduces yet another layer

[09:47:14 CDT(-0500)] <heidiv> jhung anything i can help you with?

[09:48:45 CDT(-0500)] <heidiv> otherwise i was thinking i'd test test test

[09:50:26 CDT(-0500)] <jhung> heidiv: nothing I can think of at the moment. Perhaps check in w justin_o or michelled (both offline at the moment).

[09:51:05 CDT(-0500)] <heidiv> jhung how'd the tabindex battle go?

[09:53:00 CDT(-0500)] <jhung> heidiv: in the end it was awesome.

[09:53:08 CDT(-0500)] <jhung> We didn't have to use tab indexes at all.

[09:53:38 CDT(-0500)] <jhung> Which would have been messy because we'd need to somehow force a tab index of the iframe onto the outer document.

[09:53:54 CDT(-0500)] <heidiv> jhung solution was?

[09:54:23 CDT(-0500)] <jhung> In the end we just moved the iframe to just after the <header></header> in the markup and the tab index flowed naturally from header, to panel, through DT buttons, and then to content.

[09:55:03 CDT(-0500)] <heidiv> jhung aha, and css takes care of its position. and it's obvious to user what's happening?

[09:55:36 CDT(-0500)] <jhung> heidiv: yeah! CSS takes care of that and to the user it looks fine.

[09:55:47 CDT(-0500)] <heidiv> jhung sweeeet

[09:56:10 CDT(-0500)] <jhung> Yay for awesome CSS heidiv!

[09:56:21 CDT(-0500)] <heidiv>

[11:06:14 CDT(-0500)] <clown> jhernandez: coming to the panic meeting (GoToMeeting)?

[11:13:37 CDT(-0500)] <Justin_o> Bosmon2: when you're around, cindyli and I have some questions about demands resolution and other things

[11:32:23 CDT(-0500)] <Justin_o> cindyli: do you know if this is still an issue http://issues.fluidproject.org/browse/FLUID-4481

[11:33:39 CDT(-0500)] <Justin_o> jhung: i'm going to guess you aren't working on this one right now.. could you please stop the progress on it if you aren't http://issues.fluidproject.org/browse/FLUID-3840

[11:34:30 CDT(-0500)] <jhung> Been working on that one for 3 years Justin_o.

[11:34:43 CDT(-0500)] <Justin_o> jhung: is it almost done

[11:34:50 CDT(-0500)] <cindyli> not sure, Justin_o.

[11:34:57 CDT(-0500)] <jhung> Give me 3 more years Justin_o.

[11:35:03 CDT(-0500)] <Justin_o> jhung: lol

[11:35:06 CDT(-0500)] <Justin_o> cindyli: okay

[11:43:41 CDT(-0500)] <Justin_o> cindyli: do you know if this is still an issue http://issues.fluidproject.org/browse/FLUID-4757

[11:45:09 CDT(-0500)] <cindyli> Justin_o: i think it's still an issue

[11:47:55 CDT(-0500)] <Justin_o> cindyli: okay, thanks

[11:48:02 CDT(-0500)] <cindyli> np

[11:58:31 CDT(-0500)] <Justin_o> cindyli: i think this may have been fixed, could you verify http://issues.fluidproject.org/browse/FLUID-4333

[11:59:37 CDT(-0500)] <cindyli> yes, it's fixed, Justin_o

[12:00:09 CDT(-0500)] <Justin_o> cindyli: thanks

[12:00:30 CDT(-0500)] <cindyli> np

[13:56:55 CDT(-0500)] <Justin_o> heidiv: hello.. looking at your pull request for the video player now

[13:57:18 CDT(-0500)] <Justin_o> heidiv: so we need to do two ajax calls, 1) to get the videoIO and 2) to get the captions?

[13:57:22 CDT(-0500)] <Justin_o> is that correct?

[13:57:52 CDT(-0500)] <Bosmon2> Hi there Justin_o - I see you've been de-assigning all my issues from 1.5

[13:58:38 CDT(-0500)] <Justin_o> Bosmon2: yes.. we can continue to fix things as needed but trying to clean things up to the essentials for a release.. feel free to add anything back in that needs to be

[13:59:36 CDT(-0500)] <Justin_o> Bosmon2: by the way, cindyli and i had some questions.. we were looking over chris's issue on the gpii list about not wanting some previews to be effected by changes from other adjusters

[14:00:31 CDT(-0500)] <Bosmon2> cindyli - thanks for your demands block report, I will look at it later today

[14:00:54 CDT(-0500)] <cindyli> that would be great, thanks, Bosmon2

[14:00:56 CDT(-0500)] <Bosmon2> Although I should mention that recent evidence is suggesting that we should mostly cease to use demands blocks altogether

[14:00:57 CDT(-0500)] <heidiv> Justin_o yes

[14:01:19 CDT(-0500)] <Bosmon2> So although I will fix this issue, I recommend that you try to rewrite the code you are working on without demands blocks

[14:01:27 CDT(-0500)] <Justin_o> we came up with three possible solutions 1) guard the models in the previews to not accept changes to the model for those pretences that shouldn't change in those previews 2) modify the distribute options for each preview to only pass in those enactors that the preview should be concerned about 3) use demands blocks to remove the enactors from specific previews

[14:01:39 CDT(-0500)] <Bosmon2> Justin_o - well, you can axe option 3) out of the gate

[14:01:47 CDT(-0500)] <cindyli> yes, Bosmon2, but with the issue that Chris has with removing certain enactors from the preview window, demands blocks are the easist way for him

[14:02:04 CDT(-0500)] <Bosmon2> They may be easy, but they are not good

[14:02:13 CDT(-0500)] <Justin_o> heidiv: thanks.. is there no way to get these all in one request?

[14:02:15 CDT(-0500)] <Bosmon2> It is like sugary drinks....

[14:02:31 CDT(-0500)] <Justin_o> Bosmon2:

[14:03:24 CDT(-0500)] <heidiv> Justin_o i don't think so. michelle also suggested two calls in the jira for vp-192

[14:03:49 CDT(-0500)] <heidiv> here is the api http://amara.readthedocs.org/en/latest/api.html

[14:04:03 CDT(-0500)] <Justin_o> Bosmon2: so the issues we have with the first two options 1) since the schema creates the root model, the model paths are somewhat hidden from an integrator to know what to filter the model on. 2) an integrator would have to know ahead of time what all the parts of the options to distribute for the enhancer from the outer page enhancer

[14:04:24 CDT(-0500)] <Justin_o> Bosmon: do you have any alternative suggestions.. also waiting to hear from you about the complex panels issue

[14:04:37 CDT(-0500)] <Bosmon> Justin_o - yes, very sorry I didn't reply to that yet

[14:05:15 CDT(-0500)] <Justin_o> heidiv: i guess i should read the jira

[14:05:53 CDT(-0500)] <Bosmon> Justin_o - the best approach to me seems to be 2) using distributeOptions

[14:06:07 CDT(-0500)] <Bosmon> Note that you can really achieve everything with that you could achieve with demands blocks, and more

[14:06:38 CDT(-0500)] <Justin_o> Bosmon: okay.. we can outline that.. is there a way with distribute options to say give me everything but these two things

[14:07:22 CDT(-0500)] <Bosmon> Justin_o - just what you always did with demands blocks... you can distribute "emptySubcomponent" as the type for the panels

[14:07:53 CDT(-0500)] <Justin_o> Bosmon: also while we're on the topic of me getting feedback from you can you at some point look at this http://mantrijs.com/ and see what you think of there approach. I'm starting to think that we'll have to start settling the modules issue soon.. as we'll probably want to upgrade the video players build scripts to be more modular so we can use it to bring in an instance of the video player into the discovery tool

[14:08:07 CDT(-0500)] <Bosmon> Justin_o - mantijs looks absolutely abominable

[14:08:16 CDT(-0500)] <Bosmon> Now you reminded me what I was replying to you about yesterday : P

[14:08:24 CDT(-0500)] <Justin_o> Bosmon: ha

[14:09:07 CDT(-0500)] <Justin_o> Bosmon: actually this is sort of the part i was interested in from mantis

[14:09:07 CDT(-0500)] <Justin_o> #if development

[14:09:09 CDT(-0500)] <Justin_o> <script data-require="app" src="js/vendor/mantri.web.js"></script>

[14:09:10 CDT(-0500)] <Justin_o> else

[14:09:11 CDT(-0500)] <Bosmon> Their approach seems absolutely the worst possible choice on several fronts, on issues ranging from intrusion on the client code and build process, to load-time efficiency

[14:09:11 CDT(-0500)] <Justin_o> <script src="//xxx.cloudfront.net/42/buildApp.js"></script>

[14:09:12 CDT(-0500)] <Justin_o> /if

[14:09:32 CDT(-0500)] <Bosmon> Justin_o - yes, that comes under the category of "absolutely abominable"

[14:09:53 CDT(-0500)] <Justin_o> Bosmon: but i was thinking of this more in terms of require.js and its optimizer..

[14:10:33 CDT(-0500)] <Justin_o> Bosmon: although i don't fully know how this works.. but the thought is that we use require in development and the build would switch it to the single concatenated file at build time.

[14:10:43 CDT(-0500)] <Bosmon> Justin_o - I refer you to my earlier remark

[14:10:56 CDT(-0500)] <Justin_o> Bosmon: perhaps this is still abominable.. but could you explain a bit more about why

[14:11:02 CDT(-0500)] <Bosmon> We will never adopt any system that is in the slightest bit similar to this one

[14:11:29 CDT(-0500)] <Bosmon> For a start, when you see people embedding logic in a cryptic syntax such as {{ in your markup files - I'm sure you know what to do!

[14:11:43 CDT(-0500)] <Bosmon> Surely you know what to do when you see that? : P

[14:12:25 CDT(-0500)] <Justin_o> Bosmon: yes we probably wouldn't use that, but if we only had to swap out a single js file for another one, it should be easy enough to do without crazy syntax

[14:12:36 CDT(-0500)] <Bosmon> And as for their ridiculous and complex load-time workflow that seems to give us none of the efficiency benefits we want.... based on injecting script blocks etc. rather than giving us a single set of static files at load-time

[14:13:04 CDT(-0500)] <Justin_o> Bosmon: load time in development or production?

[14:14:05 CDT(-0500)] <Justin_o> Bosmon: also could you fill in the details on this wiki page about the solution we want.. i'm not sure i captured everything there from our much earlier community meeting on the subject http://wiki.fluidproject.org/display/fluid/Grunt+based+build+scripts+planning

[14:14:15 CDT(-0500)] <Justin_o> particularly the requirements section

[14:14:18 CDT(-0500)] <Bosmon> ok

[14:14:30 CDT(-0500)] <Justin_o> Bosmon: thanks..

[14:15:35 CDT(-0500)] <Justin_o> Bosmon: so anyways.. wondering what to start with if we want to update the video player.. currently it has a simple grunt build that packages everything up into a single file, but for the discovery tool we wouldn't need infusion for example.. and possibly some of the other files in there.. like the ones that add the panels into UIO...

[14:22:19 CDT(-0500)] <Bosmon> Justin_o - why wouldn't we need infusion?

[14:22:57 CDT(-0500)] <Justin_o> Bosmon: it's already there

[14:24:01 CDT(-0500)] <Justin_o> we wouldn't need it in a concatenated vp build since it is brought in by the discovery tool already.. i mean we could have two versions.. but it seems unnecessary if they are using the same version for example.

[14:24:31 CDT(-0500)] <Justin_o> heidiv: merged your VP-192 pull request

[14:24:40 CDT(-0500)] <heidiv> Justin_o thanks!

[14:24:53 CDT(-0500)] <Justin_o> cindyli: you might want to update your vp work from master now

[14:25:17 CDT(-0500)] <Justin_o> heidiv: thank you..

[14:25:59 CDT(-0500)] <Justin_o> Bosmon: i'm going to be heading out soon.. i'll catch up with you on this next week i guess.. if you have time to update the wiki page for the grunt build scripts and reply to that e-mail about the complex panels that would be great…

[14:26:08 CDT(-0500)] <Bosmon> Justin_o - will do, thanks

[14:26:39 CDT(-0500)] <Justin_o> Bosmon: thanks