fluid-work IRC Logs-2011-05-09

Owned by Fluid IRC Log Bot
Last updated: May 09, 2011Version comment
32 min read

[08:04:02 CDT(-0500)] <jhung> jessm: fyi. I have a contractor coming between 9 and 10a. Maybe we can chat before standup at 11a?
[08:04:18 CDT(-0500)] <jessm> jhung: yes, let
[08:04:18 CDT(-0500)] <jessm> s
[08:04:24 CDT(-0500)] <jhung> k
[08:52:00 CDT(-0500)] <heidi_> hey jameswy ..so i'm gonna try to finish styling the fat panel today and get that pushed up. are you UIO'ing today?
[08:52:53 CDT(-0500)] <jameswy> heidi_: That's the plan. Doing a few more things right now on the Full w/ Prev right now, then working on Full w/o Prev. Or I can tweak up the Fatty afterward.
[08:53:13 CDT(-0500)] <jameswy> heidi_: Also, what are we doing with the standalone demo?
[08:53:30 CDT(-0500)] <heidi_> jameswy getting full w/o prev sounds like a good plan! and yeah i'll get you to checkout fatty when i'm done.
[08:53:44 CDT(-0500)] <heidi_> i think we'll delete the standalone demo for UIO, right Justin_o ?
[08:54:20 CDT(-0500)] <jameswy> heidi_, Justin_o: I was looking at the regular demos for UIO, and I had forgotten about the chrome we put around them.
[08:54:33 CDT(-0500)] <jameswy> It wouldn't work well for UIO, generally.
[08:54:49 CDT(-0500)] <jameswy> It's too large of a component, space-wise.
[08:54:53 CDT(-0500)] <heidi_> jameswy i think eventually that demo container is gonna be history, i think for 1.5 ? so won't have to live with it too long
[08:55:00 CDT(-0500)] <heidi_> but i hear ya
[08:55:10 CDT(-0500)] <heidi_> i wonder if our demos can... not have that?
[08:55:15 CDT(-0500)] <jameswy> Right, but for 1.4, what do we want to do?
[08:55:17 CDT(-0500)] <heidi_> and you just load the /html file
[08:55:28 CDT(-0500)] <heidi_> thoughts jhung?
[08:56:33 CDT(-0500)] <Justin_o> heidi_: yes for deleting the standalone demo
[08:56:37 CDT(-0500)] <Justin_o> for ui options
[08:57:02 CDT(-0500)] <Justin_o> jameswy: not to sure what you could do about the demo portal chrome
[08:58:07 CDT(-0500)] <jameswy> Justin_o, heidi_, jhung: In the long-term non-technical demo situation (i.e., showcase demos), I was thinking that the UIO demo would be embedded into the page itself, as opposed to being chromed by a page.
[08:58:27 CDT(-0500)] <heidi_> jameswy i feel like that's the plan for all demos. am i right jhung?
[08:58:43 CDT(-0500)] <jameswy> heidi_: It's not the plan right now for all the demos.
[08:59:10 CDT(-0500)] <jameswy> For the rest of the demos, we're embedding a simplified version of them into a page.
[08:59:31 CDT(-0500)] <jameswy> Lemme find the mockups:
[09:00:21 CDT(-0500)] <harriswong> Justin_o, colinclark: I have replaced the tooltip UI 1.9 with a slightly earlier version, and seems to be okay. Trying to run the tests on other system.
[09:01:04 CDT(-0500)] <heidi_> jameswy and the simplified version still wouldn't work with UIO?
[09:01:08 CDT(-0500)] <harriswong> Justin_o, mlam: 1.8.12 UI upgrade have a couple of failed unit test with IE9 on Win7. http://issues.fluidproject.org/browse/FLUID-4206.
[09:01:25 CDT(-0500)] <jameswy> heidi_: The simplified version applies to the components--and a simple UIO is still huge, space-wise.
[09:01:47 CDT(-0500)] <jhung> jameswy, heidi_: yep I think we should have the UIO embedded.
[09:01:56 CDT(-0500)] <Justin_o> harriswong: thanks for the update.. are the uploader tests in FF4 win 7 working now?
[09:02:08 CDT(-0500)] <Justin_o> for the 1.8.12 upgrade
[09:02:38 CDT(-0500)] <heidi_> jhung with the current chrome? it is a really small window for UIO
[09:03:27 CDT(-0500)] <jameswy> heidi_: A bit outdated, but here's the proposed demo usage: http://wiki.fluidproject.org/download/attachments/17665469/Draft+Infusion+sub-site-05.png?version=2&amp;modificationDate=1300386435817
[09:04:11 CDT(-0500)] <harriswong> Justin_o: the one on the FLUID-4206 link is independent from the jQuery 1.6 upgrade link. So they are still failing on my branch. However, I noticed some updates on the upstream and now I am merging + re-testing it on the 1.8.12 UI branch; then will test the 1.6 jquery rbanch as well.
[09:04:37 CDT(-0500)] <jameswy> heidi_: There's no way we're going to fit a UIO into something that small, which is why it makes more sense to simply point the user to using UIO on the page itself.
[09:04:40 CDT(-0500)] <harriswong> Justin_o: my FLUID-4206 branch still uses jquery 1.4.2
[09:04:51 CDT(-0500)] <jameswy> (i.e., pointing them to the top right)
[09:05:33 CDT(-0500)] <Justin_o> harriswong: okay... thanks.. got it
[09:05:39 CDT(-0500)] <jessm> jameswy: that'd be cool – a kind of greying out of the page and then highlighting uio maybe?
[09:05:49 CDT(-0500)] <jessm> probably being too buttinsky and specific (wink)
[09:06:31 CDT(-0500)] <heidi_> jameswy is this for 1.4 or later?
[09:06:54 CDT(-0500)] <jameswy> jessm: Yes, something like that, (wink). We can work out the details when we get there.
[09:07:04 CDT(-0500)] <heidi_> linking to the direct file sounds good to me. is that okay with you jhung?
[09:07:28 CDT(-0500)] <jameswy> heidi_, jessm: Not sure what the timeline is for it, but it's not 1.4 or 1.5 afaik
[09:07:37 CDT(-0500)] <harriswong> justin_o: sorry to confuse you..
[09:07:41 CDT(-0500)] <jhung> yep yep
[09:07:51 CDT(-0500)] <heidi_> jameswy ah, so what do you suggest for 1.4 ?
[09:08:47 CDT(-0500)] <harriswong> Justin_o: if you have time, do you think you can help me test my 1.8.12 UI branch on Safari please?
[09:09:15 CDT(-0500)] <jameswy> heidi_, jhung: It wouldn't be linking to a direct file in the proposed solution, I don't think-it'd really be the page itself. The demo would be the site actual-not a separate demo. We'd just provide the narrative around it.
[09:11:59 CDT(-0500)] <jhung> jameswy: I don't think we're getting rid of the stand-alone demo.
[09:12:38 CDT(-0500)] <jhung> jameswy: I can imagine cases (not many though) where a user would want just the demo.
[09:12:38 CDT(-0500)] <heidi_> jhung yeah i think we are
[09:13:05 CDT(-0500)] <heidi_> jhung a demo for each layout option of UIO will be in /demos , kind of like reorderers
[09:13:27 CDT(-0500)] <jhung> hold on...
[09:13:47 CDT(-0500)] <heidi_> jhung we're just wondering how those in /demos will be look, given that the chrome is too limiting. is it okay to break out of that chrome as a special case for UIO 1.4 demos?
[09:15:19 CDT(-0500)] <jhung> heidi_: okay. I think I get it now (sorry, parachuted into the middle of the convo it seems). So basically we need a UIO demo, but the current demo design is too small for it.
[09:15:57 CDT(-0500)] <heidi_> jhung exactadmundo
[09:16:39 CDT(-0500)] <jhung> heidi_: brb sorry contractor calling.
[09:22:41 CDT(-0500)] <colinclark> jameswy: How do the new demo portal designs you linked to impact on this decision?
[09:22:58 CDT(-0500)] <colinclark> In other words, we know that the current demo portal's tiny little demo window is pretty constraining
[09:23:12 CDT(-0500)] <colinclark> Would you have the same problem with the new designs, or would it be awesome?
[09:23:17 CDT(-0500)] * anastasiac is catching up on the conversation about the demos
[09:24:32 CDT(-0500)] <jameswy> The new designs also have a constricting window for most demos. In the new designs, for UIO, I would suggest that the demo applies to the page/site actual, instead of being quarantined in the window. i.e., just point the user to the UIO/displaypreferences button on the site.
[09:24:39 CDT(-0500)] <jameswy> colinclark ^
[09:25:17 CDT(-0500)] <colinclark> Meaning, in short, that UI Options would be part of the demo portal itself, rather than something inside the portal?
[09:25:25 CDT(-0500)] <jameswy> Correct.
[09:25:28 CDT(-0500)] <colinclark> That seems reasonable
[09:26:55 CDT(-0500)] <anastasiac> I like the idea of having the UI Options "demo" use the actual portal page itself, instead of being embedded in the small window
[09:27:10 CDT(-0500)] <anastasiac> it addresses the problem of the small window, as well as making the demo very real-world
[09:27:30 CDT(-0500)] <anastasiac> let's do some testing, of course, to make sure it will work with the current portal structure!
[09:27:42 CDT(-0500)] <jhung> heidi_: sorry about that.
[09:28:13 CDT(-0500)] <jhung> heidi_: yes I think it's fine for UIO to be treated differently since it's not a component like the others.
[09:29:11 CDT(-0500)] <colinclark> The question still remains, jameswy, how do we highlight it still as one of our components, something you can see in action?
[09:29:13 CDT(-0500)] <colinclark> In other words...
[09:29:21 CDT(-0500)] <colinclark> today, you go to some page and you see a bunch of little boxes
[09:29:24 CDT(-0500)] <heidi_> jhung any suggestions for how it should look? is loading the actual /html/uio.html file fine?
[09:29:38 CDT(-0500)] <colinclark> each of which represents a component we make, which you can see a demo of
[09:29:49 CDT(-0500)] <anastasiac> I wonder if we could load a simple file that explains the special nature of this demo, and instructs the user to try it out?
[09:30:08 CDT(-0500)] <anastasiac> so there'd still be a portal page for it
[09:30:15 CDT(-0500)] <jhung> heidi_: What is uio.html? The "control panel" for UIO with the preview?
[09:30:19 CDT(-0500)] <heidi_> anastasiac like a page with a list of links to those /html pages?
[09:30:26 CDT(-0500)] <heidi_> jhung i meant uiOptions.html
[09:30:52 CDT(-0500)] <jhung> heidi_: what is that exactly?
[09:31:14 CDT(-0500)] <jameswy> colinclark, anastasiac: correct, there'd still be some narrative around it, so there'd still be a portal page for it. Screenshots too, likely. Where the demo would normally be on other components, there'd be instructions on how to use UIO on the page actual.
[09:31:15 CDT(-0500)] <jhung> I don't know these files, so you're going to have to explain a little. (smile)
[09:31:16 CDT(-0500)] <heidi_> jhung the uio file in /demos/UIOptions/html/
[09:31:54 CDT(-0500)] <heidi_> jameswy i like that
[09:32:52 CDT(-0500)] <cindyli> Justin_o: i wonder how much you've progressed with reviewing my FLUID-4171 branch. I'm pretty much done with IoCing UIEnhancer, not sure if my FLUID-4171 branch is a good place to commit? The new changes mainly affect UIEnhancer.js, 3 lines in UIOptions.js are modified at where UIEnhancer is called.
[09:33:59 CDT(-0500)] <jhung> jameswy: yes that works for me. I think it can be done well.
[09:34:11 CDT(-0500)] <Justin_o> cindyli: sorry haven't gotten back to looking at your FLUID-4171 branch since we last talked... i'll take another look at today though
[09:34:50 CDT(-0500)] <cindyli> Justin_o: so is it ok that i commit the new changes into FLUID-4171?
[09:34:59 CDT(-0500)] <heidi_> jameswy do you want to take on creating that demo portal page for UIO?
[09:35:01 CDT(-0500)] <cindyli> Justin_o: since the new changes are based on 4171
[09:36:56 CDT(-0500)] <Justin_o> cindyli: hmm .. are the new changes part of FLUID-4171?
[09:37:01 CDT(-0500)] <Justin_o> or for another jira?
[09:37:50 CDT(-0500)] <cindyli> Justin_o: another jira i created last friday 4207. what if i checked into 4171 with the jira #4207?
[09:38:12 CDT(-0500)] <cindyli> i mean 4207 in the commit message
[09:38:19 CDT(-0500)] <jameswy> heidi_, jhung, jessm, Justin_o: so, colinclark, anastasiac and I just had a quick ad hoc chat about the UIO demos. The direction we're headed in now is to create a separate demo portal page for each of the UIO configurations, much like we do for the families of inline edit and reorderer.
[09:39:45 CDT(-0500)] <jhung> jameswy: that's a great idea.
[09:39:48 CDT(-0500)] <jameswy> I think this is something we can accomplish for 1.4. I'm still working on the full w/ and w/o prev UIOs right now. jhung , do you think you could help out with adapting the current demo portals for new UIO?
[09:40:07 CDT(-0500)] <Justin_o> cindyli: is it that you need to make changes to the code that is changed in 4171 because of 4207?
[09:40:21 CDT(-0500)] <jessm> jameswy: what would that look like? i'm having trouble with imagining it
[09:40:30 CDT(-0500)] <cindyli> exactly, Justin_o
[09:40:41 CDT(-0500)] <jhung> jameswy: when you say "current" you referencing the live demo pages, and not the "current" design that is yet to be implemented, correct?
[09:40:58 CDT(-0500)] <Justin_o> cindyli: hmm.. that's interesting.. how will it affect the code of the changes for FLUID-4207 aren't around?
[09:41:00 CDT(-0500)] <heidi_> i'm picturing a page with links to the different UIO layout demos
[09:41:20 CDT(-0500)] <Justin_o> meaning if i'm just testing out FLUID-4171 and don't have your ui enhancer changes
[09:41:38 CDT(-0500)] <heidi_> each using the uio preview html page as either the preview or the main content (for panels)
[09:41:58 CDT(-0500)] <jameswy> jessm: Right now I'm imagining for 1.4 that the demo portal pages look like what they look now, except for two changes: a display preferences button somewhere on the page actual, and some narrative text on how to use it in where the demo would normally be.
[09:42:17 CDT(-0500)] <jameswy> Perhaps jhung could help materialize this abstraction?
[09:42:37 CDT(-0500)] <jameswy> jhung: Yes, I meant current as in the currently implemented, live pages, not the proposed designs.
[09:42:48 CDT(-0500)] <cindyli> Justin_o: it's the other way around. 4171 does not require changes for 4207. 4207 makes changes on the code from 4171
[09:43:02 CDT(-0500)] <jhung> jameswy: yep I can help out with that.
[09:43:42 CDT(-0500)] <jameswy> jhung: awesome. Thanks!
[09:44:55 CDT(-0500)] <jhung> jameswy: so we're looking at a new "family" page for UIO adapted from current demo pages. Also, it's the intention that we're not going to be updating the other demo pages with any updates made for the UIO demos unless it's something critical, right?
[09:45:27 CDT(-0500)] <jhung> (i.e. what happens in UIO stays in UIO)
[09:47:22 CDT(-0500)] <jameswy> jhung: Correct. For 1.4, we want to keep the portal designs consistent, and UIO will only appear in UIO.
[09:47:56 CDT(-0500)] <jhung> jameswy: cool. I'll start looking at this this afternoon. It's been a while since I looked at UIO, so this is great!
[09:48:09 CDT(-0500)] <Justin_o> cindyli: wondering if the changes that you want to make to FLUID-4171 for FLUID-4207 are backwards compatible..
[09:48:12 CDT(-0500)] <jhung> jessm: I'm available to chat now if you're free.
[09:49:11 CDT(-0500)] <Justin_o> cindyli: i'm not sure what the best approach would be.. it seems like you might actually want to merge your FLUID-4171 branch into new FLUID-4207 branch and continue working there..
[09:49:17 CDT(-0500)] <jameswy> jhung: Great way to get familiar with the new designs, (smile)
[09:49:43 CDT(-0500)] <colinclark> Justin_o, cindyli: That sounds about right. Probably best to keep separate chunks of code in different branches...
[09:49:58 CDT(-0500)] <colinclark> makes it easier to do code review and to keep track of code
[09:50:26 CDT(-0500)] <cindyli> ic, will do. thx. Justin_o, colinclark
[09:54:44 CDT(-0500)] <jessm> jhung: let's do it
[10:17:36 CDT(-0500)] <Justin_o> harriswong: i've updated FLUID-4206 with my safari 5 test results
[10:18:39 CDT(-0500)] <harriswong> Justin_o: framework tests as well?
[10:19:45 CDT(-0500)] <Justin_o> harriswong: yes.. well i didn't get failures in the other places that you had mentioned in your testing.. which is kind of weird
[10:21:43 CDT(-0500)] <harriswong> Justin_o: i am assuming master branch works on the framework?
[10:22:11 CDT(-0500)] <harriswong> Justin_o: on safari 5 i mean
[10:23:56 CDT(-0500)] <Justin_o> harriswong: yes.. i tried running from the daily build site and those all work
[10:26:26 CDT(-0500)] <Justin_o> harriswong: just double checked by updating my master from upstream and testing locally.. and all of the tests are passing with the master branch
[10:26:34 CDT(-0500)] <Justin_o> all of the failing ones at leat
[10:26:35 CDT(-0500)] <jhung> jameswy: can we chat later this aft? maybe 1p or 1:30p ish? About UIO demos.
[10:26:35 CDT(-0500)] <Justin_o> least
[10:28:01 CDT(-0500)] <harriswong> Justin_o: i am getting the same old http:// and file:/// problem again on IoC test
[10:28:10 CDT(-0500)] <jameswy> jhung: Yep. Say, 1:30ish.
[10:28:33 CDT(-0500)] <harriswong> Justin_o: the ones i am failing on my FF4 is entirely different from the ones you mentioned..
[10:28:50 CDT(-0500)] <jhung> jameswy: cool. I'll ping you around then.
[10:29:26 CDT(-0500)] <harriswong> Justin_o: chrome fails on another set on the framework for me as well. I will investigate. thanks.
[10:29:29 CDT(-0500)] <Justin_o> harriswong: yes.. i find it interesting that the ones you mentioned that were failing were all different than the ones i'm seeing
[10:29:41 CDT(-0500)] <Justin_o> harriswong: okay.. good luck..
[10:46:14 CDT(-0500)] <cindyli> colinclark: u said one reason that we wanna break down uiOptions.controls is to make it easier for users to manipulate control options. does the user manipulation include adding in more controls? If yes, the user also has to implement the styling manipulation of the new controls in UIEnhancer. Would it be too much for users to do that?
[10:46:43 CDT(-0500)] <colinclark> I guess the question is what "manipulation" means
[10:46:56 CDT(-0500)] <colinclark> What I was thinking is that we want to modularize UI Options' notion of what preferences are available
[10:47:04 CDT(-0500)] <colinclark> So that it will be easy to add new preferences in the future
[10:47:07 CDT(-0500)] <cindyli> as i understand adding, removing, moving around the options
[10:47:28 CDT(-0500)] <colinclark> A concrete example: For Floe, we'll be adding Media preferences for audio and video (things like captions, audio descriptions, etc.)
[10:47:40 CDT(-0500)] <cindyli> ok
[10:47:45 CDT(-0500)] <colinclark> Alternatively, we want implementers to also be on an equal footing...
[10:47:54 CDT(-0500)] <colinclark> in that they should be able to provide their own preferences panes, too
[10:48:05 CDT(-0500)] <colinclark> UI Options and UI Enhancer are quite separate beasts
[10:48:17 CDT(-0500)] <colinclark> So UI Options is really just the place where a user can specify their preferences
[10:48:32 CDT(-0500)] <colinclark> how those preferences are acted on is another question, and will depend quite a bit on the sort of preference it is
[10:48:42 CDT(-0500)] <colinclark> UI Enhancer is destined to be split up into smaller pieces, itself
[10:48:49 CDT(-0500)] <colinclark> A subcomponent for restyling the page
[10:49:00 CDT(-0500)] <colinclark> A subcomponent for the "behavioural" changes to a page, such as the Table of Contents
[10:49:24 CDT(-0500)] <cindyli> ic
[10:49:25 CDT(-0500)] <colinclark> One can imagine that the Media preferences I referred to above wouldn't be managed by a UI Enhancer at all
[10:49:38 CDT(-0500)] <colinclark> they'd be read by a video player or some kind of delivery service
[10:50:00 CDT(-0500)] <colinclark> So, practically speaking, if a user wanted to add new preferences, yes they'd also have to write the code to do stuff with those new preferences
[10:50:08 CDT(-0500)] <colinclark> Which your ordinary implementer is never going to do
[10:50:15 CDT(-0500)] <colinclark> but certainly we're going to do it...
[10:50:17 CDT(-0500)] <heidi_> cindyli i think another reason is so the controls can be "dropped in" to different places within the different templates. i.e. no duplicate code
[10:50:25 CDT(-0500)] <colinclark> and if we're going to do it, our users are going to want to do it, too
[10:50:34 CDT(-0500)] <colinclark> heidi_: Yep, exactly!
[10:51:27 CDT(-0500)] <heidi_> and will easily allow implementers to create their own templates without worrying about breaking the controls. they would just provide the container div where it gets dropped in
[10:52:39 CDT(-0500)] <cindyli> heidi_: that makes sense. it can be achieved by separating templates
[10:53:08 CDT(-0500)] <cindyli> but it makes me more confused at how to separate the controls component
[10:53:29 CDT(-0500)] <heidi_> each control will be a component. ex. "text size"
[10:53:34 CDT(-0500)] <heidi_> i think, right colinclark ?
[10:53:44 CDT(-0500)] <cindyli> my original thought is to separate each pane into a component. but if the controls can be moved around the pane..
[10:53:46 CDT(-0500)] <colinclark> I'm not sure we need to be quite that granular
[10:53:49 CDT(-0500)] <colinclark> That'd be a lot of components
[10:54:11 CDT(-0500)] <colinclark> I was thinking that we'd break up things up based on groupings of preferences
[10:54:46 CDT(-0500)] <heidi_> that works... i think the html will be flexible enough w css
[10:54:49 CDT(-0500)] <colinclark> In terms of adding or removing individual preferences, I think we're close to being at a point where an implementer could do that without having to change any code--just tweak the template and the render tree (once we make that fully declarative)
[10:54:52 CDT(-0500)] <colinclark> heidi_: Yep, exactly
[10:55:32 CDT(-0500)] <heidi_> which template would they tweak? or would it be an option for that particular group of prefs component
[10:55:49 CDT(-0500)] <heidi_> ah, the template for the component
[11:06:18 CDT(-0500)] <cindyli> but adding preferences still need to change UIEnhancer code
[11:10:13 CDT(-0500)] <cindyli> according to jameswy's UIO design, there are 3 panes, sounds like i should break controls component into 3 sub-components. hi, heidi_, r u breaking the big UIO template into 3 smaller templates?
[11:10:52 CDT(-0500)] <heidi_> cindyli right now it's one template with 3 sections, so i expect i'll be able to load in the 3 diff tempaltes you're creating into it
[11:11:22 CDT(-0500)] <heidi_> by specifying a div with a class="flc-uioptions-textpane" or something like that
[11:11:34 CDT(-0500)] <heidi_> does that sound right?
[11:11:39 CDT(-0500)] <cindyli> yes
[11:11:42 CDT(-0500)] <heidi_> cool
[11:15:24 CDT(-0500)] <colinclark> cindyli, heidi_: That all makes sense to me
[11:27:10 CDT(-0500)] <harriswong> Justin_o: i cannot reproduce those errors on my machine. I will try it on my safari later
[11:28:26 CDT(-0500)] <Justin_o> harriswong: okay, if you can't reproduce it there, let me know and i'll have to see whats up with mine
[11:28:31 CDT(-0500)] <harriswong> Justin_o: weird thing is some of my framework tests do fail, but they fail both on the master and the FLUID-4206 branch. Tried on win7 and another machine, same result. Tried also on localhost, and filesystem, slightly diff result but same across branches.
[11:28:53 CDT(-0500)] <harriswong> Justin_o: o
[11:28:56 CDT(-0500)] <harriswong> Justin_o: ok*
[11:29:24 CDT(-0500)] <Justin_o> pretty strange, maybe an OS thing??
[11:30:25 CDT(-0500)] <harriswong> Justin_o: i hope not.. that would be quite complicated... I still haven't tried the case with 1.8.12 x 1.6
[11:34:48 CDT(-0500)] <Justin_o> harriswong: okay.. maybe we'll be lucky and that will work better
[11:35:57 CDT(-0500)] <harriswong> Justin_o: beside safari test, i have lightbox errors with IE 9; will dig into that now.
[11:36:17 CDT(-0500)] <harriswong> Justin_o: do you know if layout reorderer 3.10 test on IE 9 is an old error?
[11:38:11 CDT(-0500)] <Justin_o> harriswong: hmm.. not sure, before the upgrades though the reorderer generally didn't work in IE9... seems like a strange one to be happening in isolation.. would have though all of the tests in 3 would have failed...
[11:38:14 CDT(-0500)] <Justin_o> if that one does
[12:10:59 CDT(-0500)] <Justin_o> harriswong: so i went back and tried the unit tests again and they are passing now
[12:11:25 CDT(-0500)] <Justin_o> not sure why.. i had switched to a different branch and come back and now they are working.. maybe it was some sort of caching issue in the browser or something
[12:11:38 CDT(-0500)] <Justin_o> but the framework tests are passing in safari now
[12:12:58 CDT(-0500)] <Justin_o> harriswong: i've updated my comment on the jira
[12:29:43 CDT(-0500)] <harriswong> Justin_o: thanks for the update!
[12:30:00 CDT(-0500)] <Justin_o> harriswong: no problem.... sorry about the confusion there
[12:30:17 CDT(-0500)] <harriswong> Justin_o: nah, just browser problems
[12:35:21 CDT(-0500)] <harriswong> Justin_o: running individual lightbox test seems to pass, but running the suite fails on all but a few.
[12:35:54 CDT(-0500)] <harriswong> Justin_o: do you think this is just an IE9 async problem while running multiple test cases?
[12:37:02 CDT(-0500)] <Justin_o> harriswong: could be
[12:37:15 CDT(-0500)] <Justin_o> or something is wrong with setup/teatdown between tests
[12:37:59 CDT(-0500)] <harriswong> Justin_o: ok i will look at that then.
[13:10:38 CDT(-0500)] <heidi_> jameswy what happens when you make the browser window narrower, for fat panel?
[13:18:22 CDT(-0500)] <jameswy> heidi_: Min-width it
[13:29:25 CDT(-0500)] <Bosmon> Hi, cindyli - can you tell me a little more about the manipulation that UIOptions needs to do before init?
[13:30:18 CDT(-0500)] <Bosmon> And, yura_ - a bit more about your mouse scrolling issue
[13:30:24 CDT(-0500)] <Bosmon> I'm finding it a bit hard to visualise (tongue)
[13:30:29 CDT(-0500)] <cindyli> what do u refer to? manipulation on UIOptions controls?
[13:30:35 CDT(-0500)] <yura_> Bosmon: haha
[13:30:41 CDT(-0500)] <cindyli> or manipulation on the component container?
[13:30:47 CDT(-0500)] <cindyli> that's for ui enhancer
[13:31:03 CDT(-0500)] <yura_> ok so if you remember out autocomplete can be scrollable if there are a lot of matches
[13:31:22 CDT(-0500)] <yura_> you can scroll with the mouse wheel, also move with keyboard down the list
[13:31:50 CDT(-0500)] <yura_> you can/should also be able to use the side scroll bar and mouse to move up/down the list
[13:32:10 CDT(-0500)] <Bosmon> So, your report says, "The blurable element will not fire blur"
[13:32:12 CDT(-0500)] <yura_> now firefox is fine and lets you do it, but chrome and safari are not
[13:32:24 CDT(-0500)] <Bosmon> But what does that mean, exactly...
[13:32:30 CDT(-0500)] <Bosmon> Doesn't it actually mean the opposite of that?
[13:32:34 CDT(-0500)] <yura_> sorry i guess it is confistion
[13:32:40 CDT(-0500)] <yura_> yes
[13:32:42 CDT(-0500)] <Bosmon> Completely confisted
[13:32:47 CDT(-0500)] <Bosmon> And corripped (tongue)
[13:32:48 CDT(-0500)] <yura_> haha
[13:32:53 CDT(-0500)] <yura_> hahahaha
[13:32:55 CDT(-0500)] <yura_> sorry
[13:32:59 CDT(-0500)] <yura_> confusing
[13:33:33 CDT(-0500)] <Bosmon> So I guess what you meant to say is, the element will fire blur - and then fold up the control?
[13:33:38 CDT(-0500)] <Bosmon> When the user tries to scroll in it?
[13:34:51 CDT(-0500)] <heidi_> jameswy what's a reasonable min-width in general?
[13:35:06 CDT(-0500)] <heidi_> lizna have input on that?
[13:35:08 CDT(-0500)] <jameswy> heidi_: In general? Or for UIO fat panel?
[13:35:37 CDT(-0500)] <heidi_> jameswy both ?
[13:36:14 CDT(-0500)] <jameswy> heidi_: I'd prefer to go by what the minimum display width on desktop screens is--which is 1024x; a min width of 960 should suffice.
[13:36:59 CDT(-0500)] <heidi_> jameswy k, might have to make the slider's narrow, but should be do-able, thanks
[13:37:20 CDT(-0500)] <jameswy> heidi_: Yes. The sliders are in fact more narrow in the designs.
[13:37:30 CDT(-0500)] <heidi_> jameswy btw this is handy dandy: https://addons.mozilla.org/en-us/firefox/addon/firesizer/
[13:37:42 CDT(-0500)] <athena1> anyone around that might be able to answer a few questions about infusion 1.4 and events?
[13:40:03 CDT(-0500)] <athena1> trying to test uportal w/ the current trunk, but it looks like we have some errors
[13:40:16 CDT(-0500)] <Bosmon> yura_? ^
[13:40:46 CDT(-0500)] <athena1> should most things be backwards compatible, or is it just that we have some work to do to update?
[13:41:38 CDT(-0500)] <yura_> athena1: i might be able to help. there might be some restrictions now in case events blocks are passed around between components
[13:41:52 CDT(-0500)] <athena1> sounds like that might be related
[13:42:13 CDT(-0500)] <athena1> we're currently getting things like "Listener registered for event onError which is not defined for this component"
[13:42:56 CDT(-0500)] <athena1> which i think i've tracked down to an event in one of our components that's used by another component
[13:42:58 CDT(-0500)] <yura_> athena1: yes I think currently you cant
[13:43:08 CDT(-0500)] <yura_> pass the whole events block as an option
[13:43:45 CDT(-0500)] <athena1> is there another way we should be configuring event listeners on subcomponents?
[13:45:02 CDT(-0500)] <Bosmon> Hi yura_, I actually meant the earlier point
[13:45:06 CDT(-0500)] <Bosmon> I can take this framework question (smile)
[13:45:16 CDT(-0500)] <Bosmon> athena1 - in order to register a listener for an event, there actually needs to be an event (smile)
[13:45:18 CDT(-0500)] <yura_> Bosmon: sure thanks
[13:45:39 CDT(-0500)] <yura_> Bosmon: yes exactly
[13:45:49 CDT(-0500)] <Bosmon> This was a change in trunk recently, I noticed that the former framework would actually "auto-create" events if it happened that there was a listener found
[13:45:50 CDT(-0500)] <athena1> i have a listeners block in the fluid.defaults for the component - commenting that out makes that error go away
[13:45:58 CDT(-0500)] <athena1> ah (smile)
[13:46:00 CDT(-0500)] <Bosmon> But I think that this behaviour is too error-prone
[13:46:06 CDT(-0500)] <athena1> so how does one create an event?
[13:46:13 CDT(-0500)] <Bosmon> Although we should probably debate it one more time before this behaviour goes to release
[13:46:21 CDT(-0500)] <Bosmon> You need to create an entry in the "events" block of the component
[13:46:23 CDT(-0500)] <athena1> i think perhaps i'd misunderstood event creation as just being creating a listener in the defaults
[13:46:28 CDT(-0500)] <Bosmon> In this case something like events: {
[13:46:31 CDT(-0500)] <yura_> Bosmon: because i guess it registers a click somehow on the scroll bar out side of the exclusion
[13:46:32 CDT(-0500)] <Bosmon> onError: null
[13:46:32 CDT(-0500)] <Bosmon> }
[13:46:36 CDT(-0500)] <athena1> hm
[13:46:45 CDT(-0500)] <athena1> is that in the fluid.defaults block?
[13:46:50 CDT(-0500)] <Bosmon> athena1 - that's right
[13:46:54 CDT(-0500)] <athena1> oh ok
[13:47:03 CDT(-0500)] <athena1> so i should just be using "events" instead of "listeners" there?
[13:47:09 CDT(-0500)] <Bosmon> You need both
[13:47:12 CDT(-0500)] <Bosmon> Firstly you need to create an event
[13:47:16 CDT(-0500)] <athena1> ohh.
[13:47:17 CDT(-0500)] <Bosmon> And then register a listener for the event
[13:47:26 CDT(-0500)] <athena1> both in the defaults?
[13:47:35 CDT(-0500)] <athena1> what's the difference between the two?
[13:47:37 CDT(-0500)] <Bosmon> Now there are more choices for "where events come from" it's important to get this right (tongue)
[13:47:50 CDT(-0500)] <Bosmon> You can put them both in defaults, yes
[13:48:01 CDT(-0500)] <Bosmon> Although ultimately it doesn't matter how they get delivered to the component instance
[13:48:18 CDT(-0500)] <Bosmon> The entry in "events" says.... the IS an event with this name!
[13:48:35 CDT(-0500)] <Bosmon> there is
[13:48:40 CDT(-0500)] <athena1> so what would the event be set to if it were not null? or is it always null?
[13:48:59 CDT(-0500)] <Bosmon> http://wiki.fluidproject.org/display/fluid/Infusion+Event+System
[13:49:02 CDT(-0500)] <Bosmon> The choices are explained here
[13:49:06 CDT(-0500)] <Bosmon> At least some of them
[13:49:08 CDT(-0500)] <athena1> ah, thank you!
[13:49:16 CDT(-0500)] <athena1> ok, i remember seeing this stuff before
[13:49:20 CDT(-0500)] <athena1> terrific
[13:49:20 CDT(-0500)] <Bosmon> If you put a literal value on the RHS like "null" it means... THIS EVENT IS CREATED HERE
[13:49:26 CDT(-0500)] <athena1> this looks like it would be really easy to fix
[13:49:31 CDT(-0500)] <Bosmon> Now we have IoC, it is actually possible to have events injected from other components
[13:49:47 CDT(-0500)] <Bosmon> And the "auto-create" behaviour often just masks errors where you misspell an event name
[13:49:48 CDT(-0500)] <athena1> yeah, i'm really looking forward to working w/ the new IoC stuff
[13:49:57 CDT(-0500)] <athena1> makes sense
[13:50:02 CDT(-0500)] <athena1> that sounds reasonable to me
[13:50:11 CDT(-0500)] <athena1> are you presenting about any of the IoC changes at jasig?
[13:50:17 CDT(-0500)] <Bosmon> Yes, I will talk about them a bit
[13:50:25 CDT(-0500)] <athena1> terrific
[13:50:31 CDT(-0500)] <Bosmon> Clayton just gave a mini-workshop talk at CHI at Vancouver yesterday
[13:50:37 CDT(-0500)] <Bosmon> So he will also be prepped for IoC chat (tongue)
[13:50:39 CDT(-0500)] <athena1> maybe we can buy you a beer and make you talk about it in more detail (smile)
[13:50:52 CDT(-0500)] <athena1> (smile)
[13:50:54 CDT(-0500)] <Bosmon> Sure, I can't think of things I am more likely to talk about
[13:51:01 CDT(-0500)] <Bosmon> Beer will not be necessary, but welcome (tongue)
[13:51:09 CDT(-0500)] <athena1> i figured (tongue)
[13:51:21 CDT(-0500)] <colinclark> Beer isn't a necessity?
[13:51:21 CDT(-0500)] <Bosmon> yura_ - do you have a demo page that shows the behaviour?
[13:51:29 CDT(-0500)] <yura_> nightly has it
[13:51:34 CDT(-0500)] <yura_> any autocomplete
[13:51:35 CDT(-0500)] <Bosmon> I guess it's interesting that the scrollbar is not considered part of the excluded component
[13:51:42 CDT(-0500)] <Bosmon> I wonder what it is part of
[13:52:05 CDT(-0500)] <Bosmon> colinclark - we should make a note to review auto-create behaviour before 1.4 release
[13:52:17 CDT(-0500)] <Bosmon> Is FISH back for the Dev Meeting this Wednesday?
[13:52:23 CDT(-0500)] <Bosmon> yura_ - URL?
[13:52:24 CDT(-0500)] <colinclark> I dunno
[13:52:28 CDT(-0500)] <colinclark> let me check the calendar
[13:52:34 CDT(-0500)] <yura_> http://nightly.collectionspace.org:8180/collectionspace/ui/html
[13:52:48 CDT(-0500)] <colinclark> Looks like michelled's first day back is Wednesday
[13:52:50 CDT(-0500)] <colinclark> so yes
[13:53:52 CDT(-0500)] <Bosmon> cool
[13:53:58 CDT(-0500)] <Bosmon> We should ad it to the aggenda then
[13:54:00 CDT(-0500)] <athena1> actually Bosmon i'll buy you the beer i owe colinclark for IE6 not being dead yet
[13:54:16 CDT(-0500)] <Bosmon> What was the criterion for "being dead"? (tongue)
[13:54:20 CDT(-0500)] <Bosmon> I mean, it is dead in some senses
[13:54:21 CDT(-0500)] <colinclark> Beer is now officially on the agenda
[13:54:24 CDT(-0500)] <Bosmon> Given Google has declared it dead
[13:54:34 CDT(-0500)] <Bosmon> But it is not dead in the sense that it still has > 4% market share
[13:54:39 CDT(-0500)] <athena1> apparently if it was still supported in fluid or uportal as of 011
[13:54:42 CDT(-0500)] <athena1> er, 2011
[13:54:44 CDT(-0500)] <Bosmon> ha
[13:54:57 CDT(-0500)] <Bosmon> I will lay you a beer it will still be supported in Fluid in 2012 too
[13:55:05 CDT(-0500)] <athena1> yeah
[13:55:11 CDT(-0500)] <colinclark> I guess only Justin_o knows for sure
[13:55:14 CDT(-0500)] <athena1> i think we both agreed it was actually probably going to be supported
[13:55:30 CDT(-0500)] <athena1> but i said i'd buy beer at that point because we'd need it as consolation
[13:55:31 CDT(-0500)] <athena1> (smile)
[13:55:33 CDT(-0500)] <Bosmon> hahaha
[13:55:33 CDT(-0500)] <Bosmon> great
[13:55:44 CDT(-0500)] <Bosmon> I think a reasonable criterion for supporting a browser is about the 1% market level
[13:55:51 CDT(-0500)] <Bosmon> Which will take a LONG time still to reach from here
[13:56:05 CDT(-0500)] <athena1> i will happily make that same arrangement for 2012
[13:56:21 CDT(-0500)] <athena1> i think the biggest problem w/ IE6 is that people who are still using it often can't upgrade
[13:56:29 CDT(-0500)] <Bosmon> We have supported Opera for years on that basis
[13:56:32 CDT(-0500)] <athena1> stupid corporate environments or old machines or whatever
[13:56:51 CDT(-0500)] <athena1> i would imagine supporting opera involves less pain and suffering
[13:56:52 CDT(-0500)] <Bosmon> I saw an interesting diagram that showed that Opera has had roughly a constant 1% share since around 1997 (tongue)
[13:57:12 CDT(-0500)] <Bosmon> Somewhat less, yes, but it is still packed with some suitably bizarre oddities and bugs
[13:57:18 CDT(-0500)] <Bosmon> Mainly with keyboard handling
[13:57:30 CDT(-0500)] <Bosmon> The true IE horror, across ALL versions.... is FOCUS
[13:57:33 CDT(-0500)] * athena1 choses to pretend firefox is the one and only browser
[13:57:41 CDT(-0500)] <Bosmon> It is just so horribly and utterly illogical and broken
[13:57:56 CDT(-0500)] <Bosmon> We now have a component, "dead man's blur" that needs to somehow "jaunt back in time"
[13:58:16 CDT(-0500)] <Bosmon> To deal with the case in IE where it fires focus and blur in the wrong order on a collection of components
[13:58:23 CDT(-0500)] <athena1> ack.
[13:58:33 CDT(-0500)] <athena1> that sounds kind of terrifying (smile)
[13:58:34 CDT(-0500)] <Bosmon> It has a "reverse time window" and a "forwards time window"
[13:58:41 CDT(-0500)] <Bosmon> Much like the last episode of FRINGE (tongue)
[13:58:52 CDT(-0500)] <Bosmon> And further, it is impossible to write a test case for
[13:59:04 CDT(-0500)] <athena1> neat
[13:59:08 CDT(-0500)] <Bosmon> Since the behaviour of focus/blur is even FURTHER broken in synthetic cases on IE
[13:59:18 CDT(-0500)] <Bosmon> You just have to "try it and observe that it generally seems to work"
[13:59:49 CDT(-0500)] <athena1> haha
[13:59:57 CDT(-0500)] <athena1> that sounds like my lame attempt at doing my homework yesterday
[13:59:58 CDT(-0500)] <Bosmon> Unfortunately this is broken on IE8 too, so i guess we will be supporting this component till 2016 at least
[14:00:17 CDT(-0500)] <Bosmon> Perhaps if we can get "robot tests" working we could have more confidence in it
[14:00:30 CDT(-0500)] <Bosmon> What is your homework on?
[14:00:50 CDT(-0500)] <athena1> algorithms - this week is longest common subsequence
[14:01:02 CDT(-0500)] <Bosmon> Excellent
[14:01:05 CDT(-0500)] <athena1> but my brain was not really functioning yesterday
[14:01:08 CDT(-0500)] <athena1> and also it was sunny
[14:01:25 CDT(-0500)] <Bosmon> Every infinite sock has a longest common subsock (smile)
[14:01:49 CDT(-0500)] <athena1> though i would think that a noncontinuous sock wouldn't do anyone much good
[14:01:50 CDT(-0500)] <Bosmon> yura_ - thanks, wow, that URL didn't even change since last time (smile)
[14:02:05 CDT(-0500)] <yura_> (smile)
[14:02:36 CDT(-0500)] <Bosmon> I notice that myCollectionSpace still takes FOREVER to load
[14:03:30 CDT(-0500)] <Bosmon> Ah, I guess it is all the IOC debugging messages
[14:04:16 CDT(-0500)] <Bosmon> yura_ - the scrollbar seems to work fine for me
[14:04:20 CDT(-0500)] <Bosmon> Is this perhaps just a problem with FF 4?
[14:23:28 CDT(-0500)] <yura_> Bosmon: chrome for sure fails for me
[14:23:38 CDT(-0500)] <Bosmon> ok, I thought it was FF only
[14:24:26 CDT(-0500)] <Bosmon> WHy is there a small Flash control at the base of the page? (tongue)
[14:26:23 CDT(-0500)] <yura_> ?
[14:26:56 CDT(-0500)] <Bosmon> Well, I have FlashBlock installed... and it shows me that there is a little control there...
[14:27:17 CDT(-0500)] <Bosmon> Perhaps it is something created by ProgressiveEnhancement...
[14:35:36 CDT(-0500)] <colinclark> Hi Bosmon
[14:35:40 CDT(-0500)] <colinclark> Do you have a few minutes to chat?
[14:35:47 CDT(-0500)] <colinclark> Or are you in the midst of working with yura_?
[14:44:57 CDT(-0500)] <Bosmon> Hi colinclark - can you give me 10 mins?
[14:45:05 CDT(-0500)] <colinclark> yep
[14:45:11 CDT(-0500)] <Bosmon> cool
[14:45:19 CDT(-0500)] <colinclark> I thought we could start by typing here about your options chewing email
[14:45:24 CDT(-0500)] <colinclark> whenever you've got time
[14:45:26 CDT(-0500)] <Bosmon> ok
[14:45:39 CDT(-0500)] <Bosmon> I guess the issue is tradeoffs
[14:45:53 CDT(-0500)] <Bosmon> Clearly we should "get this working" but the question is whether we have higher priority stuff to do
[14:46:23 CDT(-0500)] <Bosmon> There are at least 2 configurations demonstrated now where IoC can get this working right - even if perhaps our favorite one isn't working
[14:46:30 CDT(-0500)] <Bosmon> Assuming that the one you wrote really is your favorite one (smile)
[14:46:44 CDT(-0500)] <colinclark> I'm fairly perplexed by the version that does work
[14:46:48 CDT(-0500)] <Bosmon> Certainly there's a lot to be said for supporting "the first thing that comes to someone's mind when they try something"
[14:46:54 CDT(-0500)] <colinclark> though I don't think I'd claim to have favourites
[14:47:04 CDT(-0500)] <colinclark> So my mental model was this...
[14:47:23 CDT(-0500)] <colinclark> that there was some new special zone in the options for a component
[14:47:27 CDT(-0500)] <colinclark> called "transformOptions"
[14:47:53 CDT(-0500)] <Bosmon> Right
[14:47:55 CDT(-0500)] <colinclark> which, if somehow added to the configuration of a component, would cause those options to be transformed based on my specification
[14:48:05 CDT(-0500)] <colinclark> Your version probably never would have occurred to me
[14:48:13 CDT(-0500)] <Bosmon> Well, it wouldn't have occurred to anyone
[14:48:15 CDT(-0500)] <colinclark> in that, not only, I guess, is there this special zone...
[14:48:22 CDT(-0500)] <Bosmon> It was implemented that way because I thought there was no alternative
[14:48:26 CDT(-0500)] <colinclark> there must be, somewhere hidden in the machinery...
[14:48:32 CDT(-0500)] <colinclark> some component called fluid.transformOptions?
[14:48:36 CDT(-0500)] <athena1> Bosmon: thanks for the help with the events - think i'm past all that now (smile)
[14:48:48 CDT(-0500)] <athena1> though any chance there are some pager changes i should know about as well?
[14:48:53 CDT(-0500)] <Bosmon> But in experimenting last night I found I probably could support something like what you wanted, although I'm concerned about how reliable it is
[14:49:10 CDT(-0500)] <Bosmon> athena1 - great, glad we could get that sorted out - there shouldn't be any pager changes, we haven't had time to work on that this release
[14:49:21 CDT(-0500)] <Bosmon> Although if there are any "urgent quick fixes" we can do you should let us know
[14:49:23 CDT(-0500)] <athena1> hmm, ok, i'll take a look then
[14:49:27 CDT(-0500)] <Bosmon> colinclark - Actually not even a real component
[14:49:36 CDT(-0500)] <colinclark> ahhhh
[14:49:40 CDT(-0500)] <Bosmon> What I implemented was a quite custom kind of "juggling of demands blocks"
[14:49:43 CDT(-0500)] <athena1> currently getting "columnDef" is undefined errors, which seems sorta weird
[14:49:48 CDT(-0500)] <Bosmon> Which even required the IoC resolution system to be refactored a bit
[14:49:50 CDT(-0500)] <colinclark> athena1: Pager hasn't seen much in the way of love recently...
[14:49:57 CDT(-0500)] <colinclark> so if you're seeing stuff, it's vaguely possible it's a regression
[14:50:02 CDT(-0500)] <colinclark> or "luck"
[14:50:11 CDT(-0500)] <Bosmon> If you look at the impl, you can see it just "queries in the raw" for a demands block for fluid.transformOptions
[14:50:13 CDT(-0500)] <Bosmon> And decodes what it sees
[14:50:17 CDT(-0500)] <colinclark> Bosmon: Okay, from the user perspective, then...
[14:50:25 CDT(-0500)] <colinclark> I'm just to assume that there is a magical component
[14:50:31 CDT(-0500)] <colinclark> if I refer to it in a demands block
[14:50:37 CDT(-0500)] <colinclark> awesomeness happens?
[14:50:42 CDT(-0500)] <Bosmon> Yes
[14:50:45 CDT(-0500)] <colinclark> Okay
[14:50:49 CDT(-0500)] <Bosmon> That was the first version I pasted in my mail
[14:50:54 CDT(-0500)] <colinclark> yes
[14:50:54 CDT(-0500)] <Bosmon> "Just do this, and that will happen"
[14:50:59 CDT(-0500)] <colinclark> So, I think we're probably both in unspoken agreement...
[14:51:03 CDT(-0500)] <Bosmon> But as you say, there isn't any particular logic to this
[14:51:15 CDT(-0500)] <colinclark> we're in the "get it working" stage for options chewing stage again any way
[14:51:20 CDT(-0500)] <colinclark> yes, as far as particular logic...
[14:51:20 CDT(-0500)] <Bosmon> And it's nothing that someone would think of, knowing about the presence of the "transformOptions" block
[14:51:27 CDT(-0500)] <colinclark> I imagine I never would have gotten it working
[14:51:37 CDT(-0500)] <Bosmon> Well, you could have just copied the test case (smile)
[14:51:39 CDT(-0500)] <colinclark> even with a lot of monkeys, or cats, typing on my keyboard
[14:51:55 CDT(-0500)] <colinclark> sure, but that would have involved no thought whatsoever (tongue)
[14:52:10 CDT(-0500)] <Bosmon> And read the nonexistent documentation
[14:52:14 CDT(-0500)] <colinclark> (smile)
[14:52:28 CDT(-0500)] <Bosmon> Anyway, I guess this was just the sort of experiment we needed to do
[14:52:37 CDT(-0500)] <colinclark> What I wrote was-I thought-a translation of the spirit of those tests to the particular context of the Uploader
[14:52:50 CDT(-0500)] <Bosmon> And I guess the results of the experiment is that the "special track" for fluid.transformOptions is not really what people expect
[14:53:00 CDT(-0500)] <colinclark> I think that's true, yes
[14:53:07 CDT(-0500)] <colinclark> So maybe let's file a bug
[14:53:10 CDT(-0500)] <colinclark> and then keep moving
[14:53:14 CDT(-0500)] <Bosmon> ok
[14:53:16 CDT(-0500)] <colinclark> I like your refinements to the test itself
[14:53:21 CDT(-0500)] <colinclark> The labels
[14:53:26 CDT(-0500)] <Bosmon> Shall we just merge in my "ii" branch then?
[14:53:33 CDT(-0500)] <Bosmon> On the grounds that it is "generally working for now"?
[14:53:36 CDT(-0500)] <colinclark> I chuckled at your change from a for loop to fluid.each()
[14:53:39 CDT(-0500)] <colinclark> yes
[14:53:40 CDT(-0500)] <colinclark> +1
[14:53:48 CDT(-0500)] <Bosmon> Why was it chucklesome? (tongue)
[14:53:53 CDT(-0500)] <Bosmon> ok cool
[14:54:10 CDT(-0500)] <colinclark> Well, I have really only had time to write code recently on my own time
[14:54:39 CDT(-0500)] <colinclark> and as you know, the performance requirements of Flocking rule out the use of luxuries such as fluid.each() (tongue)
[14:54:46 CDT(-0500)] <Bosmon> ha
[14:55:35 CDT(-0500)] <Bosmon> Perhaps we should just abolish my solution for "fluid.transformOptions"?
[14:55:44 CDT(-0500)] <Bosmon> The one that uses the "funkily encoded demands block"?
[14:56:08 CDT(-0500)] <colinclark> huh?
[14:56:30 CDT(-0500)] <Bosmon> Although I guess there's an issue with using your method universally
[14:56:39 CDT(-0500)] <Bosmon> As you know, only ONE demands block can win, for a particular scenario
[14:57:00 CDT(-0500)] <Bosmon> And if someone wants to say that they want options transformed, and the situation ALREADY has a demands block matching it
[14:57:05 CDT(-0500)] <Bosmon> Then they have nowhere to put their options
[14:57:16 CDT(-0500)] <colinclark> yes, that's an issue
[14:57:25 CDT(-0500)] <colinclark> what was your "funkily encoded demands block?"
[14:57:38 CDT(-0500)] <Bosmon> The one that issues a demand against a component apparently called "fluid.transformOptions"
[14:57:41 CDT(-0500)] <athena1> Bosmon: looks like my current issue is due to not defining annotateColumnRange
[14:57:42 CDT(-0500)] <Bosmon> Even though no such component really exists
[14:57:50 CDT(-0500)] <colinclark> ah
[14:57:56 CDT(-0500)] <colinclark> Well, I guess it's not our ideal solution, no
[14:58:03 CDT(-0500)] <colinclark> but we need to talk through the alternatives
[14:58:15 CDT(-0500)] <Bosmon> I'm not sure I can think of any (smile)
[14:58:20 CDT(-0500)] <colinclark> hmm
[14:58:21 CDT(-0500)] <Bosmon> But imagination hasn't been my strong point recently
[14:58:25 CDT(-0500)] <colinclark> lol
[14:58:33 CDT(-0500)] <colinclark> Well, okay
[14:58:39 CDT(-0500)] <colinclark> let's leave your funk for 1.4
[14:58:43 CDT(-0500)] <colinclark> I'll file a bug
[14:58:55 CDT(-0500)] <colinclark> we'll revisit this for 1.5
[14:59:15 CDT(-0500)] <Bosmon> This is a provisional addition, to a feature area which is already itself all "sneak peek"
[14:59:22 CDT(-0500)] <Bosmon> So hopefully people will not flay us alive if we change it
[15:01:21 CDT(-0500)] <Bosmon> athena1 - I see that there have been some changes to the pager recently
[15:01:26 CDT(-0500)] <Bosmon> Which I'm not sure that I entirely approve
[15:01:31 CDT(-0500)] <Bosmon> it seems it has some default values for options now
[15:01:50 CDT(-0500)] <Bosmon> Which are meaningless since they refer to data which may not exist
[15:01:52 CDT(-0500)] <Bosmon> "column1" etc.
[15:01:59 CDT(-0500)] <Bosmon> Do you know who has been working on that, colinclark?
[15:02:06 CDT(-0500)] <athena1> yeah it looks like you have to define annotateColumnRange or it tips over
[15:02:12 CDT(-0500)] <athena1> but once i defined that it works as expected
[15:03:26 CDT(-0500)] <Bosmon> We should make this a blocker for 1.4
[15:03:40 CDT(-0500)] <athena1> so we're not supposed to need to define that?
[15:03:50 CDT(-0500)] <Bosmon> We can't ship a version of Pager that breaks by default...
[15:03:53 CDT(-0500)] <athena1> do we want to define it, or is it just supposed to be optional?
[15:04:12 CDT(-0500)] <Bosmon> athena1 - I can't answer at the moment - we will need to look into what has happened here
[15:04:15 CDT(-0500)] <athena1> ok (smile)
[15:04:17 CDT(-0500)] <colinclark> Bosmon: The last changes I notice to Pager.js are from harriswong, based on merging in EricDalquist's gappedPageStrategy
[15:04:40 CDT(-0500)] <colinclark> or rather, "consistentGappedPageStrategy"
[15:04:52 CDT(-0500)] <Bosmon> These must be older changes then
[15:04:55 CDT(-0500)] <colinclark> michelled committed some changes from the King to Pager's defaults
[15:05:03 CDT(-0500)] <colinclark> Back in January
[15:05:06 CDT(-0500)] <Bosmon> Perhaps in work on "make the self-rendered version of the pager the default"?
[15:05:11 CDT(-0500)] <Bosmon> Or did I just implement this myself and forget about it
[15:05:17 CDT(-0500)] <Bosmon> We need some kind of "git blame"....
[15:05:28 CDT(-0500)] <colinclark> It's probably those changes, yes
[15:05:49 CDT(-0500)] <Bosmon> I don't have an "annotate" option any more in Eclipse for git (tongue)
[15:06:06 CDT(-0500)] <Bosmon> But hopefully we can track when the current line 896 of Pager.js was put in
[15:06:19 CDT(-0500)] <athena1> well, i can just put the property in all our pager thingies for now
[15:06:29 CDT(-0500)] <Bosmon> Well, we won't go to release like this
[15:06:30 CDT(-0500)] <athena1> and then we can evaluate whether we want to define the property or not depending on what you find
[15:06:33 CDT(-0500)] <Bosmon> So don't worry about it too much (tongue)
[15:06:42 CDT(-0500)] <colinclark> Yeah, it looks like those changes happened in 5c50980c58cb59498c187d8871c2e50c5ebf7a79
[15:06:46 CDT(-0500)] <Bosmon> Are you using trunk because you need some fixes?
[15:06:48 CDT(-0500)] <colinclark> Which would have been for 1.3.1, if I remember
[15:07:01 CDT(-0500)] <athena1> i think we'd like to use 1.4 in uportal 4
[15:07:11 CDT(-0500)] <Bosmon> ok, we will work extra hard to make it great (smile)
[15:07:22 CDT(-0500)] <athena1> so trying to evaluate and see if we have any blockers or if anything major comes up
[15:07:31 CDT(-0500)] <athena1> i usually do try to do an upgrade to a version before you cut a release
[15:07:37 CDT(-0500)] <Bosmon> That's great, athena1, we appreciate it
[15:07:42 CDT(-0500)] <athena1> since it seems more helpful to find problems before something's actually released (smile)
[15:07:56 CDT(-0500)] <athena1> but also we'd love to pick up the results of the CSS work gary's done with you guys
[15:08:18 CDT(-0500)] <athena1> so the immediate effort is to get uportal working w/ the current trunk so that gary can do testing and get all our CSS back in line with what's been done in fluid (smile)
[15:08:20 CDT(-0500)] <colinclark> sorry, my commit hash was wrong, Bosmon
[15:08:34 CDT(-0500)] <colinclark> no, it was right
[15:08:39 CDT(-0500)] <colinclark> commit hashes suck (tongue)
[15:08:50 CDT(-0500)] <Bosmon> aha, there is a "blame" on gituhb
[15:08:52 CDT(-0500)] <athena1> what's your timeline looking like for 1.4?
[15:08:52 CDT(-0500)] <Bosmon> cool
[15:09:03 CDT(-0500)] <colinclark> So what's the actual problem?
[15:09:06 CDT(-0500)] <colinclark> I wasn't following
[15:09:30 CDT(-0500)] <Bosmon> colinclark - I think your hash is correct
[15:09:52 CDT(-0500)] <Bosmon> colinclark - the default configuration for the pager is now one that doesn't work
[15:09:59 CDT(-0500)] <Bosmon> it refers to columns and data which don't exist
[15:10:15 CDT(-0500)] <jhung> jameswy, heidi_: posted demo designs here: http://wiki.fluidproject.org/display/fluid/User+interface+options%2C+Infusion+1.4+demo+pages+mockup
[15:10:23 CDT(-0500)] <colinclark> Let's ask the King why he made the change when he's in tomorrow
[15:10:26 CDT(-0500)] <Bosmon> https://github.com/fluid-project/infusion/commit/5c50980c58cb59498c187d8871c2e50c5ebf7a79
[15:10:27 CDT(-0500)] <colinclark> I'm sure he had a reason
[15:10:36 CDT(-0500)] <Bosmon> Well, we had a JIRA which said to do it (smile)
[15:10:42 CDT(-0500)] <Bosmon> That was probably at least part of the reason
[15:11:10 CDT(-0500)] <Bosmon> I guess the Pager always needs some configuration in order to work
[15:11:30 CDT(-0500)] <Bosmon> But its previous behaviour, if not everything to be configured, was to do nothing
[15:11:33 CDT(-0500)] <Bosmon> Whereas now it fails
[15:14:14 CDT(-0500)] <colinclark> Bosmon: Okay, so will push your FLUID-4174-ii branch shortly to the project repo?
[15:14:46 CDT(-0500)] <Bosmon> Yes, this evening
[15:14:54 CDT(-0500)] <Bosmon> So I guess I won't abolish "fluid.transformOptions" for now
[15:14:58 CDT(-0500)] <Bosmon> In the presence of lack of imagination
[15:15:00 CDT(-0500)] <colinclark> not for now
[15:15:07 CDT(-0500)] <colinclark> As I say, let's revisit it for 1.5
[15:15:10 CDT(-0500)] <colinclark> I
[15:15:17 CDT(-0500)] <colinclark> I'm filing a bug about its confusing-ness now
[15:15:26 CDT(-0500)] <Bosmon> Thanks, colinclark
[15:17:16 CDT(-0500)] <colinclark> Bosmon: Once your branch is in, I'm going to refactor the tests in ModelTransformation.js to not use Uploader-specific options...
[15:17:37 CDT(-0500)] <colinclark> that'll get rid of some unnecessary duplication as well as extra complexity in those tests
[15:18:01 CDT(-0500)] <colinclark> And that'll also set the stage for mlam's fileTypes branch
[15:18:07 CDT(-0500)] <colinclark> Bosmon: Is there any reason you can't push that branch now?
[15:18:42 CDT(-0500)] <colinclark> If so, I can do it for you
[15:30:18 CDT(-0500)] <Bosmon> ok
[15:30:23 CDT(-0500)] <Bosmon> It was just a matter of getting round to it (tongue)
[16:01:15 CDT(-0500)] <Bosmon> Just to close the loop on yura_'s dead man's blur issue
[16:01:31 CDT(-0500)] <Bosmon> It appears that Chrome does not deliver either click or focus events when the user operates a browser-generated scrollbar
[16:04:04 CDT(-0500)] <Bosmon> I found this Chromium bug: https://code.google.com/p/chromium/issues/detail?id=6759
[16:05:58 CDT(-0500)] <Bosmon> But this one gives a clue to a solution: http://code.google.com/p/chromium/issues/detail?id=14204
[16:06:22 CDT(-0500)] <Bosmon> It appears that, anomalously, "mousedown" events are fired by these synthetic controls
[16:14:07 CDT(-0500)] <Bosmon> I've voted and commented on Chrome bug 14204 for us
[16:14:33 CDT(-0500)] <Bosmon> In the meantime I will update FluidView to include "mousedown" in the set of events used by dead man's blur for cancellation
[16:21:06 CDT(-0500)] <athena1> Bosmon: checking in our update to pre-1.4 now so that we can do more testing and pull the CSS together
[16:21:09 CDT(-0500)] <athena1> thanks so much for all the help (smile)
[16:21:11 CDT(-0500)] <athena1> really appreciate it