[08:14:20 CDT(-0500)] <heidi_> cindyli michelled i can take a look at 4500 - UIO styling bug
[08:14:37 CDT(-0500)] <michelled> thx heidi_
[08:15:10 CDT(-0500)] <cindyli> thanks, heidi_, i will give a dig too
[08:18:22 CDT(-0500)] <heidi_> cindyli michelled i've got a fix - i'll send a pull req
[08:18:39 CDT(-0500)] <heidi_> not sure how this bug happened, but this should do it
[08:18:40 CDT(-0500)] <cindyli> awesome, thanks, heidi_
[08:19:48 CDT(-0500)] <heidi_> just checking it on some other browsers
[08:20:51 CDT(-0500)] <Justin_o> heidi_: i can review your pull request, could you please let me know after you send it?
[08:21:15 CDT(-0500)] <heidi_> Justin_o will do. i wonder if FF6 treats padding differently than 3.6
[08:21:34 CDT(-0500)] <heidi_> it's much different than safari
[08:21:58 CDT(-0500)] <Justin_o> heidi_: really.. in what way?
[08:23:47 CDT(-0500)] <heidi_> Justin_o not sure... something's different
[08:25:57 CDT(-0500)] <heidi_> Justin_o there seems to be some other styling issues now as well - particularly when font size is made larger. any guesses as to when these were introduced?
[08:28:03 CDT(-0500)] <Justin_o> heidi_: my first guess would be when we changed the stuff around line spacing
[08:28:22 CDT(-0500)] <Justin_o> but i haven't investigated the code, so am not too sure
[08:31:46 CDT(-0500)] <heidi_> cindyli michelled fyi there seem to be some other styling issues when font size is large so i'll try to fix that too
[08:32:03 CDT(-0500)] <cindyli> thanks, heidi_
[08:37:25 CDT(-0500)] <anastasiac> michelled, a question about the text fields in the UIO sliders: Should users be able to enter a decimal number less than 1 without a leading 0 and still have it be considered a number? e.g. .5 instead of 0.5
[08:38:42 CDT(-0500)] <anastasiac> hm. heidi_, jameswy, can you comment on my question, just above? ^
[08:39:15 CDT(-0500)] <heidi_> anastasiac i think the range is 1x to 2x
[08:39:41 CDT(-0500)] <anastasiac> yes, but my question is: should .5 be treated as an invalid number, or an invalid string? the results are different
[08:39:49 CDT(-0500)] <jameswy> anastasiac: Let's make anything with a leading decimal an invalid value
[08:39:58 CDT(-0500)] <jameswy> Ah, didn't realize that.
[08:40:08 CDT(-0500)] <jameswy> How are we treating invalid numbers different than strings?
[08:40:19 CDT(-0500)] <anastasiac> strings are ignored completely, but numbers less than the minimum set the value to the minimum
[08:41:10 CDT(-0500)] <jameswy> Right.
[08:41:33 CDT(-0500)] <jameswy> Let's have it treated as an invalid number, and be consistent about it throughout.
[08:41:37 CDT(-0500)] <heidi_> anastasiac it should set to 1 i would think
[08:41:46 CDT(-0500)] <jameswy> Exactly.
[08:42:18 CDT(-0500)] <anastasiac> ok, thanks. That's what I was expecting to happen. So: .5 counts as a number, and if it's entered and is less than the minimum, then the value should be set to the minimum, right
[08:42:19 CDT(-0500)] <anastasiac> ?
[08:42:54 CDT(-0500)] <heidi_> anastasiac right
[08:42:56 CDT(-0500)] <anastasiac> thanks
[08:46:00 CDT(-0500)] <Justin_o> anastasiac: is that what happens?
[08:46:31 CDT(-0500)] <anastasiac> Justin_o, right now it's treating it as a string and ignoring it, so it is NOT behaving as jameswy and heidi_ recommend. I was going to file it as a minor bug.
[08:47:25 CDT(-0500)] <Justin_o> anastasiac: okay, thanks
[08:47:38 CDT(-0500)] <anastasiac> Justin_o: http://issues.fluidproject.org/browse/FLUID-4501
[08:50:15 CDT(-0500)] <Justin_o> fluid-everyone: just a heads up that after the fix for FLUID-4500 we'll have to restart UIO testing
[08:51:48 CDT(-0500)] <anastasiac> Justin_o, does that mean re-doing test plans that were completed?
[08:52:32 CDT(-0500)] <Justin_o> anastasiac: unfortunately yes
[09:06:34 CDT(-0500)] <heidi_> Justin_o i'm noticing a scrollbar for fat panel in IE8
[09:07:16 CDT(-0500)] <heidi_> or maybe it was something i just added...
[09:10:22 CDT(-0500)] <heidi_> Justin_o no it's there in master as well.... blocker?
[09:10:53 CDT(-0500)] <Justin_o> sounds like something that was mentioned yesterday
[09:11:07 CDT(-0500)] <Justin_o> oh was that the thing you mentioned about fl-fix
[09:11:26 CDT(-0500)] <heidi_> Justin_o no that was something else
[09:11:37 CDT(-0500)] <heidi_> Justin_o are the scrollbars there in IE9 as well
[09:11:57 CDT(-0500)] <Justin_o> heidi_: hmm okay, not sure.. just in a meeting at the moment, but i can try to check later.. or maybe anastasiac can confirm
[09:12:13 CDT(-0500)] <anastasiac> sure, I'll have a look
[09:12:22 CDT(-0500)] <anastasiac> heidi_, ie8 in win7 or xp?
[09:12:50 CDT(-0500)] <heidi_> anastasiac xp
[09:13:07 CDT(-0500)] <heidi_> and wondering if it happens in win7/IE9 as well
[09:13:11 CDT(-0500)] <anastasiac> oh, you want me to check IE8 or IE9? and horizontal or vertical, heidi_?
[09:13:20 CDT(-0500)] <anastasiac> ok, I'll check everything I have 
[09:13:31 CDT(-0500)] <heidi_> anastasiac vertical scrollbar on far right when opening fat panel
[09:13:40 CDT(-0500)] <anastasiac> k
[09:13:53 CDT(-0500)] <heidi_> anastasiac for 'links and buttons'
[09:14:36 CDT(-0500)] <anastasiac> heidi_: IE9 on Win7: There is a scollbar there briefly, but the fat panel enlarges until it's big enough and the scollbar goes away
[09:15:12 CDT(-0500)] <heidi_> hm, i guess that's ok.
[09:15:15 CDT(-0500)] <heidi_> and IE8?
[09:17:04 CDT(-0500)] <anastasiac> heidi_: IE8 on Win 7: scrollbars on links & buttons and on layout & navigation; trying xp next (takes time to shut down a vm and start another)
[09:17:14 CDT(-0500)] <anastasiac> and clear cookies
[09:17:28 CDT(-0500)] <heidi_> anastasiac thanks for checking... yeah that's not good to have those vert scrollbars by default
[09:17:40 CDT(-0500)] <heidi_> Justin_o jameswy is that a blocker
[09:17:59 CDT(-0500)] <heidi_> it's too bad all these styling bugs got in...hm
[09:18:28 CDT(-0500)] <anastasiac> heidi_: IE8 on XP: scrollbars
[09:18:33 CDT(-0500)] <anastasiac> ie7 next...
[09:18:44 CDT(-0500)] <heidi_> thanks anastasiac - could you file a bug for this?
[09:18:52 CDT(-0500)] <anastasiac> sure
[09:18:57 CDT(-0500)] <heidi_> thanks!
[09:19:22 CDT(-0500)] <heidi_> i wonder if it's something Bosmon2's window resizer thing can fix?
[09:19:25 CDT(-0500)] <jameswy> heidi_, anastasiac, Justin_o: doesn't sound like a blocker to me. It's just there temporarily until the expansion is complete?
[09:19:35 CDT(-0500)] <anastasiac> IE7 same as IE9: brief scrollbars that go away when fat panel resizes
[09:19:40 CDT(-0500)] <anastasiac> I wouldn't think it's a blocker
[09:19:53 CDT(-0500)] <heidi_> jameswy no that's just for IE9 ... for IE8 scrollbars stays... sounds like that's the only browser tho
[09:20:00 CDT(-0500)] <anastasiac> jameswy, in IE8 there's no expansion: the scrollbar stays, but everything is still visible
[09:20:09 CDT(-0500)] <anastasiac> maybe a sliver of white is offscreen
[09:20:31 CDT(-0500)] <jameswy> Ah, gotcha.
[09:20:49 CDT(-0500)] <jameswy> Still don't think it's a blocker. Justin_o?
[09:20:55 CDT(-0500)] <heidi_> k i'll submit my pull for 4500 for now... i think it would also be good to fix the styling issues when font-size is big tho
[09:21:22 CDT(-0500)] <anastasiac> wow; IE6 sucks
[09:21:31 CDT(-0500)] <anastasiac> but no scrollbars
[09:21:43 CDT(-0500)] <Justin_o> jameswy: i'd agree with you
[09:22:01 CDT(-0500)] <heidi_> anastasiac how sucky?
[09:22:29 CDT(-0500)] <anastasiac> very slow; the show/hide blue extends across the whole page; very slow
[09:22:41 CDT(-0500)] <anastasiac> and it's on windows
[09:28:12 CDT(-0500)] <anastasiac> Justin_o, heidi_: http://issues.fluidproject.org/browse/FLUID-4502
[09:29:02 CDT(-0500)] <heidi_> thanks anastasiac
[09:29:16 CDT(-0500)] <heidi_> Justin_o sent pull req for 4500
[09:29:30 CDT(-0500)] <Justin_o> heidi_: thanks
[09:29:52 CDT(-0500)] <heidi_> Justin_o i wonder if we want to fix the styling issues for when the font size is large
[09:31:05 CDT(-0500)] <heidi_> something is up now... text-style isn't working at all for me in fat panel
[09:31:09 CDT(-0500)] <heidi_> in FF
[09:31:22 CDT(-0500)] <heidi_> or safari
[09:31:27 CDT(-0500)] <Justin_o> heidi_: really
[09:31:33 CDT(-0500)] <Justin_o> off the build site?
[09:31:43 CDT(-0500)] <heidi_> Justin_o no local... checking build
[09:32:49 CDT(-0500)] <heidi_> Justin_o works on build site... i wonder why that would be?
[09:33:07 CDT(-0500)] <Justin_o> heidi_: are you checking the branch you submitted the pull request from locally
[09:33:11 CDT(-0500)] <Justin_o> or the master branch
[09:33:16 CDT(-0500)] <heidi_> Justin_o master
[09:33:28 CDT(-0500)] <Justin_o> heidi_: hmm.. might be some sort of local ajax thing or something
[09:33:30 CDT(-0500)] <Justin_o> not too sure
[09:33:42 CDT(-0500)] <Justin_o> or something do with the cookie maybe
[09:34:05 CDT(-0500)] <heidi_> hmm
[09:34:59 CDT(-0500)] <heidi_> yeah my local one seems to have other issues as well so ignore... i'll try a fresh copy and if it's still weird maybe it's cos it's local... hm
[09:46:26 CDT(-0500)] <Justin_o> heidi_: i'm looking at your fix.. would it be possible to get the alignment of the text and checkbox to be the same as it is on the full page uio versions
[09:48:37 CDT(-0500)] <heidi_> Justin_o i can try
[09:49:10 CDT(-0500)] <Justin_o> heidi_: thanks
[09:49:34 CDT(-0500)] <Justin_o> the ones in the fat panel are mid aligned where as on the other pages they are more top aligned
[09:54:54 CDT(-0500)] <Justin_o> heidi_: i added my comment to the pull request for history sake
[09:55:25 CDT(-0500)] <heidi_> k
[10:00:20 CDT(-0500)] <heidi_> Justin_o i did a fresh clone of the master, deleted cookies, and still can't change text style... why would that be i wonder?
[10:00:23 CDT(-0500)] <heidi_> locally that is
[10:01:19 CDT(-0500)] <heidi_> going through localhost doesn't change that
[10:01:36 CDT(-0500)] <Justin_o> heidi_: wondering if you have run the build
[10:01:45 CDT(-0500)] <Justin_o> you might have to generate the uio themes
[10:01:55 CDT(-0500)] <heidi_> Justin_o ahhhh yes
[10:02:27 CDT(-0500)] <Justin_o> yah.. that step is so easy to miss
[10:22:13 CDT(-0500)] <heidi_> Justin_o can't figure out this input alignment thing
[10:22:20 CDT(-0500)] <heidi_> feels silly to hold up testing for it?
[10:24:07 CDT(-0500)] <heidi_> tho i'm seeing something super weird.... line-height:0 is set on the labels... what the...
[10:24:21 CDT(-0500)] <Justin_o> jameswy: do you mind if the alignment of the checkboxes isn't consistent across types of uio but it is consistent within
[10:25:14 CDT(-0500)] <heidi_> Justin_o can you take a look and see why there's a bizarre style body#fluid-id-3feos7q4-38.fl-uiOptions-fatPanel with line-height:0 ?
[10:25:20 CDT(-0500)] <heidi_> i think that might be what's breaking everything
[10:25:26 CDT(-0500)] <heidi_> on the label
[10:25:49 CDT(-0500)] <Justin_o> the weird part is the unique ID
[10:25:56 CDT(-0500)] <Justin_o> that's there probably because of rendering
[10:26:08 CDT(-0500)] <heidi_> cindyli any guesses as to why a line-height:0 is set here?
[10:27:03 CDT(-0500)] <cindyli> when does line-height:0 get set, heidi_?
[10:27:10 CDT(-0500)] <heidi_> Justin_o ignore my 4500 pull request - this is the real issue, the line height
[10:27:21 CDT(-0500)] <cindyli> at the page initializing or after adjusting certain settings?
[10:27:32 CDT(-0500)] <heidi_> cindyli this is default setting
[10:27:36 CDT(-0500)] <cindyli> ok
[10:27:46 CDT(-0500)] <heidi_> it says it's inherited from body#fluid-id-3feos7q4-38.fl-uiOptions-fatPanel
[10:27:51 CDT(-0500)] <Justin_o> heidi_: okay
[10:29:30 CDT(-0500)] <Justin_o> ehi it looks like that's an inline style too
[10:29:34 CDT(-0500)] <Justin_o> heidi_: ^
[10:29:50 CDT(-0500)] <heidi_> Justin_o yeah something up with line-height stuff
[10:30:29 CDT(-0500)] <Justin_o> heidi_: i wonder if that is being set somehow by jquery ui
[10:30:39 CDT(-0500)] <heidi_> hmm
[10:30:44 CDT(-0500)] <cindyli> heidi_: in IE?
[10:30:52 CDT(-0500)] <Justin_o> cindyli: FF
[10:30:53 CDT(-0500)] <heidi_> cindyli i'm using FF
[10:31:02 CDT(-0500)] <cindyli> i don't see it in ff, heidi_
[10:31:18 CDT(-0500)] <heidi_> inspect the label in the 3rd tab
[10:31:24 CDT(-0500)] <heidi_> and scroll down
[10:31:29 CDT(-0500)] <heidi_> it's an inline inherited style
[10:43:53 CDT(-0500)] <heidi_> cindyli Justin_o line-height:0 is set on the iframe's body
[10:44:09 CDT(-0500)] <Justin_o> heidi_: any idea what is setting it there?
[10:44:10 CDT(-0500)] <cindyli> ya, i see it, heidi_
[10:44:12 CDT(-0500)] <heidi_> it should be 1em by default - is there an error in the code for this cindyli
[10:44:21 CDT(-0500)] <cindyli> i found where it's from, Justin_o, heidi_
[10:44:32 CDT(-0500)] <cindyli> it's set by UIEnhancer
[10:44:35 CDT(-0500)] <heidi_> easy fix cindyli? typo or miscalculation?
[10:44:43 CDT(-0500)] <cindyli> not a typo
[10:45:21 CDT(-0500)] <heidi_> cindyli i'll leave it to you to send a pull req for 4500 then - cool? Justin_o can review
[10:45:31 CDT(-0500)] <cindyli> it's because the time that uienhancer detects the iframe body line-height is too early for iframe to gets initialized
[10:45:37 CDT(-0500)] <cindyli> sure, heidi_
[10:45:39 CDT(-0500)] <heidi_> ahh
[10:45:50 CDT(-0500)] <Justin_o> another timing issue eh
[10:45:58 CDT(-0500)] <cindyli> i'm thinking what's the solution
[10:46:09 CDT(-0500)] <cindyli> 1. use default 1em?
[10:46:25 CDT(-0500)] <cindyli> 2. or somehow make iframe initialize earlier?
[10:46:45 CDT(-0500)] <heidi_> cindyli well it should detect what the current setting is
[10:46:53 CDT(-0500)] <Justin_o> which enhancer is setting it, the outer or inner one?
[10:47:11 CDT(-0500)] <cindyli> should be the inner, but i'm not sure
[10:49:30 CDT(-0500)] <cindyli> agree with heidi_, should detect the current setting
[11:09:43 CDT(-0500)] <jameswy> Justin_o, re: timestamp 3:24 – yes, I do mind if the checkboxes aren't consistent across UIOs, even though they're consistent within the individual configurations. But you knew that already
[11:10:57 CDT(-0500)] <jameswy> But if you're asking if I think it's a blocker--it's definitely not.
[11:10:59 CDT(-0500)] <Justin_o> jameswy: of course, but i meant is it a blocker
[11:11:04 CDT(-0500)] <Justin_o> 
[11:11:05 CDT(-0500)] <Justin_o> okay
[11:11:06 CDT(-0500)] <Justin_o> thanks
[11:11:17 CDT(-0500)] <Justin_o> i think it's the real issue anyways..
[11:12:31 CDT(-0500)] <heidi_> Justin_o once line height's fixed checkboxes should line up
[11:13:07 CDT(-0500)] <Justin_o> heidi_: excellent
[11:20:46 CDT(-0500)] <heidi_> Justin_o cindyli can the timing thing be fixed easily-ish? need any help cindy?
[11:25:01 CDT(-0500)] <cindyli> Justin_o, heidi_, i probably was wrong with the timing reason, it seems the div for iframe is set to hidden
[11:25:23 CDT(-0500)] <Justin_o> yes, that's correct
[11:25:25 CDT(-0500)] <cindyli> once i removed the hidden style, line-height is readable
[11:25:35 CDT(-0500)] <Justin_o> cindyli: oh 
[11:25:43 CDT(-0500)] <cindyli> i'm trying to figure out where this hidden style gets added
[11:25:43 CDT(-0500)] <Justin_o> it needs to be hidden to start though
[11:25:49 CDT(-0500)] <cindyli> understand
[11:25:59 CDT(-0500)] <cindyli> just wanna experiment to confirm the cause
[11:26:02 CDT(-0500)] <Justin_o> cindyli: it's getting display: none
[11:26:03 CDT(-0500)] <Justin_o> ?
[11:26:11 CDT(-0500)] <Justin_o> that's because the sliding panel is closing
[11:26:14 CDT(-0500)] <cindyli> Justin_o: no, display: hidden
[11:26:21 CDT(-0500)] <cindyli> ah. ok
[11:26:46 CDT(-0500)] <Justin_o> cindyli: hmm.. display hidden.. i would have expected display: none.. so maybe something else is happenening
[11:26:48 CDT(-0500)] <cindyli> sorry, u r right, display: none
[11:26:49 CDT(-0500)] <Justin_o> any ideas heidi_
[11:26:51 CDT(-0500)] <Justin_o> oh okay
[11:27:42 CDT(-0500)] <heidi_> hmm... so because the div is hidden ui enhancer can't put a line height on it? i'm not sure i understand..
[11:28:17 CDT(-0500)] <heidi_> or i see, the initial value is line-height 0 because it's not being displayed... is that right cindyli?
[11:28:43 CDT(-0500)] <heidi_> is there a way to calc that value before the panel is closed?
[11:29:32 CDT(-0500)] <cindyli> heidi_: the problem is the initial "line-height" is not readable because the div is set to "hidden"
[11:29:56 CDT(-0500)] <heidi_> cindyli right... so is there a way to get the val before the panel closes?
[11:30:14 CDT(-0500)] <heidi_> or recalc it when the panel is opened
[11:30:34 CDT(-0500)] <cindyli> the panel is closed all the time at initialization, i think
[11:30:47 CDT(-0500)] <cindyli> is it right? Justin_o
[11:32:27 CDT(-0500)] <Justin_o> cindyli: i think that's correct
[11:33:18 CDT(-0500)] <heidi_> Justin_o is there a way to expose the line height value somehow
[11:33:30 CDT(-0500)] <heidi_> or signal a uie event when the panel is opened
[11:35:02 CDT(-0500)] <Justin_o> heidi_: possibly the later..
[11:35:32 CDT(-0500)] <Justin_o> heidi_: but it might cause some flickering
[11:35:55 CDT(-0500)] <Justin_o> perhaps UIO shouldn't try to set the line height until it can read some real value
[11:36:01 CDT(-0500)] <Justin_o> cindyli, heidi_ ^^
[11:36:48 CDT(-0500)] <heidi_> Justin_o but even if it's set, it's still not able to get that val
[11:37:59 CDT(-0500)] <Justin_o> heidi_: what do you mean?
[11:38:28 CDT(-0500)] <heidi_> Justin_o i guess.. when can it get the val?
[11:42:58 CDT(-0500)] <Justin_o> heidi_: i guess when the panel opens
[11:43:07 CDT(-0500)] <Justin_o> but i think that it shouldn't try to set it to 0 to start with either
[11:43:40 CDT(-0500)] <heidi_> Justin_o yeah good call, should nver be 0
[11:43:52 CDT(-0500)] <Justin_o> although it still might flicker a bit if you have increased the line spacing
[11:53:44 CDT(-0500)] <heidi_> cindyli is that possible? ^^ not set the line height if the value doesn't exist?
[11:54:53 CDT(-0500)] <cindyli> heidi_, Justin_o, about to send the pull request. i'm taking Justin_o's suggestion that don't touch line-height when it's not detectable
[11:55:11 CDT(-0500)] <cindyli> since the line-height is re-set at the panel open
[11:55:17 CDT(-0500)] <cindyli> we should be safe
[11:55:19 CDT(-0500)] <heidi_> cindyli awesome
[11:55:27 CDT(-0500)] <Justin_o> cindyli: great.. looking forward to trying it out
[11:57:56 CDT(-0500)] <cindyli> heidi_: btw, is negative number of "em" valid for line-height?
[11:58:09 CDT(-0500)] <cindyli> like, line-height: −1em
[11:58:30 CDT(-0500)] <heidi_> cindyli i don't think so no
[11:58:39 CDT(-0500)] <cindyli> cool. thanks, heidi_
[11:59:08 CDT(-0500)] <heidi_> cindyli confirmed, no negatives
[11:59:17 CDT(-0500)] <cindyli> great, thanks.
[11:59:35 CDT(-0500)] <cindyli> Justin_o, heidi_, the pull request for 4500 has been sent - https://github.com/fluid-project/infusion/pull/182
[11:59:46 CDT(-0500)] <heidi_> you rock cindyli
[12:00:01 CDT(-0500)] <cindyli>
[12:00:31 CDT(-0500)] <michelled>
[12:00:50 CDT(-0500)] <michelled> that's great cindyli - can I get you to put a comment into the code explaining why we need to do that check?
[12:00:59 CDT(-0500)] <michelled> it feels like something we'll forget before long
[12:01:28 CDT(-0500)] <michelled> referring to the JIRA number is always good
[12:01:36 CDT(-0500)] <cindyli> i did put a comment before that func in UIEnhanc: Return 0 when the line-height is not detectable.
[12:01:42 CDT(-0500)] <cindyli> is it enough? michelled
[12:01:58 CDT(-0500)] <michelled> oh, I didn't see it in the diff on github
[12:02:14 CDT(-0500)] <cindyli> ok, probably i added after push.
[12:02:23 CDT(-0500)] <cindyli> give me a sec
[12:09:18 CDT(-0500)] <Justin_o> cindyli, michelled: I tried cindy's changes in the Safari and FF on mac and it seems to be working
[12:09:48 CDT(-0500)] <cindyli> thanks, Justin_o. good to know
[12:10:30 CDT(-0500)] <Justin_o> thank you
[12:11:19 CDT(-0500)] <cindyli> michelled, Justin_o, pushed. the pull request is ready
[12:11:30 CDT(-0500)] <cindyli> to be reviewed.
[12:11:37 CDT(-0500)] <michelled> thx cindyli
[12:11:43 CDT(-0500)] <cindyli> np
[12:13:26 CDT(-0500)] <Justin_o> cindyli: thanks.. i'll take a quick peak.. but it seems to be working fine
[12:15:53 CDT(-0500)] <cindyli> cool. thanks. Justin_o
[12:19:37 CDT(-0500)] <Justin_o> cindyli: i think it might make sense to add another comment about the for line 487 to mention that the check there is for the fix for FLUID-4500 similar to what you have on line 364
[12:21:06 CDT(-0500)] <cindyli> sure, Justin_o
[12:21:13 CDT(-0500)] <Justin_o> thanks
[12:24:16 CDT(-0500)] <cindyli> Justin_o: pushed
[12:24:24 CDT(-0500)] <Justin_o> cindyli: thanks
[12:24:26 CDT(-0500)] <cindyli> np
[12:38:24 CDT(-0500)] <Justin_o> fluid-everyone: pushed cindyli's pull request.. UIO is open for testing again
[12:38:37 CDT(-0500)] <anastasiac> yay!
[12:41:14 CDT(-0500)] <anastasiac> does anyone know a way to clear cookies in IE that doesn't take 5-6 clicks?
[12:41:20 CDT(-0500)] <anastasiac> jhung?
[12:41:27 CDT(-0500)] <anastasiac> Jusin_o, maybe?
[12:42:14 CDT(-0500)] <Justin_o> anastasiac: which IE
[12:42:22 CDT(-0500)] <anastasiac> currently, IE9 in win7
[12:42:25 CDT(-0500)] <Justin_o> i think in IE8 and IE9 you can do it from the developer tools interface
[12:43:13 CDT(-0500)] <anastasiac> thanks, Justin_o!!
[12:43:57 CDT(-0500)] <Justin_o> no problem
[12:53:32 CDT(-0500)] <michelled> Justin_o: is there a JIRA for the fact that the first time you open the sliding panel is does not slide?
[12:53:36 CDT(-0500)] <michelled> FF and Chrome
[12:54:03 CDT(-0500)] <Justin_o> michelled: not that I'm aware of it
[12:54:24 CDT(-0500)] <heidi_> Justin_o i'm guessing build site has cindy's fix?
[12:54:58 CDT(-0500)] <michelled> it seems to be the sakai demo not the demo portal example Justin_o
[12:57:15 CDT(-0500)] <Justin_o> heidi_: yes
[12:57:25 CDT(-0500)] <Justin_o> michelled: okay.. well.. i guess that's better
[12:57:30 CDT(-0500)] <Justin_o> we should still file that though..
[12:57:38 CDT(-0500)] <michelled> yep, filing it now
[12:57:39 CDT(-0500)] <Justin_o> maybe we should think about tossing that demo after this release
[12:57:59 CDT(-0500)] <michelled> I think colinclark still uses it to show UIO in context
[12:58:49 CDT(-0500)] <Justin_o> michelled: okay.. we can see if he thinks the new one will be good enough for that type of demo in the futrure
[13:00:41 CDT(-0500)] <michelled> Justin_o: http://issues.fluidproject.org/browse/FLUID-4503
[13:01:09 CDT(-0500)] <Justin_o> michelled: thanks
[13:01:16 CDT(-0500)] <michelled> np
[13:20:29 CDT(-0500)] <anastasiac> jameswy, why does the UIO with preview have a "reset" button, and UIO without preview has "reset and apply" ?
[13:21:14 CDT(-0500)] <anastasiac> or heidi_ ^
[13:21:38 CDT(-0500)] <heidi_> anastasiac reset is viewable in the preview window
[13:21:49 CDT(-0500)] <heidi_> for without preview, it wouldn't do anything unless it also applied
[13:22:12 CDT(-0500)] <anastasiac> yes, but that's the same as all the other controls, no?
[13:22:37 CDT(-0500)] <heidi_> anastasiac for the controls, you change them, then click save
[13:22:47 CDT(-0500)] <heidi_> reset is sort of an immediate action
[13:23:17 CDT(-0500)] <anastasiac> but why is it immediate without the preview but not with the preview? I'm not sure which way I think is better, but it just seems inconsistent
[13:23:58 CDT(-0500)] <heidi_> anastasiac reset is an action, and the action isn't realised w/o preview unless applied. with preview, you can see it's result in the preview window
[13:24:19 CDT(-0500)] <heidi_> i agree it's weirdly inconsistent but i think that's how it made sense at the time. jameswy ?
[13:25:57 CDT(-0500)] <anastasiac> well, I'm not quite wrapping my head around it, but I'll accept that some thought was put into it, and that it's implemented the way it was intended to be implemented
[13:29:05 CDT(-0500)] <Justin_o> fluid-everyone: anyone have any opions on if this is a blocker http://issues.fluidproject.org/browse/FLUID-4504
[13:31:22 CDT(-0500)] <michelled> Justin_o: I think it should be in known issues but not block.
[13:31:48 CDT(-0500)] <michelled> jameswy: does that seem ok to you?
[13:32:05 CDT(-0500)] <anastasiac> Justin_o, fyi: in safari 5 on 10.7, there is focus styling
[13:32:07 CDT(-0500)] <heidi_> Justin_o is it just wb theme?
[13:33:24 CDT(-0500)] <Justin_o> heidi_: that's the only one i've tried so far
[13:34:07 CDT(-0500)] <Justin_o> heidi_: so yb as well
[13:34:12 CDT(-0500)] <Justin_o> the rest have a dotted black outline
[13:34:33 CDT(-0500)] <heidi_> easy to fix right?
[13:35:11 CDT(-0500)] <Justin_o> heidi_: probably
[13:35:41 CDT(-0500)] <heidi_> since a11y is our priority, i would say blocker
[13:36:07 CDT(-0500)] <michelled> anastasiac: in answer to your question above about reset versus reset and apply, don't forget that integrators will choose one of those options so users will not see an inconsistency
[13:36:22 CDT(-0500)] <anastasiac> michelled, good point
[13:55:39 CDT(-0500)] <Bosmon2> Hi cindyli - could you explain the commit title of your patch, "Ignore the line-height touch when it's not detectable."?
[13:57:05 CDT(-0500)] <cindyli> Bosmon2: apparently i should have made it clearer. :-$
[13:57:47 CDT(-0500)] <cindyli> with firefox, fat panel, retrieving "line-height" value with jquery gets "undefined" returned
[13:57:58 CDT(-0500)] <cindyli> because the iframe div is hidden initially
[13:58:48 CDT(-0500)] <cindyli> the solution in that pull request is, if "undefined" gets returned, don't touch "line-height" style
[13:59:10 CDT(-0500)] <Bosmon2> I'm also wondering what the branch "times === "" " is doing there
[13:59:20 CDT(-0500)] <Bosmon2> Shouldn't we insist that by the time it is used, the value "times" has become a number?
[14:00:24 CDT(-0500)] <Bosmon2> Similar to "lineHeight" also
[14:00:49 CDT(-0500)] <Bosmon2> I think it's an important discipline that inappropriately converted values taken from a model should be normalised as quickly as possible
[14:00:57 CDT(-0500)] <Bosmon2> We ran into issues with this in the Fluid Engage days also
[14:01:08 CDT(-0500)] <cindyli> agree
[14:01:29 CDT(-0500)] <Bosmon2> That somehow every person's hands who a piece of model information passed through came to consider it was their problem to check whether it was "", undefined, null, or any kind of other undesirable thing
[14:03:12 CDT(-0500)] <Bosmon2> My feeling is that an inappropriate value for "times" should be immediately converted to 1, and an inappropriate value for lineHeight should be treated as if it had been "normal"
[14:04:16 CDT(-0500)] <cindyli> regarding line-height, i thought about it. i don't think we can treat it as "normal"
[14:04:43 CDT(-0500)] <cindyli> 'cuz what if the stored setting has been applied
[14:05:01 CDT(-0500)] <cindyli> treating it as "normal" would eliminate the saved setting
[14:06:01 CDT(-0500)] <cindyli> so, the better way is to keep what it was until we get a real value back
[14:06:19 CDT(-0500)] <cindyli> probably not the better, but the safer
[14:07:17 CDT(-0500)] <Bosmon2> cindyli - how could a stored setting that was inappropriate have been applied?
[14:07:24 CDT(-0500)] <Bosmon2> For example, one that was "" or undefined?
[14:07:58 CDT(-0500)] <cindyli> from my discovery, it was because the div is hidden
[14:08:21 CDT(-0500)] <cindyli> certainly the stored setting would not be inappropriate
[14:08:50 CDT(-0500)] <cindyli> but as long as the div is invisible, firefox seems cannot return back whatever line-height on it
[14:09:16 CDT(-0500)] <Bosmon2> Ok - well the "times" issue is not one like this
[14:09:23 CDT(-0500)] <cindyli> exactly
[14:09:28 CDT(-0500)] <Bosmon2> This should be one directly taken from the model, rather than one inferred
[14:09:56 CDT(-0500)] <cindyli> totally agree
[14:10:00 CDT(-0500)] <Bosmon2> And also - the lineheight value is one that is recomputed every time this function exectues
[14:10:15 CDT(-0500)] <Bosmon2> So we should make sure it is normalised at exactly one point in the workflow
[14:11:47 CDT(-0500)] <cindyli> Bosmon2: what do u mean "normalised at exactly one point in the workflow"
[14:11:55 CDT(-0500)] <Bosmon2> It would probably be a lot cleaner to encode the non-existence of the container as a separate flag
[14:12:07 CDT(-0500)] <Bosmon2> Rather than encoding it as special values in one or more of the measurements we take from it
[14:12:27 CDT(-0500)] <Bosmon2> Right now it seems that we encode it by considering that initialHeight is 0
[14:12:56 CDT(-0500)] <Bosmon2> But in another branch, it seems we may also encode it as lineHeight being 0 or not
[14:13:28 CDT(-0500)] <Bosmon2> Similar to our previous unloading of responsibilities from numerizeLineHeight, I think we should ensure not to call this function with invalid values
[14:13:28 CDT(-0500)] <cindyli> i see
[14:14:01 CDT(-0500)] <Bosmon2> That is, by analogy with the principle by which we removed "container" from its argument list before
[14:14:16 CDT(-0500)] <Bosmon2> The function should have a clear responsibility to simply "numerise the line height" : P as its name suggests
[14:14:28 CDT(-0500)] <Bosmon2> And guarding of crazy values from the environment should happen in the caller
[14:15:14 CDT(-0500)] <Bosmon2> It would be great to have at least some kind of test case path for this issue too ...
[14:15:35 CDT(-0500)] <cindyli> i see your point.
[14:17:48 CDT(-0500)] <cindyli> Bosmon2: if that's the case, we also needs to re-construct more of the outer caller
[14:17:50 CDT(-0500)] <cindyli> https://github.com/cindyli/infusion/blob/master/src/webapp/components/uiOptions/js/UIEnhancer.js#L481-483
[14:18:10 CDT(-0500)] <cindyli> you will see these lines expecting a that.initialSize
[14:18:38 CDT(-0500)] <Bosmon2> Yes
[14:18:56 CDT(-0500)] <Bosmon2> The implementation of this function has always been a bit of a mess, but I think it has now been tipped over some kind of critical threshhold : P
[14:19:19 CDT(-0500)] <cindyli> :-$
[14:19:57 CDT(-0500)] <Bosmon2> Its whole implementation should really just consist of line 490
[14:20:03 CDT(-0500)] <Bosmon2> And all the other cruft should happen somewhere else
[14:20:38 CDT(-0500)] <cindyli> i will create a jira for cleaning up this chunk
[14:21:23 CDT(-0500)] <cindyli> do you think it's a blocker?
[14:21:44 CDT(-0500)] <cindyli> i don't think tho
[14:21:46 CDT(-0500)] <Bosmon2> Yes, I think it is... since I regard it as an issue derived from the previous blocker
[14:21:53 CDT(-0500)] <Bosmon2> But other people may have a different opinion
[14:22:05 CDT(-0500)] <michelled> funny you should ask
[14:22:22 CDT(-0500)] <michelled> Justin_o and I were just talking about another bug which we think is a blocker
[14:22:40 CDT(-0500)] <michelled> if we decide that we should fix it then it makes sense to rework the 4500 code too
[14:22:46 CDT(-0500)] <Bosmon2> Otherwise we set a precedent that "resolving a blocker" can be done by code which resolves it in any which way... rather than leaving the code the way we would like
[14:22:57 CDT(-0500)] <Bosmon2> There is always a "tax" to fixing an issue
[14:23:08 CDT(-0500)] <Bosmon2> Which is that if latent issues in the codebase are made worse by the fix, the tax needs to be paid : P
[14:23:49 CDT(-0500)] <Bosmon2> It's like being the next person who goes to the sink, to find it is full of washing-up
[14:24:04 CDT(-0500)] <Bosmon2> You never want the previous person to be able to say, "the washing up wasn't done because it was an emergency" : P
[14:24:05 CDT(-0500)] <Justin_o> Bosmon2: i hate it when that happens
[14:24:30 CDT(-0500)] <michelled> Bosmon2: I completely agree - the only thing that was holding me back from making the rework of the code blocking was the fact that we'd done so much testing that will need to be restarted
[14:24:32 CDT(-0500)] <Justin_o> Bosmon2: although some emergencies can take presidence
[14:24:36 CDT(-0500)] <michelled> we've already restarted the UIO testing a couple times
[14:24:40 CDT(-0500)] <Bosmon2> Justin_o - certainly
[14:24:47 CDT(-0500)] <michelled> and that is a recipe for lack of attention to detail
[14:25:12 CDT(-0500)] <Justin_o> Bosmon2, michelled: I'm leaning towards http://issues.fluidproject.org/browse/FLUID-4504 as a blocker
[14:25:14 CDT(-0500)] <Bosmon2> michelled - that's "good" - if this can be consolidated with another issue that causes testing to be restarted...
[14:25:19 CDT(-0500)] <Bosmon2> Justin_o - I think it is too
[14:25:29 CDT(-0500)] <Justin_o> and if that's the case then we should re-open FLUID-4500 and make the necessary clean up changes too
[14:25:37 CDT(-0500)] <Bosmon2> It's a fundamental failure in a base function of the component
[14:25:55 CDT(-0500)] <Justin_o> fluid-everyone: any arguments against http://issues.fluidproject.org/browse/FLUID-4504 as a blocker
[14:26:06 CDT(-0500)] <Justin_o> heidi_ already made a good case for it being a blocker
[14:26:30 CDT(-0500)] <michelled> it seems an even worse bug in chrome - I don't see any focus styling on the yellow on black theme
[14:26:45 CDT(-0500)] <michelled> except for the sliders that is
[14:27:11 CDT(-0500)] <michelled> ok, looks like we are blocking again
[14:27:16 CDT(-0500)] <michelled> heidi_: are you still around?
[14:27:20 CDT(-0500)] <heidi_> yep
[14:27:44 CDT(-0500)] <michelled> wanna take a crack at 4504 and pull in anyone you need to help you with it?
[14:28:09 CDT(-0500)] <heidi_> sure yep
[14:28:12 CDT(-0500)] <heidi_> i'm on it
[14:28:18 CDT(-0500)] <michelled> thx!
[14:28:39 CDT(-0500)] <Justin_o> Bosmon2: can you re-open FLUID-4500 and leave some comments about what needs to be done
[14:29:02 CDT(-0500)] <Bosmon2> ok
[14:29:34 CDT(-0500)] <michelled> fluid-everyone: please halt your UIO testing again
[14:29:40 CDT(-0500)] <michelled> we have another blocker on the table
[14:30:37 CDT(-0500)] <michelled> Bosmon2, cindyli: can you work together to fix up 4500?
[14:30:56 CDT(-0500)] <heidi_> Justin_o can you remind m how to do the UIO css build again? :|
[14:31:40 CDT(-0500)] <cindyli> sure, michelled
[14:32:06 CDT(-0500)] <Justin_o> heidi_: sure.. if you have your ant stuff all set up, you go to the build-scripts directory and run "ant generateUIOThemes"
[14:32:23 CDT(-0500)] <Justin_o> you might have to set the location of the lib/rhino with -lib flag
[14:32:27 CDT(-0500)] <Justin_o> that part is in the readme
[14:32:29 CDT(-0500)] <heidi_> Justin_o last time i recall having to tell it where ant was... aha ya
[14:37:28 CDT(-0500)] <heidi_> Justin_o getting BUILD FAILED
[14:37:28 CDT(-0500)] <heidi_> for /build-scripts/build.xml:79: java.lang.ClassNotFoundException: org.apache.tools.ant.util.optional.ScriptRunner
[14:38:51 CDT(-0500)] <Justin_o> heidi_: are you using the stock ant?
[14:39:00 CDT(-0500)] <Bosmon2> STOCK ANT!
[14:39:07 CDT(-0500)] <heidi_> Justin_o i have no idea
[14:39:44 CDT(-0500)] <Justin_o> heidi_: did you install ant yourself or did you use the one that came with Mac OS
[14:40:12 CDT(-0500)] <heidi_> Justin_o i can't rmember if i installed ant... how do i get version?
[14:40:50 CDT(-0500)] <Justin_o> okay.. so i'll send you some links one second
[14:41:29 CDT(-0500)] <Justin_o> heidi_: you can download one of the binaries from here http://ant.apache.org/bindownload.cgi
[14:42:34 CDT(-0500)] <Justin_o> let me know if you are able to get that working.. i had to do a work around to get my setup fully running
[14:45:03 CDT(-0500)] <heidi_> Justin_o where do i put the dir
[14:46:13 CDT(-0500)] <Justin_o> heidi_: you should go to /usr/share/ and change the name of the ant directory there or back it up somehow
[14:46:26 CDT(-0500)] <Justin_o> then you can copy the new directory to /usr/share/ant
[14:46:41 CDT(-0500)] <Justin_o> in this new directory you will need to run ant -f fetch.xml
[14:46:52 CDT(-0500)] <Justin_o> to pull down all of the dependencies
[14:47:42 CDT(-0500)] <heidi_> Justin_o looks like the build's working now - thanks!
[14:47:54 CDT(-0500)] <Justin_o> heidi_: a great, no problem
[14:48:43 CDT(-0500)] <Justin_o> if it fails with the war file not being found, you can run the ant task again with sudo.. but you then might need to use sudo to do the cleanup of the build directories later
[14:51:13 CDT(-0500)] <Bosmon2> cindyli - I think we can just assume that "times" is set properly on this side
[14:51:20 CDT(-0500)] <Bosmon2> I cleaned up a lot of these issues in UIE before
[14:51:34 CDT(-0500)] <cindyli> cool. good to know
[14:51:40 CDT(-0500)] <Bosmon2> If the value of the model in the cookie is corrupt, odd things can happen - but it isn't the responsibility of the code on this side to deal with that
[14:52:02 CDT(-0500)] <Bosmon2> If it is a problem, the settings store should make sure that it produces a valid model
[14:52:21 CDT(-0500)] <cindyli> make sense
[14:54:50 CDT(-0500)] <Bosmon2> And in general, all the various places where we read and write from "initialSize" should be consolidated into one
[14:55:54 CDT(-0500)] <Bosmon2> In fact, it would be better if "initialSize" ceased to be a member written onto top-level that
[14:56:06 CDT(-0500)] <Bosmon2> But replaced with a simple boolean flag reflecting whether we have managed to successfully initialise or not
[14:56:17 CDT(-0500)] <Bosmon2> All the other values can just be passed around as arguments
[14:56:41 CDT(-0500)] <Bosmon2> That is, extending the kind of cleanup we made to "numerizeLineHeight" to this whole network of functions
[14:57:10 CDT(-0500)] <Bosmon2> Ideally we want to reduce to an absolute minimum the number of places where we touch "that" (first priority) and also "container" (second priority)
[15:21:01 CDT(-0500)] <heidi_> michelled ... think we should just add fl-focus to the 3 buttons, or should the themes focus buttons specifically in a certain way?
[15:21:53 CDT(-0500)] <michelled> if fl-focus does the job well enough then I think we should go with that
[15:22:04 CDT(-0500)] <michelled> I always prefer a more general solution
[15:22:32 CDT(-0500)] <heidi_> michelled yeah i think that's inline with how fss should work
[15:22:36 CDT(-0500)] <michelled> heidi_: I think the problem goes beyond the buttons however
[15:23:00 CDT(-0500)] <michelled> it looked to me that on chrome yellow and black theme I couldn't see any focus styling
[15:23:56 CDT(-0500)] <heidi_> k will check out chrome as well
[15:25:54 CDT(-0500)] <heidi_> michelled i think putting fl-focus on the body of the demos would be best
[15:26:56 CDT(-0500)] <heidi_> prob for all our demos!
[15:27:01 CDT(-0500)] <heidi_> but i'll just do UIO
[15:28:12 CDT(-0500)] <cindyli> Bosmon2: are you there?
[15:28:33 CDT(-0500)] <heidi_> michelled or maybe better to include the global version of fl-focus hmm
[15:29:06 CDT(-0500)] <heidi_> i forget how we changed focussing styling
[15:29:12 CDT(-0500)] <heidi_> context vs global
[15:30:03 CDT(-0500)] <heidi_> i wonder if this is wrong... global css should have :focus ... global and base have the same (using fl-focus)
[15:30:06 CDT(-0500)] <heidi_> michelled know what i mean?
[15:30:26 CDT(-0500)] <heidi_> might be a question for justin tomorrow
[15:31:31 CDT(-0500)] <heidi_> the demos are including fss-base-global.css ... so i would expect a :focus global style, not fl-focus
[15:37:39 CDT(-0500)] <heidi_> michelled maybe i'm not explaining this well here... sent an email response to the list
[15:38:12 CDT(-0500)] <Bosmon2> Hi cindyli
[15:39:59 CDT(-0500)] <cindyli> Bosmon2: do you think it makes sense to have "times" as the input argument for lineSpacer.set()?
[15:40:06 CDT(-0500)] <cindyli> this line: https://github.com/cindyli/infusion/blob/master/src/webapp/components/uiOptions/js/UIEnhancer.js#L480
[15:40:50 CDT(-0500)] <Bosmon2> cindyli - I think it does, in general
[15:40:53 CDT(-0500)] <cindyli> if it makes sense, this function doesn't seem can be shrinked to just line 490
[15:41:09 CDT(-0500)] <Bosmon2> cindyli the entire body can't - but we should prepare for it to be better in the future
[15:41:17 CDT(-0500)] <Bosmon2> These things will one day be "ants", which have some kind of common signature
[15:41:43 CDT(-0500)] <Bosmon2> So, given that the "outer signature" has to be constant, in the terms, (modelValue, component), we need uniformity there
[15:42:16 CDT(-0500)] <Bosmon2> But we would like to factor away all the other processing which deals with "modelValue" into a self-contained function - so that in the future, it will be clear which part of the function is "model conforming" and which part is "activity"
[15:42:37 CDT(-0500)] <Bosmon2> Right now, yes, we can't avoid actually CALLING the model conforming function in the body of the setter - but that should be all that we do
[15:42:49 CDT(-0500)] <Bosmon2> In the future, we will be able to factor all of these things off so that the framework calls them automatically
[15:43:01 CDT(-0500)] <Bosmon2> But only once we have "got all our ducks in a row" by already having the model conforming function ready
[15:46:50 CDT(-0500)] <cindyli> Bosmon2: i push my change into https://github.com/cindyli/infusion/tree/FLUID-4500
[15:46:56 CDT(-0500)] <cindyli> can you have a look
[15:47:44 CDT(-0500)] <cindyli> only one commit: https://github.com/cindyli/infusion/commit/69bb653484c110a991e11086d9b90ec6de22976f
[16:04:00 CDT(-0500)] <cindyli> Bosmon2: fixed linting error and re-pushed. the old push and log has been removed. so the only commit in this branch now is https://github.com/cindyli/infusion/commit/2817709833c806feede55785e88788d1da22d50c