[08:10:49 CDT(-0500)] <system64> Hello michelled
[08:11:05 CDT(-0500)] <michelled> hi system64
[08:11:56 CDT(-0500)] <system64> Was working with keyboard accessibilty plugin. How can I make it work with dynamic content?
[08:13:52 CDT(-0500)] <michelled> system64: what are you finding with dynamic content?
[08:16:10 CDT(-0500)] <system64> michelled: The new content isn't selectable with keyboard
[08:17:06 CDT(-0500)] <system64> If I do the initialization again (in console) after new content is added the content is selectable
[08:22:32 CDT(-0500)] <michelled> good question system64. I'm not sure if we have an example that does this. The closest I can think of is the dynamic reorderer manual test, but of course it has the added complexity of the reorderer on the page: http://build.fluidproject.org/infusion/tests/manual-tests/html/dynamic-reorderer.html
[08:22:51 CDT(-0500)] <michelled> it also has terrible focus styling, so it's difficult to see what you're doing
[08:29:35 CDT(-0500)] <system64> michelled: In the demo, the refresh method is updating the selectables
[08:35:31 CDT(-0500)] <system64> michelled: Found the relevant issue http://issues.fluidproject.org/browse/FLUID-4730
[08:36:01 CDT(-0500)] <michelled> good find system64 
[08:43:07 CDT(-0500)] <system64> michelled: Is the "refresh API" referring refreshView?
[08:43:11 CDT(-0500)] <Justin_o> michelled: updated the pull request for GPII-135.. it should merge cleanly now. I also updated infusion and fixed a bug with it.
[08:43:51 CDT(-0500)] <michelled> system64: I suppose refreshView is the modern equivalent. he's probably talking about the 'refresh' method
[08:43:55 CDT(-0500)] <Justin_o> cindyli: are you looking at the comments from Bosmon7 on the FLUID-4907 pull request?
[08:43:58 CDT(-0500)] <michelled> that you saw on the reorderer
[08:44:11 CDT(-0500)] <Justin_o> cindyli: I think i've taken care of the rest of anastasiac's comments
[08:44:11 CDT(-0500)] <michelled> Justin_o: thanks - I was just looking at that
[08:44:17 CDT(-0500)] <Justin_o> michelled: thanks
[08:44:32 CDT(-0500)] <cindyli> Justin_o: no, will have a look
[08:45:12 CDT(-0500)] <Justin_o> cindyli: okay.. i'm going to start looking at the comment regarding not checking if the object is empty
[08:45:48 CDT(-0500)] <cindyli> ok
[08:54:08 CDT(-0500)] <Bosmon7> Hi cindyli
[08:54:20 CDT(-0500)] <cindyli> hi Bosmon7
[08:54:21 CDT(-0500)] <Bosmon7> Thanks for the test case for FLUID-5105
[08:54:34 CDT(-0500)] <cindyli> np
[08:54:36 CDT(-0500)] <Bosmon7> I would thank yzen too but he only seems to be in the other channel : P
[08:55:24 CDT(-0500)] <Bosmon7> I thought that the test case was invalid for a while, but now I think it is probably valid
[08:55:30 CDT(-0500)] <cindyli> did i write that test case or yura did?
[08:55:36 CDT(-0500)] <Bosmon7> Where valid === it may be possible to fix it : P
[08:56:21 CDT(-0500)] <cindyli> that's good
[08:56:46 CDT(-0500)] <Bosmon7> Although we are skating perilously close to what it is possible to achieve with dynamic grades
[08:56:59 CDT(-0500)] <Bosmon7> It would really be better to just simplify the implementation of the builder
[08:58:53 CDT(-0500)] <cindyli> Bosmon: suggestions on which part to be simplified?
[08:59:02 CDT(-0500)] <Bosmon7> We can probably fix FLUID-5015 by going to a "three-phase" system for dynamic grades - phase i) handles all static grades arising from defaults, ii) handles all dynamic grades which are supplied as simple strings from direct options and demands blocks, and iii) handles dynamic grades which require a working invoker structure or function call
[08:59:18 CDT(-0500)] <system64> michelled: How does dom.refresh() work? Is it documented anywhere? In Reorderer.js its taking 2 arguments
[09:01:01 CDT(-0500)] <Bosmon7> cindyli - it would be better to avoid the need for a grade which results from an invoker call
[09:02:43 CDT(-0500)] <Bosmon7> system64 - the API being referred to is selectables.refresh rather than dom.refresh
[09:02:55 CDT(-0500)] <cindyli> ok. that is the third phase in ur list. rather than handling it, we try to avoid
[09:03:21 CDT(-0500)] <cindyli> perhaps for the time being?
[09:04:26 CDT(-0500)] <system64> Bosmon7: Thanks! How are the selectables defined?
[09:04:33 CDT(-0500)] <Bosmon7> cindyli - I need to study your code in some detail, but I think there is some remaining confusing in the design between "builder" and "products"
[09:04:59 CDT(-0500)] <Bosmon7> confusion
[09:06:22 CDT(-0500)] <cindyli> Bosmon7: do you mean builder is supposed only to build grades rather than assembling the full uio product?
[09:32:47 CDT(-0500)] <Bosmon7> Hi cindyli - I've added a few more comments
[09:33:09 CDT(-0500)] <Bosmon7> It would help if there were some comments at the head of "primaryBuilder" explaining what its purpose and function is
[09:33:15 CDT(-0500)] <Bosmon7> Which I have been asking for for a few review cycles now : P
[09:33:39 CDT(-0500)] <Bosmon7> Could you explain i) what configuration it accepts, and ii) what products it produces, and how the user gains access to them?
[09:34:01 CDT(-0500)] <cindyli> thanks, Bosmon7. hope we won't miss them this time around
[09:34:16 CDT(-0500)] <cindyli> taking a look and will try to explain
[09:35:48 CDT(-0500)] <Bosmon7> In general I think the first step in resolving the dependency confusion is to move the material which responds to "buildPrimary" into a subcomponent
[09:36:03 CDT(-0500)] <Bosmon7> It's an old-fashioned solution, but I think it may genuinely improve the design too
[09:36:42 CDT(-0500)] <Bosmon7> But it's not completely clear what the return value to "buildPrimary" in fact is, and in fact the body of the function is invalid for a separate reason which I explained in the comment
[09:44:57 CDT(-0500)] <anastasiac> michelled, if you have a sec, could you look at this page http://wiki.fluidproject.org/display/docs/Tutorial+-+Creating+a+Preferences+Editor+Using+the+UI+Options+Preferences+Framework and give me your opinion whether you think the page is too long (and consider that there's still more to come), and should it be broken down in to multiple pages?
[09:48:09 CDT(-0500)] <michelled> anastasiac: sure - I'll take a look once I'm done with the code review for Justin_o
[09:48:18 CDT(-0500)] <anastasiac> thanks, michelled
[10:03:41 CDT(-0500)] <system64> Bosmon7: I was talking about these lines https://github.com/fluid-project/infusion/blob/master/src/components/reorderer/js/Reorderer.js#L670-L678
[10:06:05 CDT(-0500)] <Bosmon7> system64 - those lines are only necessary if you are using the "fastLocate" methods of the DOM binder, which return cached DOM elements
[10:06:20 CDT(-0500)] <Bosmon7> Since we make these calls in a mouseDrag loop, it is important to avoid creating garbage on this UI thread
[10:06:29 CDT(-0500)] <Bosmon7> This typically isn't a technique that most framework users need
[10:42:13 CDT(-0500)] <cindyli> hi, Bosmon7, r u still there?
[10:46:22 CDT(-0500)] <Justin_o> Bosmon7: was looking at the comments you made about not checking the object length
[10:48:12 CDT(-0500)] <Bosmon7> Hi
[10:48:36 CDT(-0500)] <michelled> yzen: https://github.com/GPII/prefsEditors/pull/3
[10:48:45 CDT(-0500)] <Justin_o> Bosmon7: if we don't check the length and use extending instead, we will always have at least an empty object.. this will in turn get populated with the topCommon options,which I believe will mean that even in cases where we have no configurations for something, lets say no panels, we will get the empty panels grade added
[10:48:56 CDT(-0500)] <Justin_o> Bosmon7: is this acceptable and reasonable
[10:49:55 CDT(-0500)] <Bosmon7> Justin_o - I think it's fine to "construct" a panels grade where there are no panels.... but in what case do you imagine the user asking for no panels?
[10:50:22 CDT(-0500)] <Justin_o> Bosmon7: they only want a ui enhancer
[10:50:53 CDT(-0500)] <Justin_o> so they will use the assembled uie grade and won't have to worry about the panels, but if they look at any of the constructed bits they may be wondering why it still shows up
[10:51:10 CDT(-0500)] <yzen> michelled: thanks
[10:51:37 CDT(-0500)] <Justin_o> Bosmon7: i have a feeling that generally it will mostly be an issue for testing.. as opposed to something that will really distract integrators
[10:54:17 CDT(-0500)] <Bosmon7> Justin_o - the fact that they want a UI Enhancer should surely be signalled by the fact that they use the "uie" version of the builder?
[10:54:35 CDT(-0500)] <Bosmon7> But yes, in general I think that this "isEmpty" variety of logic should always be removed
[10:54:38 CDT(-0500)] <Justin_o> Bosmon7: for sure
[10:54:55 CDT(-0500)] <Bosmon7> The builder may construct any number of things that may not be needed, this is why we take care to namespace its products so carefully : P
[10:55:28 CDT(-0500)] <Justin_o> Bosmon7: just that if they don't configure something, they'll get the empty grade back.. like an empty uio which is devoid of panels
[10:55:28 CDT(-0500)] <Justin_o> Bosmon7: okay
[10:57:07 CDT(-0500)] <Bosmon7> Justin_o - they would only "SEE" an empty uio which is devoid of panels if they actually tried to instantiate one
[10:57:14 CDT(-0500)] <Bosmon7> So why would they do that if they hadn't configured any? : P
[10:57:59 CDT(-0500)] <Justin_o> Bosmon7: yes.. true.. i guess it's not the best example, but i figure they would probably need to configure just about everything else every time anyways, so i guess this may just be a non issue
[10:58:04 CDT(-0500)] <Justin_o> for integrators
[10:58:24 CDT(-0500)] <Justin_o> we'll just have to update the tests and things should be okay i think.. just wanted to bounce all those things off of you
[11:03:30 CDT(-0500)] <Justin_o> cindyli: did you see my conversation with Bosmon7 above?
[11:04:04 CDT(-0500)] <cindyli> reading now
[11:06:54 CDT(-0500)] <cindyli> ok, i see. will make change to the aux builder and tests
[11:08:25 CDT(-0500)] <Justin_o> cindyli: i can work on that if you are doing something else already
[11:08:45 CDT(-0500)] <cindyli> ok, thanks, Justin_o
[11:21:50 CDT(-0500)] <colinclark> hey cindyli and Justin_o, do you guys have any good suggestions for nanook_ regarding a good example Renderer Component?
[11:22:11 CDT(-0500)] <colinclark> Like many of us, he's trying to wrap his head around using the Renderer for his GSoC project
[11:22:18 CDT(-0500)] <colinclark> and is looking for some good code samples
[11:26:16 CDT(-0500)] <Justin_o> colinclark: this is a simple one i made a while back, but don't know how exemplary it is https://github.com/fluid-project/infusion/blob/master/src/demos/fss/clearfix/js/clearfixDemo.js
[11:27:23 CDT(-0500)] <colinclark> nanook_: ^
[11:27:49 CDT(-0500)] <colinclark> Hey nanook_, I was also thinking that in your blog post, maybe you could post those great sketches you showed me today? They were really exciting
[11:28:23 CDT(-0500)] <nanook_> back
[11:28:49 CDT(-0500)] <nanook_> thanks Justin_o!
[11:29:24 CDT(-0500)] <nanook_> colinclark: sure.. I can do that
[11:29:29 CDT(-0500)] <colinclark> Cool
[11:29:35 CDT(-0500)] <nanook_> they're really rough sketches though
[11:29:42 CDT(-0500)] <colinclark> they looked pretty awesome to me
[11:30:10 CDT(-0500)] <colinclark> and if you want, fire me some code showing your latest Playground implementation and I can give you some suggestions for how to structure it when I'm finished all these meetings today
[11:32:38 CDT(-0500)] <nanook_> colinclark: cool! i'll send you a mail once i'm done with whatever's left
[11:33:01 CDT(-0500)] <colinclark> cool
[12:23:16 CDT(-0500)] <Justin_o> cindyli: i think i got all the checks for empty objects taken care of.. i've also updated the unit tests
[12:23:37 CDT(-0500)] <cindyli> awesome. thanks, Justin_o
[12:26:46 CDT(-0500)] <Justin_o> cindyli: what should i take a look at now?
[12:29:02 CDT(-0500)] <cindyli> Justin_o: the other thing is to the last comment that Bosmon made regarding removing invokers in the builder at generating gradenames. yzen and I were talking about that this morning, not sure if he's started or not
[12:29:33 CDT(-0500)] <yzen> cindyli: i think i might be involved with gpii mostly today..
[12:29:46 CDT(-0500)] <Justin_o> cindyli, yzen: i can start taking a look at that then
[12:29:58 CDT(-0500)] <yzen> Justin_o: that's d be great
[12:30:59 CDT(-0500)] <cindyli> ok, yzen. thanks, Justin_o, i'm working on message resolver right now, which is the last item on my list. will move on to removing invoker once resolver is done.
[12:31:21 CDT(-0500)] <cindyli> we probably can pair up at then
[12:31:28 CDT(-0500)] <Justin_o> cindyli: okay.. sounds good
[12:35:41 CDT(-0500)] <Justin_o> heidiv: looking at your pull request for GPII-136
[12:36:31 CDT(-0500)] <Justin_o> it looks good.. i notice though that the logo and the electors image in the header don't change with the contrast themes
[12:36:40 CDT(-0500)] <Justin_o> are they supposed to with this jira, or is there another jira for that?
[12:40:12 CDT(-0500)] <heidiv> Justin_o that's in 140 which i'm doing now, ya
[12:40:22 CDT(-0500)] <Justin_o> heidiv: thanks
[12:41:13 CDT(-0500)] <Justin_o> heidiv: also you decided not to go with a <details> element for the description?
[12:41:31 CDT(-0500)] <cindyli> yzen: where's the primary schema defined?
[12:41:36 CDT(-0500)] <heidiv> Justin_o i used ariadescribed-by - do you think details would be better?
[12:42:00 CDT(-0500)] <heidiv> they don't seem like details, but, required info in order to understand the img, since removing the text
[12:42:12 CDT(-0500)] <cindyli> yzen: the actual schema with the "properties"
[12:42:46 CDT(-0500)] <yzen> it's defined in their independent grades
[12:42:55 CDT(-0500)] <yzen> that are all magically combined into 1
[12:43:01 CDT(-0500)] <cindyli> where are those grades?
[12:43:08 CDT(-0500)] <cindyli> not in primaryBuilder.js
[12:43:11 CDT(-0500)] <yzen> PrimaryBuilder i think yes
[12:43:13 CDT(-0500)] <Justin_o> heidiv: i think you would still need the aria described-by… i see what you mean by it being required to understand the image.. i'm not sure how that will work with the more text option though.. michelled, anastasiac do you have thoughts on that?
[12:43:45 CDT(-0500)] <heidiv> yes the text is no longer "extra" , but required for the img
[12:44:46 CDT(-0500)] <anastasiac> heidiv, forgive me for having to catch up. you're using the aria-describedby attribute; what element is it referencing?
[12:46:05 CDT(-0500)] <anastasiac> heidiv, which issue is this?
[12:46:35 CDT(-0500)] <Justin_o> anastasiac: GPII-136
[12:46:37 CDT(-0500)] <heidiv> hey anastasiac we're talking about the images in the demo resource - we've replaced the images there now to images with the text removed, and numbers instead. then i've added text below the images that describe what the numbers represent. GPII-136
[12:46:40 CDT(-0500)] <Justin_o> https://github.com/fluid-project/prefsEditors/pull/12/files
[12:47:16 CDT(-0500)] <anastasiac> right, gotcha. so the 'describeby' references the element containing the text
[12:47:50 CDT(-0500)] <heidiv> in addition to explaining the #s though, i added text descriptions of the images. perhaps the two things could be seperated … with the text descrip as <details> and the # descrip as something else
[12:47:52 CDT(-0500)] <heidiv> yep
[12:49:07 CDT(-0500)] <anastasiac> I think the text that is being removed from the image should always be displayed, so that the result is the same as what users would have seen. For this reason, the details element seems inappropriate for that text. details is a disclosure widget
[12:49:45 CDT(-0500)] <anastasiac> I think the text descriptions of the image should be separated from the text that was originally on the image, and that might be what we'd use the details element for, as part of the more-text functionality
[12:51:42 CDT(-0500)] <anastasiac> heidiv, based on vjoanna's designs, the 'more text' should be presented in a disclosure-widget type thingy: http://wiki.fluidproject.org/display/fluid/Preference+Discovery+Tool+%28June+9%29#PreferenceDiscoveryTool%28June9%29-Imagecaptionstyling
[12:51:46 CDT(-0500)] <anastasiac> so the details element seems appropriate
[12:52:01 CDT(-0500)] <anastasiac> michelled, Justin_o, what do you think? ^
[12:53:50 CDT(-0500)] <heidiv> anastasiac so image text always shown, text descrip in <details> - i think that makes sense
[12:54:25 CDT(-0500)] <anastasiac> heidiv, that's what seems to make sense to me
[12:55:06 CDT(-0500)] <Justin_o> anastasiac, heidiv: sounds good to me
[12:55:51 CDT(-0500)] <heidiv> Justin_o i'll update the pull req
[12:55:58 CDT(-0500)] <Justin_o> heidiv: thanks
[12:56:24 CDT(-0500)] <Justin_o> anastasiac: just to double check.. will this work with the more text enactor you started on?
[12:57:12 CDT(-0500)] <anastasiac> Justin_o, I imagine so. The more-text enactor I started doesn't do much yet, besides find the images and add a <div> to them. It's really just a sketch, ripe to be torn up and rebuilt
[12:57:32 CDT(-0500)] <heidiv> anastasiac vjoanna i'm not sure the styling for "more text" will work when the description is long and would cover the img.
[12:58:18 CDT(-0500)] <anastasiac> heidiv, I believe vjoanna's not quite sure about the overlay nature of the more-text. I think for now, we might want to start by just placing the text under the image. Justin_o, does that seem reasonable as a first-pass?
[13:00:45 CDT(-0500)] <vjoanna> heidiv, anastasiac: yeah i agree, the overlay could be problematic for the long descriptions
[13:01:09 CDT(-0500)] <heidiv> i'll put it below for now
[13:03:56 CDT(-0500)] <michelled> anastasiac: I was just looking at your tutorial. I think it's working well as is. I think I'd want all those parts available on the page.
[13:04:32 CDT(-0500)] <anastasiac> ok, thanks for the feedback, michelled, I appreciate it
[13:04:45 CDT(-0500)] <michelled> np
[13:09:06 CDT(-0500)] <michelled> yzen: as far as I remember, the only places we are using TTS is in the climate change demo and in prefs editors
[13:09:08 CDT(-0500)] <michelled> is that right?
[13:09:57 CDT(-0500)] <yzen> michelled: correct
[13:10:11 CDT(-0500)] <yzen> I'm going to update the climate change demo since the pref editors are up to date
[13:10:41 CDT(-0500)] <michelled> great!
[13:10:41 CDT(-0500)] <michelled> thx
[13:11:01 CDT(-0500)] <michelled> so that would be on the demo branch in the infusion project repo
[13:11:36 CDT(-0500)] <yzen> michelled: yep that's right
[13:12:19 CDT(-0500)] <michelled> and use we've updated that, avtar can blow away the old server
[13:12:27 CDT(-0500)] <michelled> 'once'
[13:12:58 CDT(-0500)] <yzen> michelled: i am only updating the url there
[13:14:26 CDT(-0500)] <michelled> yzen: is there something else that would need to happen?
[13:15:22 CDT(-0500)] <yzen> i only did some modification to the enactor itself nothing other than that
[13:31:03 CDT(-0500)] <michelled> Justin_o: didn't we use continuum for the climate change nightly?
[13:31:57 CDT(-0500)] <Justin_o> michelled: I'm not sure.. since it isn't built we might have just been serving it.. but i though we were because we had the issue of needing it to come from a master branch
[13:32:31 CDT(-0500)] <michelled> yeah, and my master branch is actually the project repo demo branch for that very reason
[13:32:40 CDT(-0500)] <michelled> I can't seem to find the continuum task
[13:36:02 CDT(-0500)] <Justin_o> michelled: that's strange.. we didn't use a different instance of continuum by any chance did we?
[13:36:24 CDT(-0500)] <michelled> cindyli: it looks like we missed something when we did the directory restructuring. the builder: http://build.fluidproject.org/infusionBuilder/html/InfusionBuilder.html
[13:36:50 CDT(-0500)] <michelled> Justin_o: I'm not sure - avtar when you have a minutes perhaps you can help me unravel this mystery
[13:37:19 CDT(-0500)] <cindyli> michelled: we should look into builder code, it might still looking up dependencies from the old directories
[13:37:48 CDT(-0500)] <avtar> michelled: i'll be done here by 3:30 and can take a look then
[13:37:49 CDT(-0500)] <michelled> yeah, I see references to 'webapp' in the head
[13:37:57 CDT(-0500)] <michelled> thx avtar
[13:38:19 CDT(-0500)] <michelled> I suppose I'll open a new JIRA, cindyli, instead of reopening the existing one
[13:45:47 CDT(-0500)] <michelled> heidiv: have you ever done any work on the Infusion Builder?
[13:46:02 CDT(-0500)] <heidiv> michelled i don't think so
[13:46:47 CDT(-0500)] <michelled> we have a pretty important blocker that we need to resolve and I don't really want to distract cindyli. if you feel up to it, you could take a look: http://issues.fluidproject.org/browse/FLUID-5106
[13:48:56 CDT(-0500)] <heidiv> michelled i'll take a look!
[13:49:04 CDT(-0500)] <michelled> thanks!
[13:53:10 CDT(-0500)] <heidiv> Justin_o 136 updated.
[13:53:33 CDT(-0500)] <Justin_o> heidiv: thanks
[13:56:48 CDT(-0500)] <Justin_o> heidiv: do the details have display none on them so that the more text can show it later?
[13:57:14 CDT(-0500)] <heidiv> Justin_o yes. details is also not supported by firefox and shows by default
[13:57:32 CDT(-0500)] <Justin_o> heidiv: okay… thanks
[14:57:06 CDT(-0500)] <cindyli> michelled: did you notice the src/webapp directory is back with a couple of folders and files? seems from the commit "5b6ad2f3bd832d732e4d1df4183d1c1d7d8355c7"
[15:01:16 CDT(-0500)] <michelled> no, I didn't notice that
[15:02:36 CDT(-0500)] <michelled> cindyli: I guess I should reopen the JIRA and assign it to either justin_o or heidiv
[15:02:49 CDT(-0500)] <cindyli> sounds good, michelled
[15:03:35 CDT(-0500)] <heidiv> michelled which jira? i can take a look
[15:07:00 CDT(-0500)] <michelled> heidiv: issues.fluidproject.org/browse/FLUID-4740
[15:07:11 CDT(-0500)] <michelled> thx heidiv
[15:07:24 CDT(-0500)] <heidiv> cindyli thanks for your comment, ill fix that now
[15:07:44 CDT(-0500)] <cindyli> no problem, thanks, heidiv
[15:35:23 CDT(-0500)] <cindyli> michelled: heidiv's pull request for builder (https://github.com/fluid-project/builder/pull/3) looks good
[15:35:51 CDT(-0500)] <michelled> thanks for reviewing it cindyli
[15:35:54 CDT(-0500)] <michelled> I'll push it
[15:36:03 CDT(-0500)] <heidiv> cindyli michelled i relocated the files that caused webapp to be recreated. here's the pull : https://github.com/fluid-project/infusion/pull/377
[15:36:10 CDT(-0500)] <cindyli> np. hope i didn't miss anything
[15:36:38 CDT(-0500)] <cindyli> thanks, heidiv
[15:38:36 CDT(-0500)] <system64> michelled: I got the video tiles accessible with keyboard
[15:38:56 CDT(-0500)] <michelled> that's great system64!
[15:38:58 CDT(-0500)] <system64> Any suggestions on controls for mute and fullscreen buttons?
[15:39:33 CDT(-0500)] <michelled> I would make sure they are tab focussable and styled nicely when they receive focus
[16:08:53 CDT(-0500)] <system64> michelled: How can the mute and full screen buttons be tab focus-able?
[16:09:37 CDT(-0500)] <system64> Right now I can navigate tiles with arrow keys, and pressing tab loses focus (since there is no next element)