[08:24:27 CDT(-0500)] <heidi_> hey Justin_o fyi i'm finishing up fluid-4362 <heidi_> cindyli if you put it on the options, does it work? select option <cindyli> heidi_: what i did - .fl-uiOptions #theme option
[08:24:40 CDT(-0500)] <heidi_> and also i still owe you $20 - forgot to leave it last time i was in! be there thurs
[08:26:01 CDT(-0500)] <Justin_o> heidi_: thanks no problem..
[08:48:52 CDT(-0500)] <heidi_> Justin_o any other styling bugs i should look at after this one?
[08:49:26 CDT(-0500)] <heidi_> 4412 looks tricky
[08:57:46 CDT(-0500)] <Justin_o> heidi_: yes.. probably.. we need to redesign the portal, the iframe is too small
[08:58:46 CDT(-0500)] <heidi_> Justin_o the iframe for the fat panel is using the width of the entire page instead of the iframe it's within i think. not sure why
[09:00:40 CDT(-0500)] <Justin_o> that's interesting.. how would it know that though
[09:01:55 CDT(-0500)] <heidi_> Justin_o not sure, maybe i'm wrong. just not sure why width:100% for iframe is larger than ...the iframe
[09:03:45 CDT(-0500)] <Justin_o> yah.. i don't know enough about iframes yet
[09:06:20 CDT(-0500)] <heidi_> Justin_o do you recall why fat panel doesn't you fss-base ? the other 2 UIO's do
[09:06:27 CDT(-0500)] <heidi_> doesn't *use
[09:06:50 CDT(-0500)] <Justin_o> heidi_: not sure
[09:07:51 CDT(-0500)] <heidi_> Justin_o makes for annoying inconsistencies between the 3. fat panel seems to be adding stuff that base has
[09:08:08 CDT(-0500)] <heidi_> but it lives within UIOptions.css so there's unnecessary overlap for the other 2
[09:08:56 CDT(-0500)] <Justin_o> heidi_:
[09:09:03 CDT(-0500)] <Justin_o> we should get rid of that
[09:09:17 CDT(-0500)] <heidi_> Justin_o i'll try adding base to fatpanel and seeing how badly it breaks :o
[09:09:39 CDT(-0500)] <Justin_o> heidi_: okay. let me know.. i'll cross my fingers
[09:09:54 CDT(-0500)] <Justin_o> i think there may have been a reason to drop it though.. but i can't quite recall now
[09:09:54 CDT(-0500)] <Justin_o> '
[09:10:54 CDT(-0500)] <heidi_> Justin_o minor tweaks needed but it seems fine
[09:11:10 CDT(-0500)] <Justin_o> heidi_: okay.. that's good
[09:32:23 CDT(-0500)] <Justin_o> michelled, yura, heidi_ : looks like you have the last remaining blockers.. did any of you need help?
[09:32:49 CDT(-0500)] <michelled> Justin_o: I think I will but I need a few more minutes before I can bring someone into it
[09:33:03 CDT(-0500)] <michelled> Justin_o: I have an attempt at the fix but it's not working as I expected
[09:33:26 CDT(-0500)] <michelled> Justin_o: I think I'll need help picking through the generated style sheets to determine what went wrong
[09:33:29 CDT(-0500)] <heidi_> Justin_o mine's blossoming into a bigger css cleanup
[09:33:35 CDT(-0500)] <heidi_> but it's going ok
[09:33:36 CDT(-0500)] <michelled> I should be able to push what I've got pretty soon
[09:33:43 CDT(-0500)] <yura> Justin_o: i m about to try really start looking into it, had to switch to cspace last friday
[09:33:55 CDT(-0500)] <Justin_o> yura: okay..
[09:34:08 CDT(-0500)] <Justin_o> michelled: okay.. sounds scary..
[09:34:18 CDT(-0500)] <heidi_> Justin_o the button reset that cindyli emailed about - is that in the newest YUI?
[09:34:33 CDT(-0500)] <Justin_o> heidi_: not sure
[09:34:56 CDT(-0500)] <Justin_o> we'll have to double check there were a few changes between our version and the latest, but i can't remember
[09:34:59 CDT(-0500)] <Justin_o> what they were
[09:35:01 CDT(-0500)] <heidi_> Justin_o cindyli if it is, then yes we should update. maybe there are other 'new' tags that have defaults we'd want to reset
[09:35:30 CDT(-0500)] <heidi_> Justin_o the button reset was necessary for UIO to work correctly (the links to the other UIO's on the demo weren't resizing/line-height)
[09:35:36 CDT(-0500)] <Justin_o> cindyli: what are you working on at the moment by the way
[09:35:38 CDT(-0500)] <Justin_o> ?
[09:36:15 CDT(-0500)] <cindyli> Justin_o: just sent a pull request on 4356 minutes ago
[09:36:37 CDT(-0500)] <cindyli> Justin_o: probably you or michelled can have a code review
[09:37:11 CDT(-0500)] <cindyli> now scanning thru the list. the next i may take on 4410 or 4426. not decided yet
[09:39:20 CDT(-0500)] <cindyli> Justin_o: taking 4410
[09:39:25 CDT(-0500)] <cindyli> as my next
[09:42:30 CDT(-0500)] <Justin_o> cindyli: okay, thanks
[09:43:00 CDT(-0500)] <yura> heidi_: ayt?
[09:43:14 CDT(-0500)] <heidi_> hey yura
[09:43:25 CDT(-0500)] <yura> would you happen to know what's the reasoning behind min width of 960px for fat panel ?
[09:43:37 CDT(-0500)] <yura> that seems to be the issue with messed up reset in demo
[09:43:39 CDT(-0500)] <heidi_> jameswy 's instruction
[09:43:54 CDT(-0500)] <yura> jameswy: ?
[09:43:56 CDT(-0500)] <heidi_> but yeah good catch - you're right
[09:44:27 CDT(-0500)] <jameswy> yura: Why is it causing issues?
[09:44:29 CDT(-0500)] <heidi_> cindyli yeah our reset is from YUI
[09:44:44 CDT(-0500)] <heidi_> so we should look at the current YUI to see if we're out of date - maybe it address button's and other stuff
[09:44:54 CDT(-0500)] <heidi_> jameswy the iframe for the demo is smaller than 960
[09:45:05 CDT(-0500)] <cindyli> i see. thanks, heidi_
[09:45:22 CDT(-0500)] <jameswy> The min width is there because we need at least some width to play with. I haven't thought out how the UI should react at smaller widths (e.g., what does fat panel look like at 240px width?)
[09:45:39 CDT(-0500)] <jameswy> heidi_, yura ^^
[09:45:53 CDT(-0500)] <yura> right
[09:45:58 CDT(-0500)] <heidi_> jameswy max-width:960px makes sense but min 960 sounds too large as a min
[09:46:25 CDT(-0500)] <heidi_> yura does it look terrible without that style?
[09:46:27 CDT(-0500)] <yura> jameswy: in demo portal, the fat panel of min 960 is loaded into smaller iframe which cuts out controls on the right side
[09:46:37 CDT(-0500)] <yura> such as reset all button
[09:47:08 CDT(-0500)] <yura> heidi_: jameswy it looks the same without it, my i guess it affects the way it looks when the panel is resized to something really narrow
[09:47:31 CDT(-0500)] <heidi_> yura does the reset button come back into frame?
[09:47:39 CDT(-0500)] <yura> yes
[09:47:48 CDT(-0500)] <yura> removing that min height fixes the issue
[09:48:59 CDT(-0500)] <heidi_> yura i think jameswy should make the call, but is there a better min you could recommend?
[09:49:10 CDT(-0500)] <heidi_> when playing with its width, before it becomes unusable
[09:49:34 CDT(-0500)] <yura> well min should be as small as possible with the layout still preserved
[09:49:47 CDT(-0500)] <yura> i believe it can be smaller than 960
[09:49:49 CDT(-0500)] <michelled> Justin_o: I just pushed my branch up - ideas on who I can work with? https://github.com/michelled/infusion/tree/FLUID-4404
[09:49:50 CDT(-0500)] <yura> jameswy: ideas?
[09:50:17 CDT(-0500)] <Justin_o> yura: make sure you try it with the different options set, like text size, line spacing and text style
[09:50:46 CDT(-0500)] <yura> Justin_o: alright
[09:50:55 CDT(-0500)] <heidi_> yura yeah, make sure to try with increased text size as well
[09:50:56 CDT(-0500)] <yura> but was there a specific reason it was set to 960?
[09:51:09 CDT(-0500)] <heidi_> n/m justin said that ha
[09:52:21 CDT(-0500)] <jameswy> yura, heidi_: for the time being, kill the min-width. http://issues.fluidproject.org:18080/browse/FLUID-4380 will take care of it in 1.5
[09:58:27 CDT(-0500)] <yura> so jameswy should i just remove min-width or something smaller is ok ?
[09:58:52 CDT(-0500)] <jameswy> yura: What's the repercussion of removing min-width entirely?
[09:59:54 CDT(-0500)] <yura> jameswy: if someone makes a window really tiny, blocks will jump on different lines
[10:01:26 CDT(-0500)] <jameswy> heidi_, yura: Is it possible to set min-widths relative to the text size?
[10:01:51 CDT(-0500)] <yura> dynamically ?
[10:01:54 CDT(-0500)] <jameswy> Yes.
[10:01:57 CDT(-0500)] <yura> i m afraid not
[10:02:23 CDT(-0500)] <jameswy> Think it's something we could do for 1.5?
[10:02:23 CDT(-0500)] <heidi_> jameswy it's more than just text-size tho, it's browser width/resolution ya?
[10:02:32 CDT(-0500)] <heidi_> oh wait n/m
[10:03:38 CDT(-0500)] <jameswy> heidi_, yura: It's not just that--it's also width of the content⦠is there any way to tell what width the implementer is using?
[10:04:35 CDT(-0500)] <jameswy> Ideally, I feel like we should be matching the implementer.
[10:05:21 CDT(-0500)] <jameswy> If our min/max widths are out of sync with theirs, the site will generally look messed up at either end
[10:05:54 CDT(-0500)] <michelled> Justin_o: I think I'm done with 4404 - I made a pull request - please take a look
[10:07:49 CDT(-0500)] <yura> well jameswy how about setting min-width to inherit , which will make it inherited from the parent element
[10:08:55 CDT(-0500)] <jameswy> yura: That sounds good.
[10:09:00 CDT(-0500)] <yura> alright
[10:09:41 CDT(-0500)] <jameswy> I'm still concerned about what happens with the widths when we change text sizes though.. we'll think about it more (heidi_, yura)
[10:09:57 CDT(-0500)] <heidi_> k
[10:12:57 CDT(-0500)] <michelled> cindyli: I'm confused by your pull request - was it for 4356?
[10:13:08 CDT(-0500)] <michelled> http://issues.fluidproject.org/browse/FLUID-4356
[10:13:45 CDT(-0500)] <cindyli> sorry, michelled - 4365
[10:14:18 CDT(-0500)] <cindyli> , my commit message, have to modify
[10:14:27 CDT(-0500)] <michelled> ok
[10:14:39 CDT(-0500)] <cindyli> can u remove this pull request? i will send in another one
[10:16:17 CDT(-0500)] <yura> jameswy: i guess on the up side all panel elements will be visible to the user, unlike in case where min-width is greater than the actual frame width
[10:19:36 CDT(-0500)] <cindyli> michelled: i sent another pull request on 4365. can you have a look. thanks
[10:20:11 CDT(-0500)] <michelled> thx cindyli
[10:20:19 CDT(-0500)] <cindyli> np
[10:24:15 CDT(-0500)] <michelled> jameswy: what casing did you want for the colour and contrast options?
[10:24:23 CDT(-0500)] <michelled> http://issues.fluidproject.org/browse/FLUID-4365
[10:25:25 CDT(-0500)] <michelled> heidi_, yura: it looks like the two of you are holding the blockers - do you need help?
[10:25:54 CDT(-0500)] <heidi_> michelled should be done soonish
[10:25:55 CDT(-0500)] <jameswy> michelled: Upper
[10:26:11 CDT(-0500)] <heidi_> help testing it on diff browsers would be good tho
[10:26:17 CDT(-0500)] <yura> michelled: I have a fix for mine, jameswy mentioned that more elegant solution might be coming in 1.5
[10:26:27 CDT(-0500)] <yura> michelled: should i issue a pull request ?
[10:27:03 CDT(-0500)] <heidi_> jameswy having trouble finding your UIO 1.4 mockups on wiki - help?
[10:31:33 CDT(-0500)] <jameswy> heidi_: http://wiki.fluidproject.org/display/fluid/Floe+design under UIO
[10:32:03 CDT(-0500)] <heidi_> thanks!
[10:36:18 CDT(-0500)] <jhung1> justin_o do you want to chat Skype or in the channel?
[10:36:34 CDT(-0500)] <michelled> cindyli: jameswy wanted the upper case not lower case for 4365
[10:36:54 CDT(-0500)] <michelled> yura: yep with the pull request
[10:37:05 CDT(-0500)] <cindyli> Aha, i see. michelled.
[10:37:16 CDT(-0500)] <cindyli> more is coming into the pull request
[10:37:22 CDT(-0500)] <michelled> thx
[10:38:37 CDT(-0500)] <yura> michelled: done
[10:39:26 CDT(-0500)] <heidi_> cindyli did you take a look at the most recent YUI
[10:39:48 CDT(-0500)] <cindyli> heidi_: yes, i'm looking and quite confused
[10:40:01 CDT(-0500)] <heidi_> maybe Justin_o can help you
[10:40:18 CDT(-0500)] <cindyli> heidi_: i will ask for his help. thanks, heidi_
[11:00:34 CDT(-0500)] <cindyli> michelled: 4365 is ready for further review
[11:14:41 CDT(-0500)] <heidi_> michelled how do i update a pull request? i forget
[11:15:11 CDT(-0500)] <michelled> pushing to the branch that you made the request from should do it
[11:19:52 CDT(-0500)] <heidi_> michelled ah cool. maybe Justin_o should review the css changes? not sure where he went
[11:20:10 CDT(-0500)] <michelled> he's at lunch - should be back soonish
[11:20:11 CDT(-0500)] <heidi_> needs to be tested on IE as well
[11:20:14 CDT(-0500)] <heidi_> ok cool
[12:47:24 CDT(-0500)] <michelled> cindyli: I was just looking at your 4365 pull request - I'm wondering why you both used toUpperCase on the strings and also changed the strings to upper case in the options
[12:53:05 CDT(-0500)] <cindyli> michelled: the change of the strings to upper case is cuz we know that the design is to have them this way. The funciton call of toUpperCase() is to avoid the case that if someone else didn't realize the design of the upper case and wrote the strings in lower case, the script would ensure everything is converted in the right way
[12:53:32 CDT(-0500)] <cindyli> writing strings in upper case is not mandatory tho
[12:54:52 CDT(-0500)] <michelled> cindyli: I guess this strategy means that if someone wanted a different casing in the drop down they'd have to hack the code
[12:55:26 CDT(-0500)] <cindyli> i thought the design is to have theme options in upper case all the time
[12:55:44 CDT(-0500)] <cindyli> the script is to prevent the different casing
[12:56:43 CDT(-0500)] <heidi_> cindyli you could use css for that
[12:57:18 CDT(-0500)] <cindyli> heidi_: we have the css in place
[12:57:41 CDT(-0500)] <cindyli> but in the script, the strings were written in the mixture of upper and lower case
[12:58:25 CDT(-0500)] <cindyli> which causes the problem that in some browsers, like chrome, the listed theme options are in the mixture, but once the option is selected, it turns into upper case
[12:59:28 CDT(-0500)] <cindyli> heidi_: do you mean that we can have a css to for these options even when they are not selected, which would convert the strings to upper case
[12:59:42 CDT(-0500)] <cindyli> a good idea, i think
[13:00:41 CDT(-0500)] <cindyli> right now the css to turn strings into upper case is only associated with the selected option
[13:01:13 CDT(-0500)] <heidi_> whichever way works! but doing it with css instead of code is better
[13:01:45 CDT(-0500)] <cindyli> heidi_: ya, agree, to save the processing power and time
[13:02:25 CDT(-0500)] <heidi_> cindyli more to keep it easily customizable for implementers
[13:03:13 CDT(-0500)] <Justin_o> cindyli: did that change to the reset file for the button go into the repo?
[13:03:22 CDT(-0500)] <cindyli> yes, Justin_o
[13:03:27 CDT(-0500)] <cindyli> last friday
[13:03:54 CDT(-0500)] <anastasiac> Bosmon, are you there?
[13:03:59 CDT(-0500)] <Justin_o> cindyli: thanks.. what was the jira for that one
[13:04:01 CDT(-0500)] <cindyli> cool. michelled, i'm making change for 4365 to use css. will let you know when it's ready
[13:04:59 CDT(-0500)] <cindyli> Justin_o: 4376
[13:06:06 CDT(-0500)] <michelled> thx cindyli
[13:06:21 CDT(-0500)] <cindyli> np, michelled
[13:17:14 CDT(-0500)] <michelled> Justin_o: this is no longer an issue - do you know if there is duplicate JIRA which fixed it? http://issues.fluidproject.org/browse/FLUID-3991
[13:18:38 CDT(-0500)] <anastasiac> Justin_o, I'm filing a JIRA for that bug where listeners are not registered. I'm assuming this is a blocker for bug parade?
[13:19:53 CDT(-0500)] <Justin_o> anastasiac: yes.. sounds like it
[13:20:28 CDT(-0500)] <anastasiac> thanks, Justin_o. The bug was definitely introduced with the 4409 branch. Should I assign the JIRA to Bosmon, or just leave it unassigned?
[13:21:38 CDT(-0500)] <Justin_o> anastasiac: umm.. hmm.. i guess assign it to him for now
[13:21:49 CDT(-0500)] <anastasiac> k, thanks
[13:30:37 CDT(-0500)] <heidi_> Justin_o tryin to pick another jira - suggestions?
[13:52:16 CDT(-0500)] <cindyli> heidi_: michelled, i had no success to apply css text-transform: uppercase to theme option drop down items, chrome in particular. It appears this is a known issue in chrome - http://code.google.com/p/chromium/issues/detail?id=31349
[13:53:12 CDT(-0500)] <cindyli> heidi_: i'd like to seek your expertise
[13:53:59 CDT(-0500)]
[13:54:18 CDT(-0500)] <cindyli> heidi_: tried, no. double checking
[13:54:22 CDT(-0500)] <heidi_> if it's a bug in chrome, i don't think we should make a hack around it, but just accept this result
[13:54:36 CDT(-0500)] <heidi_> jameswy can make the call tho
[13:54:49 CDT(-0500)]
[13:55:48 CDT(-0500)] <heidi_> cindyli i'm updating my chrome and will take a look
[13:56:08 CDT(-0500)] <cindyli> thanks, heidi_
[13:57:09 CDT(-0500)] <cindyli> btw, heidi_, safari has the same issue
[14:11:13 CDT(-0500)] <huslage> howdy luciantimofte
[14:11:21 CDT(-0500)] <huslage> i'm the sysadmin round these parts
[14:18:35 CDT(-0500)] <heidi_> welcome luciantimofte
[14:34:58 CDT(-0500)] <Justin_o> heidi_: just trying to test your FLUID-4362 branch now
[14:35:00 CDT(-0500)] <Justin_o> i think there
[14:35:10 CDT(-0500)] <Justin_o> is a merge conflict with it and the project repo
[14:35:17 CDT(-0500)] <Justin_o> would you be able to take a look at that
[14:35:22 CDT(-0500)] <heidi_> ok
[14:35:25 CDT(-0500)] <Justin_o> thanks
[14:56:03 CDT(-0500)] <Bosmon> Hi anastasiac - I am just looking at your FLUID-4428 issue now
[14:58:29 CDT(-0500)] <Bosmon> Hi yura - michelled said to me that you were looking at FLUID-4428?
[14:58:38 CDT(-0500)] <anastasiac> Bosmon, great - yura looked at it a bit, too, he might have some thoughts
[14:59:06 CDT(-0500)] <yura> Bosmon: hi
[15:00:06 CDT(-0500)] <yura> it looks like the option chewer, in order to grab incoming user options, needs the config value to be a string
[15:00:10 CDT(-0500)] <yura> which makes sense
[15:01:10 CDT(-0500)] <yura> it looks like fullpreview and nopreview use config inappropriately, e.g. actually contain options rather than mapping information
[15:01:15 CDT(-0500)] <yura> unlike other components
[15:01:18 CDT(-0500)] <yura> Bosmon: ^
[15:02:19 CDT(-0500)] <Bosmon> Well, you could call it "inappropriately"
[15:02:24 CDT(-0500)] <Bosmon> In another sense, it is "by design"....
[15:02:40 CDT(-0500)] <Bosmon> I am trying to reconstruct the original intentions of the implementors here
[15:04:12 CDT(-0500)] <Bosmon> Yes
[15:04:28 CDT(-0500)] <Bosmon> I guess we could have expected that the terrible logic I put in for FLUID-4409 would bite us in the end
[15:04:49 CDT(-0500)] <Bosmon> Or even, thankfully, at the beginning
[15:08:26 CDT(-0500)] <heidi_> oh Justin_o i fixed the merge conflict
[15:09:34 CDT(-0500)] <Bosmon> The catastrophic part of this impl is that the original value in "config" for direct uiOptions options has been completely destroyed
[15:09:49 CDT(-0500)] <Justin_o> heidi_: thanks
[15:09:51 CDT(-0500)] <Bosmon> On line 207 there was this element configured: ".uiOptionsLoader..uiOptions": "uiOptions",
[15:10:36 CDT(-0500)] <Bosmon> The strategy of trying to hurl default options into the config in specific subcomponents has overwritten this element completely through merging
[15:10:44 CDT(-0500)] <Bosmon> With the following value: ".uiOptionsLoader..uiOptions": {
[15:10:44 CDT(-0500)] <Bosmon> options: {
[15:10:53 CDT(-0500)] <Bosmon> Held, for example, on line 37 of FullNoPreviewOptions.js
[15:11:38 CDT(-0500)] <Justin_o> heidi_: hmm.. text size and line spacing don't seem to work at all in IE6
[15:12:28 CDT(-0500)] <heidi_> Justin_o hmm. worked fine before?
[15:12:38 CDT(-0500)] <Justin_o> heidi_: i think so
[15:13:02 CDT(-0500)] <heidi_> Justin_o ok. i don't have IE6 - can you check the build site and confirm that?
[15:13:23 CDT(-0500)] <heidi_> i think i might know which style it was. one sec
[15:13:26 CDT(-0500)] <Justin_o> heidi_: i'll check.. but there were a lot of changes since i tried it last time
[15:14:20 CDT(-0500)] <Justin_o> heidi_: it's not working on the build site either
[15:14:29 CDT(-0500)] <heidi_> Justin_o ok, so it wasn't me
[15:15:03 CDT(-0500)] <Justin_o> heidi_: at least not with this change
[15:15:10 CDT(-0500)] <heidi_> hey
[15:15:19 CDT(-0500)] <heidi_> was it ever working?
[15:15:32 CDT(-0500)] <Justin_o> i think so.. i'm not 100% sure though
[15:16:23 CDT(-0500)] <michelled> cindyli: you had tested on ie6 in the past, right?
[15:16:57 CDT(-0500)] <michelled> text size and line spacing I mean
[15:17:30 CDT(-0500)] <cindyli> michelled: Justin_o, heidi_, yes, i tested, it wasn't working and 4427 was created for it
[15:17:43 CDT(-0500)] <Bosmon> Hmm.... I thought I saw them working
[15:17:58 CDT(-0500)] <Bosmon> 4427 is a pretty late number... perhaps they were broken by a quite recent change
[15:18:34 CDT(-0500)] <Bosmon> For example, I thought I saw them working when I reworked cindyli's version number detection push last Friday
[15:18:36 CDT(-0500)] <cindyli> Bosmon: it wasn't working in the branch that I took over from Justin. That's when this jira was created
[15:18:48 CDT(-0500)] <Bosmon> I see
[15:18:48 CDT(-0500)] <cindyli> Bosmon: in ie6?
[15:18:57 CDT(-0500)] <Bosmon> Yes, that is what I thought I remember seeing
[15:19:55 CDT(-0500)] <Bosmon> I guess I misremembered
[15:19:57 CDT(-0500)] <Justin_o> cindyli: which branch did you take over for me?
[15:20:00 CDT(-0500)] <Bosmon> I was in a bit of a hurry then
[15:20:11 CDT(-0500)] <Justin_o> cindyli: i can't remember the jira number
[15:20:19 CDT(-0500)] <Justin_o> I wonder if it was something in that branch?
[15:20:37 CDT(-0500)] <cindyli> Justin_o: 4370
[15:21:19 CDT(-0500)] <cindyli> we can test the version that's before and after this branch was merged into project repo
[15:21:43 CDT(-0500)] <cindyli> i'm testing now
[15:21:57 CDT(-0500)] <michelled> Justin_o: what are your feelings on 4427?
[15:22:03 CDT(-0500)] <michelled> is that a blocker for 1.4?
[15:22:40 CDT(-0500)] <Justin_o> michelled: i think so...
[15:22:54 CDT(-0500)] <Justin_o> since for 1.4 we've decided to still support IE6 we will need it to be working
[15:22:57 CDT(-0500)] <michelled> ok, looks like we can't freeze tonight
[15:23:07 CDT(-0500)] <michelled> cindyli: do you have cycles to take that on?
[15:23:25 CDT(-0500)] <cindyli> sure, michelled
[15:23:52 CDT(-0500)] <michelled> thanks cindyli
[15:23:56 CDT(-0500)] <cindyli> np
[15:24:12 CDT(-0500)] <michelled> Bosmon: code freeze will probably happen sometime tomorrow
[15:24:18 CDT(-0500)] <Justin_o> fluid-everyone: i've made this a blocker for 1.4 http://issues.fluidproject.org:18080/browse/FLUID-4427
[15:25:31 CDT(-0500)] <Bosmon> ok
[15:25:57 CDT(-0500)] <Bosmon> I will get a pull in for 4428 this evening
[15:26:02 CDT(-0500)] <Bosmon> As well as tests for FullPreview
[15:26:12 CDT(-0500)] <michelled> fluid-everyone: we'll start QA for everything except UIO tomorrow morning
[15:26:46 CDT(-0500)] <michelled> fluid-everyone: Justin_o will organize that tomorrow. cindyli and Bosmon have blockers and everyone else can help with QA
[15:30:20 CDT(-0500)] <heidi_> cindyli do i have to do something special in chrome to get uio to work?
[15:30:33 CDT(-0500)] <cindyli> no, heidi_
[15:30:50 CDT(-0500)] <heidi_> none of them work for me, hmm
[15:30:59 CDT(-0500)] <cindyli> oh, heidi_, u need to access thru web server, localhost
[15:31:00 CDT(-0500)] <heidi_> Justin_o do i have to enable local js for chrome or anything?
[15:31:07 CDT(-0500)] <heidi_> ah
[15:31:19 CDT(-0500)] <cindyli> there's a chrome setting to turn it off
[15:31:53 CDT(-0500)] <cindyli> trying to remember
[15:32:00 CDT(-0500)] <heidi_> i'm using localhost now, it's cool. thanks!
[15:32:16 CDT(-0500)] <heidi_> so cindyli you were just trying to make the colour and contrast dropdown all caps?
[15:32:30 CDT(-0500)] <cindyli> yes, heidi_
[15:33:34 CDT(-0500)] <cindyli> heidi_: try this - http://stackoverflow.com/questions/4270999/google-chrome-allow-file-access-from-files-disabled-for-chrome-beta-8
[15:34:49 CDT(-0500)] <heidi_> cindyli thanks. yeah i can't get uppercase to work either - i think it's just a chrome bug, but i don't think it's worth hacking
[15:35:00 CDT(-0500)] <heidi_> the colours don't work either
[15:35:05 CDT(-0500)] <heidi_> what was the jira # for this
[15:35:28 CDT(-0500)] <cindyli> heidi_: do u mean the colors on the drop down options?
[15:35:38 CDT(-0500)] <heidi_> cindyli ya
[15:36:03 CDT(-0500)] <cindyli> heidi_: in chrome? it works on me
[15:36:34 CDT(-0500)] <cindyli> the options are with right fore- and back- ground colors
[15:38:11 CDT(-0500)] <heidi_> cindyli are you on a mac
[15:38:25 CDT(-0500)] <cindyli> hehe, no
[15:38:30 CDT(-0500)] <cindyli> windows
[15:38:39 CDT(-0500)] <heidi_> ah, colours aren't working for me, maybe just for mac version then
[15:38:49 CDT(-0500)] <cindyli> ok
[15:38:51 CDT(-0500)] <heidi_> what is the jira #? ill note that
[15:38:57 CDT(-0500)] <cindyli> i don't know
[15:39:25 CDT(-0500)] <cindyli> i'm actually surprised to see the colours work on chrom/windows
[15:39:54 CDT(-0500)] <cindyli> at the time i implemented this feature, it only worked in firefox, not any other browsers. someone must have improved this feature. nice.
[15:40:40 CDT(-0500)] <Bosmon> yura - I've just realised a really appalling inconsistency in our options expansion process, too
[15:40:45 CDT(-0500)] <Bosmon> Perhaps you have been aware of this for a while
[15:41:05 CDT(-0500)] <yura> which is ?
[15:41:39 CDT(-0500)] <Bosmon> But I realise that a "direct options structure" which is supplied as the argument to a component creator function... whilst it does not have options expanded which appear at top level, DOES have options expanded which are destined for subcomponents
[15:41:54 CDT(-0500)] <Bosmon> As soon as IoC starts expanding a subcomponent, the options are no longer considered "direct"
[15:42:23 CDT(-0500)] <yura> hmm
[15:42:30 CDT(-0500)] <Bosmon> I was looking at this "mid-level defaults" structure here in FullNoPreviewUIOptions and wondering who the h"Β£$ was responsible for expanding it
[15:42:35 CDT(-0500)] <yura> not sure i noticed that, or just worked with/around it
[15:42:35 CDT(-0500)] <Bosmon> Given it contains IoC references
[15:46:59 CDT(-0500)] <yura> michelled: I can't reproduce this one http://issues.fluidproject.org/browse/FLUID-4363
[15:48:02 CDT(-0500)] <michelled> yura: I think that's related to the work heidi_ did
[15:48:16 CDT(-0500)] <michelled> we should link those so justin can check tomorrow when he reviews it
[15:48:26 CDT(-0500)] <yura> alright ill comment on that one
[15:48:27 CDT(-0500)] <heidi_> don't think that's related to what i did
[15:48:38 CDT(-0500)] <heidi_> oh actually yeah i did fix that
[15:48:47 CDT(-0500)] <heidi_> i made the width a touch wider
[15:48:57 CDT(-0500)] <heidi_> cos it was happening by default in safari
[15:49:00 CDT(-0500)] <heidi_> yura ^
Unknown macro: { text-transform}
Unknown macro: { text-transform}
Manage space
Manage content
Integrations