fluid-work IRC Logs-2010-11-05

[09:17:17 CDT(-0500)] <jamon> justin_o: both are running now
[09:17:28 CDT(-0500)] <justin_o> jamon: thanks
[09:25:55 CDT(-0500)] <harriswong> justin_o: i posted a patch on http://issues.fluidproject.org/browse/FLUID-3754
[09:26:31 CDT(-0500)] <justin_o> harriswong: thanks... that's for the layout reorderer?
[09:26:53 CDT(-0500)] <harriswong> justin_o: yep
[09:27:08 CDT(-0500)] <justin_o> harriswong: thanks, i'll take a look at that in a bit...
[09:27:20 CDT(-0500)] <harriswong> justin_o: okie~
[09:29:16 CDT(-0500)] <harriswong> justin_o: i noticed on the layoutReorderer/demo.html, the frame is small.. so the 25% 50% 25% kinda doesn't work quite well with the banana/apple pictures. They will go out of bound because their width is bigger than 25% of the frame width.
[09:29:37 CDT(-0500)] <justin_o> ah
[09:29:42 CDT(-0500)] <harriswong> justin_o:i don't know if you want to do horizontal scrolling, if so, we can add min-width in
[09:30:21 CDT(-0500)] <justin_o> we should check with jhung, but i'd guess not.. we should try to scale the picture size i think
[09:33:45 CDT(-0500)] <justin_o> anastasiac: did you happen to take a look at mlam's latest patch comments patch on FLUID-3821
[09:34:08 CDT(-0500)] <harriswong> justin_o: btw, i just thought of a way to handle the avatar invisibility display, let me update the css abit
[09:34:22 CDT(-0500)] <justin_o> okay...
[09:35:14 CDT(-0500)] <harriswong> justin_o: when you move the banana picture, image is still showing in the avatar.
[09:35:14 CDT(-0500)] <heidi> jamon do you know what "htmldoc" pkg is and if its on the handbook server ?
[09:36:35 CDT(-0500)] <jamon> heidi: it isn't installed
[09:36:38 CDT(-0500)] <anastasiac> justin_o, yes, I spoke to mlam about it yesterday afternoon. He's going to make a few changes and post another patch
[09:36:52 CDT(-0500)] <jamon> heidi: http://www.htmldoc.org
[09:36:54 CDT(-0500)] <heidi> jamon could we add it when you have time?
[09:36:56 CDT(-0500)] <heidi> or can i?
[09:37:04 CDT(-0500)] <mlam> anastasiac: i posted the patch on a JIRA last night - FLUID-3821
[09:37:05 CDT(-0500)] <heidi> for pdf exports
[09:37:18 CDT(-0500)] <justin_o> harriswong: i guess you can make it hidden or something
[09:37:18 CDT(-0500)] <jamon> heidi: from mediawiki?
[09:37:24 CDT(-0500)] <heidi> jamon yep
[09:37:24 CDT(-0500)] <anastasiac> ah! ok, cool, I'll have a look, mlam
[09:38:07 CDT(-0500)] <jamon> heidi: done
[09:38:15 CDT(-0500)] <heidi> jamon thanks !
[09:38:31 CDT(-0500)] <mlam> thanks!
[09:38:39 CDT(-0500)] <justin_o> anastasiac, mlam: thanks..
[09:39:09 CDT(-0500)] <justin_o> anastasiac: i'm reading over the patch too now... if you are happy with it, did you want to commit it or would you like me to?
[09:39:29 CDT(-0500)] <anastasiac> justin_o, I'm happy either way. I'll be able to get to it in a few minutes
[09:39:55 CDT(-0500)] <justin_o> anastasiac: okay thanks... i guess i'll let you do it then if you don't mind
[09:40:02 CDT(-0500)] <anastasiac> np
[09:43:28 CDT(-0500)] <justin_o> mlam: for the comment on fluid.inlineEdit.bindMouseHandlers the word return is there twice
[09:44:02 CDT(-0500)] <justin_o> this is the same for the next two functions as well
[09:45:16 CDT(-0500)] <mlam> justin_o: yah, looks like i did that for all the functions comments after that
[09:45:20 CDT(-0500)] <justin_o> harriswong: please let me know when i should look at the patch for the layout reorderer
[09:46:02 CDT(-0500)] <justin_o> mlam: that was the only thing i noticed with the patch, the rest looked good
[09:46:52 CDT(-0500)] <mlam> justin_o: want me to create another patch to remove the duplicate return text?
[09:47:37 CDT(-0500)] <justin_o> sure, might make it easier for anastasiac
[09:48:08 CDT(-0500)] <anastasiac> mlam, don't worry about it, I can just do that before committing
[09:48:15 CDT(-0500)] <anastasiac> but thanks for the offer
[09:48:49 CDT(-0500)] <mlam> ok, thanks
[09:56:34 CDT(-0500)] <harriswong> justin_o: i did some changes to the patch, sorry about that. now it works on chrome, and the image automatically scales.
[09:57:13 CDT(-0500)] <justin_o> harriswong: np, is it up on the jira now?
[09:57:50 CDT(-0500)] <harriswong> justin_o: yes
[09:59:10 CDT(-0500)] <justin_o> harriswong: thanks i'll go check it out now
[10:10:14 CDT(-0500)] <jhung_afk> mlam: are you still working on Inline Edit documentation?
[10:10:23 CDT(-0500)] <mlam> no, not anymore
[10:10:48 CDT(-0500)] <jhung> mlam: ok. Thanks!
[10:10:54 CDT(-0500)] <mlam> np
[10:10:57 CDT(-0500)] <mlam> need anything from me?
[10:11:18 CDT(-0500)] <jhung> Nope. I was using it to write some other documentation and wasn't sure if it was going to change.
[10:11:26 CDT(-0500)] <mlam> ahh ok
[10:14:22 CDT(-0500)] <anastasiac> mlam, can you clarify for me what the lazyEditView flag does? it looks like if it's true, then renderEditContainer doesn't actually render anything - is that right? Why is this option available?
[10:14:54 CDT(-0500)] <anastasiac> ah, mlam, I just read the wiki
[10:14:57 CDT(-0500)] <anastasiac> that explains it
[10:15:21 CDT(-0500)] <mlam>
[10:18:48 CDT(-0500)] <anastasiac> justin_o, mlam: I've made a few small tweaks to the comments, and committed mlam's patch for FLUID-3821. Thanks, mlam!
[10:19:02 CDT(-0500)] <mlam> yw, thanks for the tweaks
[10:19:21 CDT(-0500)] <harriswong> justin_o: is there any other jira you want me to start working on?
[10:20:12 CDT(-0500)] <justin_o> harriswong: i think you can check in with anastasiac about the keyboard a11y demo. i think she wanted to pair with someone on that, and not sure if she's found someone yet
[10:20:40 CDT(-0500)] <anastasiac> justin_o, harriswong: I did get a start on it yesterday with michelled
[10:21:04 CDT(-0500)] <anastasiac> but today, I need to get some documentation finished up
[10:23:44 CDT(-0500)] <harriswong> anastasiac, justin_o: should i pair on documentation, or should i check on other jiras?
[10:24:24 CDT(-0500)] <justin_o> harriswong: i can check what other jiras need work, anastasiac would you like help on documentation in the mean time?
[10:24:29 CDT(-0500)] <anastasiac> harriswong, I'd check with justin_o for other jiras. doc writing is not really amenable to pairing
[10:25:04 CDT(-0500)] <anastasiac> thanks for the offer!
[10:25:05 CDT(-0500)] <harriswong> anastasiac, justin_o: haha, okay.
[10:28:20 CDT(-0500)] <justin_o> harriswong: would you like to look at FLUID-3824
[10:29:09 CDT(-0500)] <justin_o> you may have to pint Bosmon2 about it though, as it may be related to some framework change. I'm not really sure why it stopped working
[10:29:29 CDT(-0500)] <harriswong> justin_o: will do. and let me know if there is any problem w/ #3754 patch
[10:29:41 CDT(-0500)] <harriswong> justin_o: k.
[10:29:58 CDT(-0500)] <justin_o> harriswong: thanks... and i'll let you know about the patch
[10:49:38 CDT(-0500)] <colinclark> Okay mlam, I think you're in business now with the Uploader
[10:49:46 CDT(-0500)] <colinclark> I just made a commit that brings all the unit tests back to life
[10:49:57 CDT(-0500)] <mlam> sweet
[10:50:02 CDT(-0500)] <colinclark> We need better test coverage overall and then we need to get the HTML 5 implementation going
[10:50:06 CDT(-0500)] <colinclark> So go for it!
[10:50:33 CDT(-0500)] <colinclark> I'm going to work on options backwards compatibility, but I can do it in a way that won't affect Uploader directly, I think
[10:50:52 CDT(-0500)] <mlam> ok, cool
[10:51:07 CDT(-0500)] <mlam> i've started some coding on the html5 uploader, but i'm doing it in a separate file
[10:51:28 CDT(-0500)] <mlam> i'm just going to code away with it's own start, stop, browse and cancel
[10:51:29 CDT(-0500)] <colinclark> That's good. You should create a new HTML5UploaderSupport.js file
[10:51:41 CDT(-0500)] <mlam> then tie it in with what's already there
[10:51:49 CDT(-0500)] <mlam> yah, that's exactly what i called the file
[10:51:58 CDT(-0500)] <colinclark> perfect
[10:52:07 CDT(-0500)] <colinclark> Feel free to commit early and often to the branch
[10:52:15 CDT(-0500)] <colinclark> can't do any harm there, and I can help you out with it that way
[10:52:23 CDT(-0500)] <mlam> ok
[10:52:41 CDT(-0500)] <mlam> i'm just going to focus on the html5 upload file first, before i start touching the other files
[10:52:53 CDT(-0500)] <colinclark> Do take a look at the demo upload engine a bit...
[10:53:00 CDT(-0500)] <mlam> i think i'll need your help with how to tie it all in
[10:53:04 CDT(-0500)] <mlam> ok, i will
[10:53:05 CDT(-0500)] <colinclark> I expect that you'll actually need some of the logic from it in order to implement the HTML 5 engine
[10:53:13 CDT(-0500)] <mlam> ok
[10:53:21 CDT(-0500)] <colinclark> The reason I say that is that we put SWFUpload in charge of firing all the important events
[10:53:45 CDT(-0500)] <colinclark> Whereas the demo engine fires all its own events at the appropriate times (file start, complete success, etc)
[10:53:51 CDT(-0500)] <mlam> ahhh ok
[10:53:56 CDT(-0500)] <colinclark> You'll need to fire these exact same events when uploading via HTML 5
[10:55:14 CDT(-0500)] <colinclark> Then there are series of onFileProgress events that occur until the file is done
[10:55:27 CDT(-0500)] <colinclark> Regardless of error or success, onFileComplete will fire
[10:55:31 CDT(-0500)] <mlam> the onFileProgress events are what control the progress bar?
[10:55:38 CDT(-0500)] <colinclark> mlam: yep
[10:55:52 CDT(-0500)] <colinclark> So those you'll just write a bit of adaptor code to make them work with XHR level 2
[10:56:01 CDT(-0500)] <mlam> right
[10:56:09 CDT(-0500)] <colinclark> If I remember correctly, onFileError or onFileSuccess file first
[10:56:13 CDT(-0500)] <colinclark> then onFileComplete
[10:56:19 CDT(-0500)] <colinclark> Then it starts all over again for each file in the queue
[10:56:21 CDT(-0500)] <mlam> ok
[10:56:28 CDT(-0500)] <colinclark> then we get afterUploadComplete
[10:57:14 CDT(-0500)] <mlam> thanks colin
[10:57:26 CDT(-0500)] <colinclark> no problem
[10:57:28 CDT(-0500)] <mlam> i'll see where i can get this weekend, and maybe commit something
[10:57:37 CDT(-0500)] <colinclark> ok
[10:57:48 CDT(-0500)] <colinclark> It should be quite doable
[10:57:59 CDT(-0500)] <colinclark> The biggest thing is going to be to ensure we're growing our test coverage
[10:58:06 CDT(-0500)] <mlam> right
[10:58:15 CDT(-0500)] <colinclark> Were you able to get the Image Gallery server working okay?
[10:58:43 CDT(-0500)] <mlam> the image gallery?
[10:59:06 CDT(-0500)] <colinclark> I passed along a link to it awhile ago
[10:59:18 CDT(-0500)] <colinclark> https://source.fluidproject.org/svn/fluid/image-gallery/trunk/
[10:59:35 CDT(-0500)] <colinclark> This is a Java application (SpringMVC-based) that we use for testing the Uploader against a real server
[10:59:55 CDT(-0500)] <colinclark> the demo engine is all smoke and mirrors, so you'll need to use this to do real testing
[11:00:13 CDT(-0500)] <mlam> just looked thru the email again, no i haven't tried, i'll do that
[11:00:20 CDT(-0500)] <mlam> ok
[11:10:04 CDT(-0500)] <colinclark> justin_o: I have a quick question if you have time
[11:11:02 CDT(-0500)] <justin_o> colinclark: sure
[11:11:18 CDT(-0500)] <colinclark> I have been doing a terrible job of tracking Bug Parade bugs for Uploader
[11:11:30 CDT(-0500)] <colinclark> as you've probably noticed, I'm pretty much just using the umbrella issue
[11:11:39 CDT(-0500)] <colinclark> I'm sure mlam will have more concrete bug parade issues for his stuff
[11:11:44 CDT(-0500)] <colinclark> mostly I've just been "refactoring"
[11:11:59 CDT(-0500)] <colinclark> Anyway, my next step is to provide backwards compatibility for Uploader's options
[11:12:13 CDT(-0500)] <colinclark> Is there any JIRA anywhere on Bug Parade that is appropriate for this?
[11:13:05 CDT(-0500)] <justin_o> colinclark: not sure.. i'll take a look
[11:13:09 CDT(-0500)] <colinclark> thanks
[11:13:11 CDT(-0500)] <colinclark> sorry to distract you
[11:13:27 CDT(-0500)] <colinclark> what I'm going to do is move the "model chewer" from ENGAGE-367 into the framework
[11:13:33 CDT(-0500)] <colinclark> and then get some serious code review
[11:13:38 CDT(-0500)] <colinclark> and then petition you to put it into the bug parade
[11:14:05 CDT(-0500)] <colinclark> and if it works, we can talk early next week about if we want to actually do some of that options restructuring in Inline Edit that you guys wanted to do, assuming this all works
[11:14:31 CDT(-0500)] <justin_o> colinclark: that would be nice
[11:14:56 CDT(-0500)] <justin_o> colinclark: i don't think there is a specific jira for that, except for the more general refactoring jiras
[11:15:01 CDT(-0500)] <colinclark> ok
[11:15:43 CDT(-0500)] <colinclark> So, I'm going to file a subissue against FLUID-3750 that encompasses this
[11:15:46 CDT(-0500)] <colinclark> and then work in my branch
[11:15:54 CDT(-0500)] <justin_o> colinclark: thanks...
[11:15:56 CDT(-0500)] <colinclark> our branch, right mlam?
[11:16:04 CDT(-0500)] <colinclark> and then when it's in some form to be used, we can figure out what to do next
[11:16:09 CDT(-0500)] <mlam> righto
[11:16:13 CDT(-0500)] <justin_o> colinclark: sounds good
[11:20:04 CDT(-0500)] <colinclark> justin_o: http://issues.fluidproject.org/browse/FLUID-3826
[11:20:50 CDT(-0500)] <justin_o> colinclark: thanks... i'll add that to the bug parade
[11:21:00 CDT(-0500)] <colinclark> well, maybe don't sweat it yet
[11:21:03 CDT(-0500)] <colinclark> let's do it before we merge
[11:21:05 CDT(-0500)] <colinclark> assuming it all works
[11:21:11 CDT(-0500)] <colinclark> i'm in a branch, so it doesn't have to be on parade yet
[11:21:39 CDT(-0500)] <justin_o> colinclark: right... that's a good point
[11:21:41 CDT(-0500)] <justin_o> okay
[11:30:55 CDT(-0500)] <justin_o> harriswong: I think I have some comments about the layour reorderer patch... did you want to skype about it later
[11:31:29 CDT(-0500)] <harriswong> justin_o: sure.
[11:32:43 CDT(-0500)] <justin_o> harriswong: okay... whenever is a good time for you
[11:33:04 CDT(-0500)] <harriswong> justin_o: i can do it now
[11:33:08 CDT(-0500)] <justin_o> okay
[11:33:14 CDT(-0500)] <justin_o> i'll call you on skype
[11:33:20 CDT(-0500)] <harriswong> justin_o: k
[11:52:29 CDT(-0500)] <justin_o> jhung_afk: when you have a second can you tell harriswong and I where the skyp link should navigate to
[11:54:39 CDT(-0500)] <jhung_afk> justin_o, harriswong: the skip link should put focus onto the top container in the middle column.
[11:55:02 CDT(-0500)] <justin_o> jhung: the one with apple, right?
[11:55:07 CDT(-0500)] <jhung> yes
[11:55:13 CDT(-0500)] <justin_o> okay, thanks
[12:03:15 CDT(-0500)] <justin_o> jhung: when you click the skip link do you want focus pushed onto the portlet or just have the page scroll to their
[12:04:00 CDT(-0500)] <harriswong> jhung: yea, so should i just use the bookmark, or do you want it to be focus with the border on it?
[12:05:02 CDT(-0500)] <jhung> justin_o: I would think push focus there so navigation would begin starting at the top-middle coumn portlet.
[12:19:07 CDT(-0500)] <justin_o> colinclark: do you have a second for a question
[12:19:18 CDT(-0500)] <colinclark> yep, sure
[12:20:55 CDT(-0500)] <justin_o> in jhung's wireframes for layout reorderer there is a skip link. He wants that to go to a specific portlet. harriswong is trying to implement that now. He can get the correct item focus but the arrow keys don't change selection. He has to tab first
[12:21:18 CDT(-0500)] <justin_o> is there a special way that we need to set focus on an element ?
[12:22:06 CDT(-0500)] <colinclark> I think probably the safest way is to use the keyboard nav plugin's API
[12:22:23 CDT(-0500)] <colinclark> I'm pretty sure there should be something resembling a select() method
[12:22:40 CDT(-0500)] <justin_o> colinclark: okay thanks... i'll hunt around for it
[12:23:42 CDT(-0500)] <colinclark> Yep, it's the select() method
[12:23:47 CDT(-0500)] <colinclark> fluid.selectable.select()
[12:24:50 CDT(-0500)] <colinclark> Looking at the implementation, it's just a cover for a call to focus()
[12:27:47 CDT(-0500)] <justin_o> mlam: heidi put up a patch for the stlying of the inlineEdit
[12:28:07 CDT(-0500)] <heidi> partial... its just the css. js has to be worked on
[12:28:14 CDT(-0500)] <mlam> ok
[12:28:32 CDT(-0500)] <justin_o> mlam, heidi: maybe you could work together to get it all fitting
[12:29:27 CDT(-0500)] <mlam> sure
[12:30:02 CDT(-0500)] <mlam> heidi: i'm just going to grab and apply the patch first
[12:30:25 CDT(-0500)] <heidi> mlam cool... make sure to change that one line in .js
[12:33:20 CDT(-0500)] <mlam> k
[12:34:53 CDT(-0500)] <heidi> mlam let me know when you've done it and ill come over !
[12:36:16 CDT(-0500)] <mlam> come on over
[12:36:18 CDT(-0500)] <mlam>
[12:36:21 CDT(-0500)] <heidi> k
[12:41:46 CDT(-0500)] <heidi> mlam yeah wierd the blue directions still okay on mine hmm
[12:42:41 CDT(-0500)] <heidi> do you see blue directions on build demo now?
[12:43:46 CDT(-0500)] <mlam> lemme check
[12:44:01 CDT(-0500)] <mlam> yes
[12:44:59 CDT(-0500)] <mlam> browser caching maybe?
[12:56:11 CDT(-0500)] <heidi> mlam so you see blue instructions on all other browsers but firefox
[12:56:42 CDT(-0500)] <mlam> no, i don't see the blue instructions on any browser
[12:57:37 CDT(-0500)] <justin_o> jhung, colinclark: we are having trouble getting the skip link working properly
[12:57:48 CDT(-0500)] <justin_o> basically programatically focusing isn't working well
[12:57:55 CDT(-0500)] <colinclark> What is happening?
[12:59:13 CDT(-0500)] <justin_o> we can focus the element but you still have to tab before you can use the arrow keys.. this is the case even with fluid.selectable.select (by the way i think the signature may be wrong for this function)
[13:00:08 CDT(-0500)] <colinclark> Okay, so do you know why that is the case?
[13:00:30 CDT(-0500)] <justin_o> colinclark: why it's not working.. not show
[13:00:48 CDT(-0500)] <colinclark> Can you start to trace it a bit and determine if it's a bug in the keyboard nav plugin, or a bug in your own code, or a bug in the markup?
[13:01:18 CDT(-0500)] <justin_o> colinclark: sure we can try that
[13:01:25 CDT(-0500)] <colinclark> If it's helpful, I can say unequivocally that you should be able to simply issue a programmatic element.focus() call and have it be the equivalent of focusing the selectable element
[13:01:48 CDT(-0500)] <colinclark> So, either it's a bug in the plugin, or it's a bug in your code
[13:02:14 CDT(-0500)] <justin_o> colinclark: okay...
[13:05:21 CDT(-0500)] <Bosmon2> Hmm
[13:05:26 CDT(-0500)] <Bosmon2> Can you really say that unequivocally?
[13:05:30 CDT(-0500)] <colinclark> Well, yes
[13:05:42 CDT(-0500)] <colinclark> In that, when I designed the plugin, this was a key requirement
[13:05:48 CDT(-0500)] <Bosmon2> Well, yes...
[13:05:52 CDT(-0500)] <Bosmon2> But did you know it was possible?
[13:05:52 CDT(-0500)] <colinclark> and one that was certainly supported "at some point in time"
[13:05:57 CDT(-0500)] <Bosmon2> ok
[13:06:00 CDT(-0500)] <colinclark> it worked, at some point, yes
[13:06:09 CDT(-0500)] <colinclark> we clearly have an API that suggests it should be possible
[13:06:27 CDT(-0500)] <mlam> heidi: it was me
[13:06:35 CDT(-0500)] <heidi> mlam phew ! ha
[13:06:42 CDT(-0500)] <mlam> when i renamed a variable, i forgot to rename it in the css
[13:06:48 CDT(-0500)] <heidi> ah ok
[13:06:51 CDT(-0500)] <Bosmon2> justin_o: Do you have a demo of this effect somewhere?
[13:07:12 CDT(-0500)] <justin_o> Bosmon2: not exactly yet... sort of ... harris has it on his computer...
[13:07:23 CDT(-0500)] <justin_o> it is part of his update on a patch he posted
[13:07:25 CDT(-0500)] <heidi> mlam do you want to edit the js together or are you cool? taking out the img stuff.
[13:07:29 CDT(-0500)] <justin_o> so it will be coming
[13:07:44 CDT(-0500)] <Bosmon2> I think the issue might be that to some browsers, some elements are "unfocusable"
[13:07:54 CDT(-0500)] <mlam> i'm good. could u pop over one more time ? i'm getting a double pencil again
[13:08:00 CDT(-0500)] <heidi> k
[13:08:00 CDT(-0500)] <Bosmon2> That is, they simply don't participate in focus events at the DOM level
[13:08:03 CDT(-0500)] <colinclark> Bosmon2: that sounds quite scary
[13:08:03 CDT(-0500)] <justin_o> Bosmon2: but it is the same element that would get focus when using the arrow keys
[13:08:05 CDT(-0500)] <Bosmon2> divs and spans, etc
[13:08:25 CDT(-0500)] <colinclark> Bosmon2: With a tabindex of "0" divs and spans should be programmatically focusable
[13:08:32 CDT(-0500)] <colinclark> At least in a browser that doesn't completely suck
[13:08:35 CDT(-0500)] <Bosmon2> hum
[13:08:48 CDT(-0500)] <colinclark> meaning, not some miserable versions of safari
[13:09:02 CDT(-0500)] <colinclark> even firefox 2 was capable of this, i believe
[13:09:07 CDT(-0500)] <justin_o> colinclark: safari's not soo bad
[13:09:15 CDT(-0500)] <colinclark>
[13:09:25 CDT(-0500)] <justin_o> colinclark: i think firefox 2 couldn't tab navigate to empty anchors
[13:09:26 CDT(-0500)] <Bosmon2> In CSpace I started to see lots of effects from setting custom tabindex that encouraged me to think that this feature has become unworkable in modern browsers
[13:09:29 CDT(-0500)] <colinclark> A version or two ago, it was dismal at supporting keyboard navigation
[13:09:34 CDT(-0500)] <Bosmon2> But this is just anecdotal
[13:09:44 CDT(-0500)] <colinclark> Bosmon2: yeah, this is always the darkest corner of a browser
[13:09:50 CDT(-0500)] <colinclark> I think we can say this
[13:09:53 CDT(-0500)] <Bosmon2> Certainly the only way I could get the selectable plugin to do something sensible is simply remove all the custom tabindexes
[13:09:57 CDT(-0500)] <colinclark> Tabindices should really only sanely be set to 0 or -1
[13:10:15 CDT(-0500)] <Bosmon2> Since the tabbing order you got from any non-default setting of tabindex was insane
[13:10:32 CDT(-0500)] <colinclark> Bosmon2: You mean anything > 0?
[13:10:41 CDT(-0500)] <Bosmon2> Well, so far I have fears that that sane set of tabindexes might have shrunk further
[13:10:48 CDT(-0500)] <Bosmon2> To "-1" or "nothing" (not 0)
[13:10:54 CDT(-0500)] <colinclark> I don't think that could be possible
[13:11:02 CDT(-0500)] <colinclark> I mean, anything is possible
[13:11:05 CDT(-0500)] <harriswong> colinclark, Bosmo2: would you like me to upload the patch as is, so you can take a look at it?
[13:11:23 CDT(-0500)] <colinclark> harriswong: yes, cool
[13:11:23 CDT(-0500)] <Bosmon2> I think we have to fear that any kind of incompetence is possible, when imagining the behaviour of browser developers for a11y features
[13:11:58 CDT(-0500)] <Bosmon2> But, let's hope for the best...
[13:12:00 CDT(-0500)] <colinclark> Well, I think we have a rather different opinion in the case of Firefox after version 3.5 or so
[13:12:39 CDT(-0500)] <mlam> justin_o: with heidi's new background image , we should remove all the work with updating the alt text of the textEditButton?
[13:13:12 CDT(-0500)] <colinclark> mlam: hey, did heidi figure out a masterful way of avoiding the need for an img tag with inline edit?
[13:13:25 CDT(-0500)] <mlam> colinclark: yah, she did
[13:13:28 CDT(-0500)] <mlam> it works really well
[13:13:54 CDT(-0500)] <colinclark> heidi: WICKED!
[13:13:58 CDT(-0500)] <colinclark> that's so great
[13:14:10 CDT(-0500)] <heidi>
[13:15:46 CDT(-0500)] <justin_o> mlam: i think so
[13:16:00 CDT(-0500)] <mlam> colinclark: yes
[13:17:02 CDT(-0500)] <colinclark> cool
[13:19:09 CDT(-0500)] <heidi> mlam i should show you the small bug i found when using voiceover
[13:19:25 CDT(-0500)] <mlam> ok, coming over
[13:19:40 CDT(-0500)] <colinclark> aha, justin_o and harriswong and Bosmon2
[13:19:46 CDT(-0500)] <colinclark> This is connected with the darkest pit of event handling
[13:19:53 CDT(-0500)] <colinclark> firing one event as the result of another event
[13:19:56 CDT(-0500)] <Bosmon2> Hi harris - could we always make sure to produce patches relative to the project root?
[13:20:05 CDT(-0500)] <Bosmon2> I was discussing this issue with anastasiac the other day...
[13:20:35 CDT(-0500)] <Bosmon2> Apparently Aptana makes it desperately easy to peddle in these kinds of "capriciously formed patches" but other people then need to "guess right" in order to use them
[13:20:59 CDT(-0500)] <colinclark> I highly recommend using the "patch" command, though Bosmon2 doesn't share my aesthetic
[13:21:19 CDT(-0500)] <Bosmon2> colinclark: What influence does that have on the issue?
[13:21:20 CDT(-0500)] <colinclark> harriswong and justin_o: One thing to try, as a start, is to return false from your click event handler
[13:21:41 CDT(-0500)] <harriswong> Bosmo2: will do. sorry.
[13:21:43 CDT(-0500)] <colinclark> Using "patch"?
[13:21:49 CDT(-0500)] <Bosmon2> Don't you still then need to guess where to apply a patch, even when using "patch"?
[13:23:34 CDT(-0500)] <colinclark> It forces you to think about what you are actually doing, and from which location
[13:23:34 CDT(-0500)] <colinclark> sorry, yes
[13:23:34 CDT(-0500)] <colinclark> "svn diff" from the command line
[13:23:34 CDT(-0500)] <colinclark> anyway
[13:23:34 CDT(-0500)] <colinclark> harriswong: Start by making sure you prevent the default action and stop all propagation of the click event
[13:23:35 CDT(-0500)] <colinclark> I'm curious to see if it has any effect, though I imagine it won't
[13:23:43 CDT(-0500)] <colinclark> justin_o: Is there a wireframe for this demo anywhere?
[13:24:09 CDT(-0500)] <colinclark> maybe i should be asking jhung
[13:24:10 CDT(-0500)] <justin_o> yes.. it's on the jira that harris put his patch on
[13:24:44 CDT(-0500)] <Bosmon2> Return false doesn't work
[13:24:55 CDT(-0500)] <harriswong> colinclark: i think the return false fixed it...
[13:25:00 CDT(-0500)] <colinclark> Bosmon2: You just tried it?
[13:25:04 CDT(-0500)] <Bosmon2> yes
[13:25:20 CDT(-0500)] <colinclark> harriswong: and you did too?
[13:25:23 CDT(-0500)] <Bosmon2> Doesn't work for me, harriswong
[13:25:29 CDT(-0500)] <justin_o> Bosmon2: harris switched to pushing focus to a specific portlet instead of to the reorederer
[13:25:49 CDT(-0500)] <Bosmon2> ok
[13:26:06 CDT(-0500)] <colinclark> what does that mean, justin_o?
[13:26:18 CDT(-0500)] <Bosmon2> So.... the "last-minute JIRA" I wanted to propose is http://issues.fluidproject.org/browse/FLUID-3825
[13:26:39 CDT(-0500)] <Bosmon2> This is part of work Jura is in progess in collectionspace
[13:26:45 CDT(-0500)] <justin_o> so we had tried to things beforfe.. 1 was to push focus to the apple portlet, and the other was to push it to the container of the reorderer which itself pushes focus i think..
[13:26:57 CDT(-0500)] <justin_o> both didn't work even though a portlet had focus
[13:27:05 CDT(-0500)] <Bosmon2> The "upside" for the framework is that this relates to functionality that was implemented last month but doesn't have test cases
[13:27:07 CDT(-0500)] <colinclark> Okay, so justin_o and harriswong
[13:27:12 CDT(-0500)] <colinclark> you are saying:
[13:27:12 CDT(-0500)] <Bosmon2> So as well as the fix, we would get the test cases too
[13:27:14 CDT(-0500)] <justin_o> but with your suggesion colin, it now worked when we focused the apple straight away
[13:27:14 CDT(-0500)] <jhung> colinclark: reading log now.
[13:27:18 CDT(-0500)] <colinclark> 1. If we focus the selectable
[13:27:22 CDT(-0500)] <colinclark> 2. We prevent the default action
[13:27:23 CDT(-0500)] <colinclark> it works
[13:27:24 CDT(-0500)] <colinclark> yes?
[13:27:54 CDT(-0500)] <colinclark> jhung: nevermind, dude
[13:27:58 CDT(-0500)] <Bosmon2> justin_o: Summary sounds plausible since I think we have often had issues with "double focus"
[13:28:09 CDT(-0500)] <colinclark> It really only makes sense
[13:28:09 CDT(-0500)] <jhung> colinclark: yeah saw that.
[13:28:14 CDT(-0500)] <Bosmon2> calling focus in the middle of an existing focus call usually has unfortunate effects
[13:28:32 CDT(-0500)] <colinclark> clearly you want to stop any further behaviour related to the click event before running off to focus something
[13:28:56 CDT(-0500)] <colinclark> similarly, it sounds like you actually want to move focus to a particular selectable
[13:29:02 CDT(-0500)] <colinclark> so that's all cool
[13:29:22 CDT(-0500)] <colinclark> nice job, harriswong and justin_o
[13:29:41 CDT(-0500)] <Bosmon2> harriswong: I guess we still need a cursor CSS style for the grab handles on the portlets?
[13:30:22 CDT(-0500)] <harriswong> Bosmon2: like a hover style?
[13:30:37 CDT(-0500)] <Bosmon2> Also should try to use "border" rather than "padding" so that the portlet content doesn't jump about when selecting them... although from jacob's experience this can be tricky to get right
[13:30:40 CDT(-0500)] <Bosmon2> harriswong: yes
[13:30:55 CDT(-0500)] <Bosmon2> I think all the previous samples have this so you can consult them for how to do it
[13:31:23 CDT(-0500)] <colinclark> Seriously, the Lightbox effect they added in JIRA is one of the worst things I've ever seen
[13:31:47 CDT(-0500)] <Bosmon2> Which effect is that?
[13:31:57 CDT(-0500)] <colinclark> Well, I'm trying to view jhung's wireframe
[13:32:04 CDT(-0500)] <colinclark> and i click on the image and it pops up a tiny lightbox
[13:32:08 CDT(-0500)] <Bosmon2> ha
[13:32:19 CDT(-0500)] <colinclark> I got to try to "right click" on it to view it, and it just closes the freaking lightbox
[13:32:19 CDT(-0500)] <Bosmon2> Yes, Google seems to love to do that too
[13:32:24 CDT(-0500)] <Bosmon2>
[13:32:32 CDT(-0500)] <jhung> colinclark: click the link at the bottom of the image
[13:32:41 CDT(-0500)] <colinclark> Okay, so I'm in a bit of a dramatic mood...
[13:32:44 CDT(-0500)] <colinclark> but software like this is cruel
[13:32:59 CDT(-0500)] <Bosmon2> Atlassian were never masters of design
[13:33:07 CDT(-0500)] <Bosmon2> What's really cruel is that they are well above average for the industry
[13:33:12 CDT(-0500)] <harriswong> Bosmon2: ok. i will check the other demos about that border/padding issue.
[13:33:12 CDT(-0500)] <Bosmon2> It's why we keep using their products
[13:33:18 CDT(-0500)] <Bosmon2> Are we going to move over to Bugzilla?
[13:33:31 CDT(-0500)] <colinclark> rrrrr
[13:33:42 CDT(-0500)] <Bosmon2> I'm sure Mitchell Baker would tell us it is just fine
[13:33:51 CDT(-0500)] <colinclark> hey
[13:33:54 CDT(-0500)] <colinclark>
[13:34:15 CDT(-0500)] <colinclark> We talked about how huge a shift it was for the community to become product-focused
[13:34:20 CDT(-0500)] <colinclark> consumer product focused
[13:34:27 CDT(-0500)] <Bosmon2> harriswong: The existing samples are mainly a source for the grab handle style..... but if you're lucky, you might find the border style too
[13:34:28 CDT(-0500)] <colinclark> she talked about how most software sucks
[13:34:37 CDT(-0500)] <Bosmon2> So it does
[13:34:41 CDT(-0500)] <Bosmon2> And most managers don't care
[13:34:43 CDT(-0500)] <colinclark> She really is an honorary member of Fluid
[13:34:44 CDT(-0500)] <colinclark> it was really great
[13:34:56 CDT(-0500)] <colinclark> Well, I guess our move to MediaWiki for the Handbook has been awfully interesting
[13:35:01 CDT(-0500)] <Bosmon2>
[13:35:02 CDT(-0500)] <colinclark> it's both bad and good simultaneously
[13:35:08 CDT(-0500)] <colinclark> Ambivalent Software
[13:35:28 CDT(-0500)] <colinclark> hey harriswong and justin_o: I feel a bit funny about the code that disables all links
[13:35:41 CDT(-0500)] <colinclark> Does it make you guys feel funny too, or is it just me?
[13:35:41 CDT(-0500)] <justin_o> colinclark: okay
[13:35:50 CDT(-0500)] <Bosmon2> It makes me feel funny too
[13:35:58 CDT(-0500)] <justin_o> it is a bit heavy handed i supposed
[13:36:00 CDT(-0500)] <justin_o> suppose
[13:36:07 CDT(-0500)] <harriswong> colinclark: mm.
[13:36:12 CDT(-0500)] <colinclark> I understand it, I think
[13:36:20 CDT(-0500)] <colinclark> it's just that I wonder why, a bit?
[13:36:42 CDT(-0500)] <justin_o> colinclark: we just don't want the page jumping around, refreshing, or messing up the url
[13:37:00 CDT(-0500)] <justin_o> since all the links are fake
[13:37:27 CDT(-0500)] <harriswong> colinclark: or we can just do a $('<tag> a') instead of $('a')
[13:38:00 CDT(-0500)] <colinclark> harriswong: I'm not sure what you mean
[13:38:01 CDT(-0500)] <justin_o> Bosmon2: reading up on FLUID-3825. I'm not sure i really understand it
[13:38:18 CDT(-0500)] <colinclark> I guess it's an interesting question
[13:38:23 CDT(-0500)] <colinclark> jhung: Was this part of your spec?
[13:39:13 CDT(-0500)] <jhung> colinclark: which?
[13:39:19 CDT(-0500)] <harriswong> colinclark: so instead of disabling all clicking event of all the links element, we can specify the link element within just the demo page. ie. $('.example a').
[13:39:21 CDT(-0500)] <colinclark> having the links be dummy
[13:39:31 CDT(-0500)] <colinclark> I don't really have a clearly formed opinion about any of this...
[13:39:35 CDT(-0500)] <colinclark> it just makes me feel a bit funny
[13:40:02 CDT(-0500)] <colinclark> harriswong: definitely best to do that in general, yes
[13:40:16 CDT(-0500)] <jhung> colinclark: yes the links are dummy, but the demo clearly indicates this as such. Used primarily to illustrate the context.
[13:40:22 CDT(-0500)] <colinclark> though i guess my question, to try to formulate my thoughts a bit more clearly, is two-fold:
[13:41:08 CDT(-0500)] <colinclark> 1. Do we want dummy links? Are links that don't go anywhere really confusing? Why are they links at all? Could they go somewhere else? What's simplest without being contrived?
[13:41:17 CDT(-0500)] <colinclark> I forget what the second part of my question was
[13:41:45 CDT(-0500)] <Bosmon2> Perhaps the 2nd part of your question was, 2. What might the effect of this implementation be, if this demo were extended or maintained in some way, or found parts of it embedded elsewhere?
[13:41:58 CDT(-0500)] <colinclark> that's always a good point
[13:42:15 CDT(-0500)] <colinclark> if someone else copy-pasted this into their code (and they will!) will it cause their stuff to suck?
[13:42:30 CDT(-0500)] <colinclark> When it comes to demos, we're acrobats
[13:42:38 CDT(-0500)] <colinclark> right jhung?
[13:43:06 CDT(-0500)] <colinclark> We have to walk this tightrope of being simple, compelling-with a bit of context-but also exemplary enough that people can cut and paste our stuff and build off of it
[13:43:15 CDT(-0500)] <jhung> colinclark: if you mean that our demos wear tights while flying over hungry tigers, then you're correct.
[13:43:22 CDT(-0500)] <heidi> progress doesn't work w/ voiceover
[13:43:22 CDT(-0500)] <Bosmon2> It's not really that hard
[13:43:28 CDT(-0500)] <Bosmon2> We just "always need to do the right thing"
[13:43:32 CDT(-0500)] <Bosmon2>
[13:43:41 CDT(-0500)] <colinclark> Bosmon2: I thoroughly disagree
[13:43:47 CDT(-0500)] <colinclark> I mean, that it's not hard
[13:44:06 CDT(-0500)] <colinclark> Because again, the content of the demo will influence how simple our code is while doing the "right thing," as you call it
[13:44:11 CDT(-0500)] <Bosmon2> I wasn't actually being sarcastic
[13:44:12 CDT(-0500)] <heidi> are any components tested w/ voiceover?
[13:44:20 CDT(-0500)] <jhung> Colinclark: 1. the links can be removed. I think the context still holds without them.
[13:44:21 CDT(-0500)] <heidi> colinclark or justin_o
[13:44:23 CDT(-0500)] <colinclark> Bosmon2: I know
[13:44:45 CDT(-0500)] <colinclark> jhung: that's one option, or they could always go somewhere funny or something
[13:44:48 CDT(-0500)] <jhung> the dummy links any how.
[13:45:25 CDT(-0500)] <Bosmon2> Ah, now I am getting confused about sarcasm
[13:45:35 CDT(-0500)] <Bosmon2> I remember that time you said... "I don't even know any more"
[13:45:38 CDT(-0500)] <harriswong> colinclark: if they(users) were to copy my code, i do have a comment there that says "disable all links action on demo page"
[13:45:43 CDT(-0500)] <jhung> colinclark: but that'll pull them out of context. I'd rather they stay in the demo and the links be removed.
[13:45:52 CDT(-0500)] <Bosmon2> Yes
[13:45:59 CDT(-0500)] <Bosmon2> And they will probably copy the comment too, harriswong
[13:46:06 CDT(-0500)] <colinclark> lol
[13:46:10 CDT(-0500)] <colinclark> Agreed
[13:46:12 CDT(-0500)] <jhung> colinclark: in which case, I think the content of the portlets may have to change a little to reduce the expectancy of links to more content.
[13:46:42 CDT(-0500)] <justin_o> heidi: not too often i don't think.. but safari doesn't have complete aria support at the moment.. i don't think it does much with aria-live
[13:46:52 CDT(-0500)] <harriswong> Bosmo2: I see.
[13:46:56 CDT(-0500)] <harriswong> Bosmon2*
[13:47:03 CDT(-0500)] <colinclark> Bosmon2: btw, that was from an episode of the Simpsons
[13:47:08 CDT(-0500)] <Bosmon2> Ah, really
[13:47:14 CDT(-0500)] <colinclark> I've never been the kind of guy who could quote from the Simpsons
[13:47:17 CDT(-0500)] <colinclark> but that one resonated with me
[13:47:25 CDT(-0500)] <heidi> justin_o ah, i see
[13:47:31 CDT(-0500)] <Bosmon2> You delivered it much better that it might have been in the Simpsons
[13:47:41 CDT(-0500)] <colinclark> It was these two Gen Xers at "Homerpalooza" or whatever it was called--a spoof on the '90s Lollapalooza festival
[13:49:08 CDT(-0500)] <colinclark> jhung, justin_o, and harriswong: I'll leave a solution up to you, but my general feeling is that the "disable all links" code is probably confusing and a bit risky for us to show to users.
[13:49:21 CDT(-0500)] <Bosmon2> justin_o: Can I give you more explanation about FLUID-3825?
[13:49:26 CDT(-0500)] <colinclark> But I'm really impressed to see this new demo shaping up so quickly
[13:49:35 CDT(-0500)] <justin_o> Bosmon2: yes please
[13:49:52 CDT(-0500)] <Bosmon2> Basically there is some new functionality in fluid.fetchResources - but right now it is somewhat incompletely implemented
[13:49:59 CDT(-0500)] <Bosmon2> We support a flag called "forceCache"
[13:50:23 CDT(-0500)] <Bosmon2> Which we haven't documented yet
[13:50:35 CDT(-0500)] <Bosmon2> And also, which I discovered last night doesn't even work completely reliably
[13:51:30 CDT(-0500)] <Bosmon2> The purpose of the flag is to nominate that url as a "resource" which should be fetched only once during the lifetime of the page
[13:52:02 CDT(-0500)] <Bosmon2> And once fetched, it is placed in a cache which future requests are resolved from
[13:52:08 CDT(-0500)] <Bosmon2> However, this raises quite a number of timing issues
[13:52:09 CDT(-0500)] <jhung> harriswong, justin_o: so can we do this skip link gracefully? The alternative is to put an anchor and place it next to the top-middle column portlet so the next TAB will focus the portlet.
[13:52:30 CDT(-0500)] <Bosmon2> For example - what happens if a second request is received for the same resource, before the first one completes?
[13:52:44 CDT(-0500)] <Bosmon2> And still worse - raises issues in global coordination, particularly in CSpace
[13:53:01 CDT(-0500)] <Bosmon2> The "initial cache priming site" is in one file - but the point of "central coordination" is in a different file
[13:53:32 CDT(-0500)] <Bosmon2> As the JIRA explains a crucial use case is for a FILE to initiate fetch of a template, but to allow it to be possible to block on this I/O before any INSTANCE of components in that file are created
[13:53:46 CDT(-0500)] <justin_o> jhung: i think we got that one sorted out
[13:53:46 CDT(-0500)] <Bosmon2> Now clearly these two points of coordination (the file, and the point of instance creation) are different
[13:53:49 CDT(-0500)] <justin_o> and working properly
[13:53:58 CDT(-0500)] <jhung> justin_o: okay cool!
[13:54:09 CDT(-0500)] <Bosmon2> So this JIRA relates to a completion of the fluid.fetchResources functionality to deal with this use case
[13:54:26 CDT(-0500)] <Bosmon2> I was expecting JURA to need it today, although he doesn't seem to be around at present
[13:54:59 CDT(-0500)] <Bosmon2> Why this is of benefit to the general framework is that actually the "prototype" for this functionality was implemented in a hurry last month for a CSpace release and so far has no test cases
[13:55:53 CDT(-0500)] <Bosmon2> Actually I discovered last night that the implementation in trunk has a fatal flaw, once I wrote cases for it using "mockjax"
[13:56:22 CDT(-0500)] <justin_o> Bosmon2: okay.. how hard will it be to address
[13:56:34 CDT(-0500)] <Bosmon2> The work is mostly done now
[13:56:35 CDT(-0500)] <justin_o> also what did you mean about the extra unit tests
[13:56:54 CDT(-0500)] <justin_o> was it not possible to make them before or they just didn't exist before
[13:57:02 CDT(-0500)] <Bosmon2> One other effect that I was just chatting with Colin about is that we actually have no users of jqMock right now
[13:57:11 CDT(-0500)] <Bosmon2> And it doesn't actually let us write tests of this kind
[13:57:38 CDT(-0500)] <Bosmon2> Last night I found a different mocking toolkit called "mockjax" that does, which I would put into the "test" area of Infusion
[13:57:56 CDT(-0500)] <Bosmon2> So far we have no capability to test AJAX functionality under the influence of asynchronous service
[13:58:32 CDT(-0500)] <colinclark> hopefully IoC in 1.3 will allow us to avoid having to test AJAX functionality at such a low level most of the time
[13:58:42 CDT(-0500)] <colinclark> but fetchResources() is exactly the sort of thing you want a mock XHR for
[13:58:49 CDT(-0500)] <Bosmon2> Yes
[13:59:10 CDT(-0500)] <justin_o> Bosmon2: could this failure you were seeing be why the other pager demo is broken?
[13:59:27 CDT(-0500)] <Bosmon2> I don't know
[13:59:38 CDT(-0500)] <Bosmon2> It sounds unlikely
[13:59:51 CDT(-0500)] <Bosmon2> So far there are no uses of "forceCache" in the framework image, either in demos or tests
[14:00:43 CDT(-0500)] <justin_o> Bosmon2: okay
[14:01:26 CDT(-0500)] <justin_o> Bosmon2: well if the work is almost done, it fixes issues, and improves test coverage that it seems reasonable to add it in
[14:01:47 CDT(-0500)] <Bosmon2> justin_o: Thanks for your benevolent Kingly mercy
[14:02:01 CDT(-0500)] <justin_o>
[14:02:20 CDT(-0500)] <justin_o> Bosmon2: did you still need to chat about the reorderer stuff too
[14:02:28 CDT(-0500)] <Bosmon2> Yes
[14:02:34 CDT(-0500)] <Bosmon2> What is our end date for Bug Parade now?
[14:02:58 CDT(-0500)] <justin_o> Bosmon2: next friday... with test starting the monday after
[14:03:06 CDT(-0500)] <Bosmon2> ok, cool
[14:03:15 CDT(-0500)] <Bosmon2> Can we chat in half an hour?
[14:03:23 CDT(-0500)] <justin_o> sure
[14:03:40 CDT(-0500)] <justin_o> colinclark: you want to join Bosmon2 in talking about reorderer
[14:04:14 CDT(-0500)] <Bosmon2> colinclark's off to a completely awesome dinner shortly
[14:04:47 CDT(-0500)] <justin_o> Bosmon2: oh really... now i'm jealous.. i have to wait another 3 hours or more before i make it to dinner
[14:05:05 CDT(-0500)] <harriswong> justin_o: i'm only having lunch...
[14:05:22 CDT(-0500)] <justin_o> harriswong: late lunch... sorry for keeping you...
[14:05:29 CDT(-0500)] <justin_o> hope it's awesome
[14:05:51 CDT(-0500)] <harriswong> justin_o, jhung: are we keeping the links on the page?
[14:05:52 CDT(-0500)] <Bosmon2> I still haven't made it to breakfast yet
[14:06:00 CDT(-0500)] <colinclark> I wish I could join you guys to talk about Reorderer
[14:06:18 CDT(-0500)] <colinclark> I'm having dinner shortly with Joseph Hardin, who was the guy who started Sakai at University of Michigan
[14:06:29 CDT(-0500)] <colinclark> he's retired now and moving up to Canada
[14:06:33 CDT(-0500)] <colinclark> and he's a sailor
[14:06:49 CDT(-0500)] <colinclark> So this should be a nice break from all the conference craziness
[14:07:04 CDT(-0500)] <colinclark> I saw Tona last night and she told me to say hello to everyone in Fluid for her
[14:07:05 CDT(-0500)] <Bosmon2> Should be fun
[14:07:06 CDT(-0500)] <colinclark> she misses work with us
[14:07:28 CDT(-0500)] <jhung> harriswong, justin_o: no. There will be no links in the demo aside from the skip link. We'll adjust the content of the portlets accordingly. For now just implement as in the wireframe minus the <a> tags
[14:07:37 CDT(-0500)] <justin_o> colinclark: that was nice of her.. I'm sure we all miss her too
[14:07:54 CDT(-0500)] <harriswong> jhung: ok.
[14:15:14 CDT(-0500)] <colinclark> Well, have a really good weekend everyone
[14:15:20 CDT(-0500)] <colinclark> see you on the other side on Monday
[14:15:41 CDT(-0500)] <colinclark> mlam: we can continue the uploader odyssey then
[14:16:09 CDT(-0500)] <mlam> sound sgood
[14:16:11 CDT(-0500)] <mlam> cya
[15:20:02 CDT(-0500)] <anastasiac> Bosmon2, an IoC question: Am I correct in understanding that it's not possible to merge the options in a demands block with the options in the defaults for the subcocmponent?
[15:20:21 CDT(-0500)] <Bosmon2> That's correct, yes
[15:20:29 CDT(-0500)] <Bosmon2> This is the basic fault that is at the heart of FLUID-3771
[15:20:35 CDT(-0500)] <Bosmon2> Actually one of several related faults
[15:20:44 CDT(-0500)] <Bosmon2> Actually sorry
[15:20:48 CDT(-0500)] <Bosmon2> Exactly the opposite is true
[15:20:51 CDT(-0500)] <anastasiac> ok, good. thanks for the confirmation. just wanted to make sure I wasn't misunderstanding
[15:20:54 CDT(-0500)] <anastasiac> oh, wait
[15:20:57 CDT(-0500)] <anastasiac> what do you mean?
[15:20:57 CDT(-0500)] <Bosmon2> It is ONLY possible to merge the options in a demands block with the defaults
[15:21:26 CDT(-0500)]

[15:21:52 CDT(-0500)]

<anastasiac> and the demands block has the options argument as

Unknown macro: {bar}

[15:22:00 CDT(-0500)] <anastasiac> then the subcomponent will get both foo and bar?
[15:22:10 CDT(-0500)] <Bosmon2> In fact the options supplied in demands take the direct place of options supplied by the user
[15:22:17 CDT(-0500)] <anastasiac> replacement
[15:22:21 CDT(-0500)] <anastasiac> so not merging?
[15:22:33 CDT(-0500)] <Bosmon2> Well, like user options, they will merge with the defaults
[15:22:41 CDT(-0500)] <Bosmon2> So yes, it will get both foo and bar
[15:24:07 CDT(-0500)] <anastasiac> Bosmon2, I'm playing around with that, and that's not what I'm seeing
[15:24:11 CDT(-0500)] <Bosmon2> Document all of this as HIGHLY provisional because it is exactly the first thing that will change after the release
[15:24:13 CDT(-0500)] <Bosmon2> I see
[15:24:22 CDT(-0500)] <Bosmon2> What are you seeing?
[15:24:23 CDT(-0500)] <anastasiac> I'm seeing the demands options completely replacing the defaults
[15:24:31 CDT(-0500)] <anastasiac> so the subcomponent only gets bar
[15:24:37 CDT(-0500)] <anastasiac> ah, wait
[15:24:40 CDT(-0500)] <anastasiac> right, ok
[15:24:47 CDT(-0500)] <anastasiac> it gets bar as user options
[15:24:53 CDT(-0500)] <anastasiac> the subcomponent needs to merge with the defaults
[15:24:54 CDT(-0500)] <anastasiac> right
[15:25:02 CDT(-0500)] <anastasiac> ok, sorry... it's late on friday afternoon
[15:25:07 CDT(-0500)] <Bosmon2> hm
[15:25:29 CDT(-0500)] <Bosmon2> Yes, you should see the demands options replacing the user options
[15:26:13 CDT(-0500)] <anastasiac> oh, wait
[15:26:36 CDT(-0500)] <anastasiac> so in my example, the "foo" option is just gone, inaccessible, never to be seen again
[15:27:06 CDT(-0500)] <anastasiac> so NO merging
[15:27:27 CDT(-0500)] <Bosmon2> I see
[15:27:34 CDT(-0500)] <anastasiac> well, I guess if the subcomponent had its own defaults, that might work...
[15:27:36 CDT(-0500)] <Bosmon2> That's not what I was believing would happen
[15:27:40 CDT(-0500)] <Bosmon2> Yes, that's what I meant
[15:27:42 CDT(-0500)] <Bosmon2> By "user options"
[15:27:48 CDT(-0500)] <anastasiac> but the options: specified in compoents: is gone, gone
[15:27:50 CDT(-0500)] <Bosmon2> I mean, the ones written in, by the person who configured the component
[15:27:51 CDT(-0500)] <Bosmon2> Right
[15:27:56 CDT(-0500)] <Bosmon2> That's what I mean by "user options"
[15:28:07 CDT(-0500)] <Bosmon2> I guess it's good to make this clear
[15:28:14 CDT(-0500)] <anastasiac> ok, good. I think I've got this straight now
[15:28:17 CDT(-0500)] <Bosmon2> Yes, the "defaults" it would get are its own defaults
[15:28:27 CDT(-0500)] <Bosmon2> This is why we are thinking that writing things in "components" is actually actively confusing
[15:28:35 CDT(-0500)] <anastasiac> yes, it's challenging explaining all this: there are 27 ways from Sunday to do everything!
[15:28:38 CDT(-0500)] <Bosmon2> We may stop doing this, or at least create a notation there that is equivalent to "demands"
[15:29:39 CDT(-0500)] <anastasiac> ok, so the options in the components declaration are not the defaults for the subcomponent, they're more like user options, which would be overridden by any demands blocks. got it.
[15:30:14 CDT(-0500)] <Bosmon2> So, to refer to that "foo" that you saw completely destroyed - you would use the fluid.COMPONENT_OPTIONS notation that we always used to in defaults
[15:30:19 CDT(-0500)] <Bosmon2> To refer to "what had actually been there"
[15:30:22 CDT(-0500)] <Bosmon2> But this, too, is going to be replaced
[15:30:57 CDT(-0500)] <anastasiac> but you can't use both fluid.COMPONENT_OPTIONS and add more user options, can you?
[15:31:01 CDT(-0500)] <anastasiac> it's one or the other
[15:31:41 CDT(-0500)] <Bosmon2> That's correct
[15:31:49 CDT(-0500)] <Bosmon2> That is one of the most crushing deficiencies of the current system
[15:31:50 CDT(-0500)] <anastasiac> gotcha
[15:31:58 CDT(-0500)] <Bosmon2> It's probably not worth trying to document it in too much detail
[15:32:09 CDT(-0500)] <anastasiac> it does seem like a bit of a limitation
[15:32:16 CDT(-0500)] <Bosmon2> Basically the answer is, "if you find yourself in a tight corner, invent a new kind of subcomponent and write a demands block for it"
[15:32:22 CDT(-0500)] <anastasiac> yeah, maybe I'll just document the one or two main ways of doing things
[15:32:33 CDT(-0500)] <Bosmon2> That aspect of the system works relatively reasonably - the interaction with things written in "defaults" is currently fairly bad
[15:32:34 CDT(-0500)] <anastasiac> but it's still helpful for me to understand it
[15:33:11 CDT(-0500)] <anastasiac> and all of the documentation has a big red block at the top that says "the APIs will change"