fluid-work IRC Logs-2011-06-10

Owned by Fluid IRC Log Bot
Last updated: Jun 10, 2011Version comment
24 min read

[07:40:51 CDT(-0500)] <heidi> Justin_o going to do the tabs fix up now - should i cancel my old pull request? i'll send a new one with correct jira
[07:41:21 CDT(-0500)] <Justin_o> heidi: sure, makes sense
[07:41:34 CDT(-0500)] <heidi> Justin_o do i lose pull request comments if i cancel it
[07:42:40 CDT(-0500)] <Justin_o> heidi: not sure.. you can still see the closed pull requests though
[07:46:34 CDT(-0500)] <heidi> Justin_o ok
[08:21:06 CDT(-0500)] <jhung> heidi: hey. I uploaded updated UIO icons. Check it out.
[08:21:17 CDT(-0500)] <heidi> jhung cool, will do
[08:21:48 CDT(-0500)] <jhung> heidi: also let me know if you'll have time to help me out with the fat panel.
[08:22:07 CDT(-0500)] <heidi> jhung likely this afternoon. are you working on it this morning? how's it going?
[08:23:15 CDT(-0500)] <jhung> heidi: yep. Trying to figure out where mysterious tab padding is coming from. (tongue)
[08:23:47 CDT(-0500)] <heidi> jhung k ... i also noticed with fat panel themes there is some strange bg colour stuff going on behind the controls
[08:23:57 CDT(-0500)] <heidi> if you have time to investigate that
[08:24:43 CDT(-0500)] <jhung> I'm focusing on the tabs to get that matching as much as possible. So if you have time this aft, maybe you can look at the tab bodies.
[08:25:17 CDT(-0500)] <jhung> let me know before you start so I can push up my changes to my branch, heidi.
[08:25:50 CDT(-0500)] <heidi> jhung will definitely sync with you before i move to that. cool
[08:41:41 CDT(-0500)] <heidi> hey Justin_o , i think i'm still happy using flc-tabs to label the tabs instead of flc-tabs-tabList. the thing is the component, so i don't think we need component-thing.
[08:42:16 CDT(-0500)] <heidi> just seems simpler
[08:42:29 CDT(-0500)] <Justin_o> heidi: what would you use for the container though?
[08:43:17 CDT(-0500)] <heidi> Justin_o it is the container
[08:43:21 CDT(-0500)] <heidi> no?
[08:43:26 CDT(-0500)] <Justin_o> what do you mean?
[08:43:37 CDT(-0500)] <Justin_o> i'm assuming it's a view component that you would attach tabs to something on
[08:43:51 CDT(-0500)] <Justin_o> or maybe you could just change it to attach the tabs the whatever container is used
[08:46:21 CDT(-0500)] <heidi> Justin_o i guess i'm not sure what the convention is. is the container always supposed to be flc-component name? in practice for fat panel, the container we send is the sliding panel, and for the fss demos, it's just the parent container
[08:48:38 CDT(-0500)] <Justin_o> well i guess that doesn't really matter.. i suppose my question wasn't a good one... (smile) but i think it's kind of strange to just use flc-componentName for something internal... often the selector and the class name will be symetrical.. and should probably be like that
[08:49:31 CDT(-0500)] <Justin_o> that being said.. it may make sense in this case to have no selectors
[08:49:45 CDT(-0500)] <Justin_o> and just create the jQuery ui tabs directly off the container
[08:49:46 CDT(-0500)] <heidi> Justin_o should i be putting flc-tabs somewhere in the demos? would flc-tabs just not exist anymore?
[08:50:06 CDT(-0500)] <heidi> yeah maybe no selectors, just call it on the container
[08:50:50 CDT(-0500)] <Justin_o> heidi: yah.. i think that might be the easiest.. unless there are any objections.. michelled any thoughts from you?
[08:51:27 CDT(-0500)] <heidi> Justin_o hm, i'm still kind of confused
[08:51:55 CDT(-0500)] <heidi> Justin_o cos it has to call .tabs on the div that surrounds the <ul> and tab panels
[08:52:07 CDT(-0500)] <heidi> feels like doing that on .container is too loose
[08:52:21 CDT(-0500)] <heidi> you have to know what container to send it.... ?
[08:52:36 CDT(-0500)] <heidi> it can't just be any div with tabs inside, know what i mean?
[08:54:02 CDT(-0500)] <michelled> seems to me that there is no need for the selector - I agree that the container is enough
[08:54:25 CDT(-0500)] <Justin_o> heidi: when you use it, you will have to make sure to put it on the correct element
[08:55:43 CDT(-0500)] <heidi> Justin_o_ hm. i'll try it
[08:56:38 CDT(-0500)] <Justin_o> heidi: okay
[08:57:32 CDT(-0500)] <heidi> Justin_o i don't think this is gonna work... cos the container for fat panel is the sliding panel, which isn't the right div to run .tabs on
[08:58:05 CDT(-0500)] <heidi> tho actually, it seems to work... so maybe .tabs just looks for a ul within
[08:59:11 CDT(-0500)] <heidi> Justin_o_ ok that was good. this component is like 4 lines ha ha
[08:59:35 CDT(-0500)] <heidi> i wonder if i even need to put flc-tabs anywhere in the markup now
[08:59:40 CDT(-0500)] <heidi> don't think so?
[09:01:18 CDT(-0500)] <michelled> jameswy, heidi: I have a question for you
[09:01:48 CDT(-0500)] <heidi> shoot
[09:02:02 CDT(-0500)] <michelled> in the old UIO we set minimum font size in pixels on the container and removed all the FSS classes that scaled down the font
[09:02:35 CDT(-0500)] <Justin_o__> heidi: probably not
[09:02:48 CDT(-0500)] <michelled> now that people set the font size as a multiplication factor, do we still want to remove the fss classes that scale it down?
[09:03:33 CDT(-0500)] <heidi> michelled i thinkkk so. we still wouldn't want the set font-size to be over-ridden
[09:04:53 CDT(-0500)] <michelled> one of the reasons I'm wondering about this is because the text on the dialog no longer says 'minimum' text size
[09:05:05 CDT(-0500)] <michelled> it just says 'text size' and has a multiplication factor
[09:05:45 CDT(-0500)] <michelled> using the fss classes should end up scaling the text size accordingly.
[09:05:57 CDT(-0500)] <michelled> a concrete example might help
[09:09:38 CDT(-0500)] <michelled> let's say the page has a font size of 10 pixels and there is an fss class on a span inside which scales it down to 8 pixels. If the user sets their text size to 2 times we would change the page font size to 20 pixels and the fss class on the span should still scale down properly to 16 pixels.
[09:10:05 CDT(-0500)] <michelled> so the user would see all the text double in size
[09:10:37 CDT(-0500)] <michelled> if we keep with the current implementation which is a hold over from the old UIO we would remove that fss class and the text in the span would be 20 pixels
[09:10:53 CDT(-0500)] <michelled> heidi, jameswy: thoughts?
[09:11:50 CDT(-0500)] * jameswy is slightly confused.
[09:12:05 CDT(-0500)] <heidi> michelled i guess it depends on what the over-riding style is. if it's em, that multiplication thing works, but if it's 8px it would remain 8px
[09:12:21 CDT(-0500)] <michelled> aren't all the fss classes em heidi?
[09:12:38 CDT(-0500)] <michelled> even in the old way we are only stripping fss classes
[09:12:41 CDT(-0500)] <michelled> not other styles
[09:12:48 CDT(-0500)] <michelled> jameswy: would this be easier in sky[e?
[09:12:58 CDT(-0500)] <michelled> or skype even?
[09:13:15 CDT(-0500)] <jameswy> In the end, if the end-user is seeing 8 px/pt/em/arbitraryunit to begin with (i.e., the calculated style), and the multiplication factor is set to 2x, then they should be seeing 16 px/pt/em/arbitraryunit (as the calculated style)
[09:13:22 CDT(-0500)] <heidi> michelled ah, just fss styles. yes they are all em so you're right
[09:14:04 CDT(-0500)] <michelled> jameswy: that's what I thought - and it means I get to delete code - colinclark would be so happy
[09:14:20 CDT(-0500)] <jameswy> Great, (smile)
[09:16:25 CDT(-0500)] <michelled> cindyli: was there a JIRA for changing text size from pixels to multiplication factor?
[09:16:53 CDT(-0500)] <cindyli> yes, part of 4216
[09:17:27 CDT(-0500)] <heidi> michelled good catch
[09:17:54 CDT(-0500)] <michelled> I think that's too broad a JIRA - Justin_o I'm going to create one for this fix if it's ok with you
[09:18:32 CDT(-0500)] <Justin_o> michelled: sure, could you please also add the bug parade tag to it
[09:18:40 CDT(-0500)] <michelled> sure
[09:21:42 CDT(-0500)] <heidi> Justin_o what does this mean "You might also want to have a way to pass along options into the tabs component. "
[10:00:30 CDT(-0500)] <michelled> Justin_o, cindyli: I just opened this pull request: https://github.com/fluid-project/infusion/pull/71
[10:01:02 CDT(-0500)] <cindyli> ok, michelled
[10:01:03 CDT(-0500)] <michelled> cindyli: I think it makes sense for you to take a peek at it
[10:24:08 CDT(-0500)] <cindyli> i will, michelled. just saw the msg, sorry
[10:48:50 CDT(-0500)] <heidi> Justin_o pull req sent for 4215
[10:52:52 CDT(-0500)] <heidi> and closed the pull for 4229
[11:28:02 CDT(-0500)] <Justin_o> heidi: thanks
[11:58:09 CDT(-0500)] <heidi> jameswy the min width for full w preview appears to be 1060px-ish ... that seems too big no?
[11:58:41 CDT(-0500)] <jameswy> heidi: very. should be 800 or 960
[11:59:01 CDT(-0500)] <heidi> jameswy which one? some of the other layouts don't go to 800
[11:59:14 CDT(-0500)] <jameswy> heidi: Let's go with 960 for now then
[12:00:01 CDT(-0500)] <heidi> jameswy is that sufficient? seems like some resolutions have max 800px. tho i think for osme of these layouts scrolling would still be better than wrapping
[12:00:05 CDT(-0500)] <heidi> so ok 960
[12:26:12 CDT(-0500)] <jameswy> heidi, jhung: do you have time to sync up on UIO in a bit? (say, 1:45?)
[12:26:27 CDT(-0500)] <heidi> jameswy yep
[12:26:36 CDT(-0500)] <heidi> jameswy are you free to help?
[12:27:15 CDT(-0500)] <jhung> jameswy: sure.
[12:27:18 CDT(-0500)] <jameswy> heidi: wherever I can chip in
[12:27:32 CDT(-0500)] <jameswy> alright--we'll Skype it in a bit then
[12:29:42 CDT(-0500)] <heidi> hey colinclark i think for the importants, injecting them in as they were in 1.3 is the safest way to go
[12:29:57 CDT(-0500)] <colinclark> ok
[12:38:22 CDT(-0500)] <Justin_o_> heidi: just looking over your Tabs pull request now
[12:38:51 CDT(-0500)] <heidi> Justin_o look ok?
[12:39:08 CDT(-0500)] <Justin_o_> The copyright information at the top of the js file is incorrect
[12:39:17 CDT(-0500)] <Justin_o_> it should be for OCADU for 2011 and not have the others
[12:39:23 CDT(-0500)] <Justin_o_> also the unit tests are failing
[12:40:51 CDT(-0500)] <heidi> Justin_o_ hm, ok
[12:48:33 CDT(-0500)] <anastasiac> heidi and cindyli, I'm working on instructions for customizing UIOptions by adding another font family to the 'text style' list. Would I be correct in understanding that this won't work properly without supplying a new HTML template that includes the new <option> element?
[12:48:49 CDT(-0500)] <anastasiac> or am I doing something wrong?
[12:48:56 CDT(-0500)] <Justin_o_> heidi: can you tell me again about the bug you had with the tab component and the jquery ui tab options
[12:49:04 CDT(-0500)] <heidi> sec in conf call with james and jon
[12:50:04 CDT(-0500)] <anastasiac> I've added the strings and the controlValues, and the classnameMap for UIEnhancer. The <option> element is added automatically, but a) it has no class and so isn't styled nicely, and b) it has no effect.
[12:50:31 CDT(-0500)] <anastasiac> or rather, it sets to default instead of to courier
[12:51:43 CDT(-0500)] <anastasiac> cindyli, any thoughts? ^
[12:52:06 CDT(-0500)] <cindyli> anastasiac: does the control name of the new font style in classnameMap matches with the one on controlValues?
[12:52:23 CDT(-0500)] <anastasiac> yes, indeed
[12:53:06 CDT(-0500)] <cindyli> ok, interesting, coming over, anastasiac
[13:05:32 CDT(-0500)] <Justin_o_> heidi: i've made some comments on your FLUID-4215 pull request
[13:27:25 CDT(-0500)] <Justin_o_> fluid-everyone: did you want to check in with how your UIO and related work is going
[13:28:53 CDT(-0500)] <cindyli> michelled: i've done with reviewing ur pull request https://github.com/fluid-project/infusion/pull/71. nice work and good catch
[13:28:56 CDT(-0500)] <heidi> Justin_o cool ill fix up 4215
[13:29:05 CDT(-0500)] <michelled> thanks cindyli
[13:29:06 CDT(-0500)] <Justin_o> heidi: thanks
[13:29:25 CDT(-0500)] <michelled> Justin_o_: can you push 71 for me?
[13:29:26 CDT(-0500)] <Justin_o> michelled, cindyli: is it ready to be pushed into the project repo?
[13:29:30 CDT(-0500)] <Justin_o> michelled: sure
[13:29:32 CDT(-0500)] <heidi> Justin_o we just had a layout meeting, jhung jameswy and i .... i'm finishing full w preview, full no preview done, and jon and i will do fat panel. jameswy is going to review all
[13:29:34 CDT(-0500)] <michelled> thx
[13:30:01 CDT(-0500)] <Justin_o> heidi: sounds good.. how long do you think that would take?
[13:30:20 CDT(-0500)] <Justin_o> heidi: also, other than the touchup for the tabs stuff, any more js you're working on?
[13:30:22 CDT(-0500)] <michelled> Justin_o: I'm working on the modifications to UIE based on the code review last week. I should have a pull request ready by end of day
[13:30:31 CDT(-0500)] <heidi> Justin_o we're hoping to finish general lyout clean up today, but i think monday we'll have to spend fixing jameswy's finds and more testing
[13:30:45 CDT(-0500)] <heidi> Justin_o no more js
[13:30:50 CDT(-0500)] <Justin_o> heidi: okay great thanks
[13:30:53 CDT(-0500)] <Justin_o> michelled: thanks
[13:31:08 CDT(-0500)] <Justin_o> mlam, harriswong did you guys want to mention what you're up to?
[13:31:40 CDT(-0500)] <harriswong> Justin_o: TableOfContents unit test
[13:31:45 CDT(-0500)] <mlam> sure. i'm currently working on the live preview of uioptions
[13:31:57 CDT(-0500)] <harriswong> Justin_o: adding more TableOfContent unit tests*
[13:32:14 CDT(-0500)] <heidi> how's live preview going?
[13:32:20 CDT(-0500)] <mlam> we're having problems with listeners and events within an iframe interacting with anything outside of it
[13:32:38 CDT(-0500)] <heidi> feel do-able? jameswy i wonder if we should consider adding buttons to fat panel for 1.4
[13:32:42 CDT(-0500)] <mlam> i'm doing some research online right now
[13:32:55 CDT(-0500)] <jameswy> heidi: Buttons of what sort?
[13:33:06 CDT(-0500)] <heidi> jameswy save/reset/cancel
[13:33:26 CDT(-0500)] <heidi> then when you click save it applies to both UIO and content
[13:33:37 CDT(-0500)] <mlam> and then possibly stick one of our components in an iframe, write a dummy component to listen for events fired by our component within the iframe. if we can't, then we'll have to come up iwth something else
[13:33:57 CDT(-0500)] <jameswy> heidi: That isn't how we're envisioning fat panel to work--changes should apply to the content immediately.
[13:34:02 CDT(-0500)] <cindyli> Justin_o, i'm working on re-factoring ui options to inject ui enhancer thru demands. almost done. i would like to have michelled to take a look before sending out the pull request. after that, should work on 4234 to fix the hanging ui options unit tests on all browsers except ff
[13:34:13 CDT(-0500)] <heidi> jameswy i know, just trying to think of alternatives if the live preview doesn't happen
[13:34:17 CDT(-0500)] <jameswy> Ahh.
[13:34:21 CDT(-0500)] <jameswy> I see.
[13:34:30 CDT(-0500)] <jameswy> (sorry, didn't read the context)
[13:34:51 CDT(-0500)] <jameswy> Yes, if we can't get live preview to work, then that's probably what we'll end up doing.
[13:34:51 CDT(-0500)] <heidi> np. any other thoughts? mlam Justin_o the big issue is applying styles to content and not UIO right
[13:35:09 CDT(-0500)] <heidi> or just UIO changing, as it does now, when you change controls. that's pretty crazy tho
[13:35:27 CDT(-0500)] <jameswy> Justin_o, mlam: how difficult is the problem looking?
[13:35:35 CDT(-0500)] <jameswy> (the problem = live preview)
[13:35:42 CDT(-0500)] <mlam> jameswy: pretty tough. a lot of unknowns
[13:36:06 CDT(-0500)] <jameswy> Hm.
[13:36:18 CDT(-0500)] <jameswy> Does it look doable at all within our timeframe?
[13:36:42 CDT(-0500)] <heidi> mlam like we should come up with a plan b asap ?
[13:37:02 CDT(-0500)] <mlam> heidi: the problem we are having is that we needed to place the UIO in an iframe and inject a separate uiEnhancer for the UIO so that the changes wouldn't take immediate effect
[13:37:42 CDT(-0500)] <mlam> but, we're having a hard time interacting the iframe with the rest of the page
[13:37:50 CDT(-0500)] <heidi> yeah sounds tricky
[13:37:52 CDT(-0500)] <mlam> heidi: I'm not sure
[13:38:04 CDT(-0500)] <heidi> jameswy a plan b would prob be good to have just in case
[13:38:27 CDT(-0500)] <mlam> jameswy: yah, i'm not sure about that either. Justin_o is probably the better person to ask that question
[13:38:40 CDT(-0500)] <jameswy> Justin_o: Does live preview look doable in our timeframe?
[13:39:03 CDT(-0500)] <Justin_o> jameswy: i suppose right now mlam and I are trying to figure out if it is doable in an iframe at all
[13:39:43 CDT(-0500)] <Justin_o> jameswy: we could probably talk about other solutions.. we have some other thoughts on getting the effect you're after without the iframe, but they all have their pros and cons
[13:40:21 CDT(-0500)] <jameswy> Justin_o: Let's hear them.
[13:40:39 CDT(-0500)] <Justin_o> jameswy: i don't think we've fully got them worked out.. yet
[13:40:56 CDT(-0500)] <jameswy> Haha, alright.
[13:41:02 CDT(-0500)] <Justin_o> the two suggestions are 1) don't use an iframe at all.. use two sibling containers and have ui enhancers for each
[13:41:17 CDT(-0500)] <Justin_o> 2) put the content page in the iframe
[13:41:20 CDT(-0500)] <jameswy> So, as heidi was suggesting--is the situation bad enough that I should be looking at design alternatives?
[13:42:36 CDT(-0500)] <Justin_o> jameswy: not sure yet.. it won't be a bad idea to be prepared.. but i think we can get something out
[13:43:36 CDT(-0500)] <jameswy> Justin_o, mlam: alright. Let me know how it is on Monday, and if it's still looking bad technically, we'll swing together a design alternative.
[13:44:01 CDT(-0500)] <Justin_o> jameswy: thanks
[13:44:32 CDT(-0500)] <Justin_o> heidi, cindyli, michelled : do you know if the UI Options roadmap is up-to-date
[13:44:48 CDT(-0500)] <heidi> Justin_o i think so-ish
[13:45:05 CDT(-0500)] <heidi> that's not so helpful. let me look
[13:45:30 CDT(-0500)] <Justin_o> heidi: okay... thanks
[13:45:47 CDT(-0500)] <cindyli> Justin_o, i'm updating my part
[13:45:58 CDT(-0500)] <Justin_o> this is what we have for bug parade http://issues.fluidproject.org/secure/ConfigureReport.jspa?atl_token=hLyns-VDmh&amp;filterid=10128&amp;mapper=components&amp;selectedProjectId=10001&amp;reportKey=com.atlassian.jira.plugin.system.reports%3Asinglelevelgroupby&amp;Next=Next
[13:46:19 CDT(-0500)] <Justin_o> I think there were some more jiras added to bug parade recently, have they made their way on to the roadmap
[13:46:20 CDT(-0500)] <Justin_o> ?
[13:46:29 CDT(-0500)] <heidi> Justin_o it looks up to date - except the new themes are in master now, and michelled is done enhancer updating i think
[13:46:52 CDT(-0500)] <michelled> heidi: not quite - still working on the code review comments
[13:47:00 CDT(-0500)] <heidi> k
[13:47:11 CDT(-0500)] <heidi> then yeah Justin_o roadmap is up to date i think
[13:47:24 CDT(-0500)] <michelled> Justin_o_: I didn't add the JIRA to the roadmap but it's really a subtask of another JIRA that's on there
[13:47:26 CDT(-0500)] <michelled> is that ok?
[13:48:20 CDT(-0500)] <Justin_o> michelled: i suppose so, if that parent one won't be closed till it's done
[13:48:33 CDT(-0500)] <anastasiac> heidi, I'm experimenting with removing the layout controls from the UI Options interface altogether (currently FullNoPreview version). The controls are successfully not being displayed, but the title is - I see that the title for the layout controls template is not in the layout controls template itself, but rather in the main template. Do you think maybe it should be moved? Should I file a JIRA for this? And Justin_o, if so, how would this fit int
[13:48:33 CDT(-0500)] <anastasiac> priorities?
[13:49:29 CDT(-0500)] <heidi> anastasiac i don't think that's a bug - that's the template for our version of full no preview. you would have to create your own template, and set that as the template in your options
[13:49:51 CDT(-0500)] <heidi> putting the header in control templates doesn't work because for ex, fat panel doesn't have those
[13:50:31 CDT(-0500)] <anastasiac> ah. hm. ok. From the user's perspective that's a bit of a pain, but I can see that there might not be an alternative
[13:51:12 CDT(-0500)] <Justin_o> anastasiac: i guess the priority would depend on how it fits with the current designs and intentions.. although i guess you're saying it's a configuration issue if it is actually a bug
[13:51:12 CDT(-0500)] <colinclark> Justin_o_, mlam, jameswy: I'm just catching up on the "live preview" issue
[13:51:17 CDT(-0500)] <colinclark> to be clear, so that I understand it...
[13:51:24 CDT(-0500)] <colinclark> it's not so much the ability to show a live preview
[13:51:30 CDT(-0500)] <anastasiac> well, Justin_o, heidi says it's not a bug, so (smile)
[13:51:36 CDT(-0500)] <colinclark> as the ability to not restyle UIO while we're doing it
[13:51:36 CDT(-0500)] <colinclark> right?
[13:51:45 CDT(-0500)] <heidi> anastasiac well, you're basically making your own kind of UIO, other than the 3 we have. so a new template shouldn't be a surprise?
[13:52:12 CDT(-0500)] <heidi> or... maybe it is something we need to have an option for? headers on off or something
[13:52:23 CDT(-0500)] <Justin_o> colinclark: yes.. the live preview is intended to update the page on the fly, but not the uio itself
[13:52:54 CDT(-0500)] <anastasiac> heidi, I don't know. I know we modularized the different controls, and are planning to modularize it even more. I was assuming that was so that integrators could 'plug-and-play' different subsets.
[13:55:09 CDT(-0500)] <heidi> anastasiac perhaps headers on/off should be a UIO option then? there are limitations regardless with our templates. for ex changing header txt, or removing just one of the controls from the section etc
[13:55:35 CDT(-0500)] <heidi> would all require creating your own templates , but they are easily plugged in. so it is pretty flexible right no
[13:55:36 CDT(-0500)] <heidi> w
[13:55:59 CDT(-0500)] <colinclark> heidi and anastasiac: Can you elaborate on why we need to change a template to change the headers?
[13:56:04 CDT(-0500)] <anastasiac> heidi, good thoughts. Probably not a priority for this release, but something to think about in a bit more detail...
[13:56:11 CDT(-0500)] <colinclark> Is it just because they are just static HTML or something?
[13:56:55 CDT(-0500)] <heidi> colinclark our templates are static html yes
[13:56:57 CDT(-0500)] <anastasiac> colinclark: I am writing instructions for customizing ui options. One customization I imagined that an integrator might like to do is choose only one or two of the three current 'sets' of options, so I removed one of them. The header remained.
[13:57:18 CDT(-0500)] <colinclark> Okay
[13:57:21 CDT(-0500)] <anastasiac> the header is in the main template, separate from the actual controls template, because the fat-panel doesn't want a header
[13:57:43 CDT(-0500)] <colinclark> heidi: So, if anastasiac tutorial was slightly different...
[13:57:56 CDT(-0500)] <heidi> we have 3 templates for each version, then 3 control templates for each control section. the controls plug into the 3 version templates
[13:58:07 CDT(-0500)] <colinclark> if it was about "How to localize UI Options" and showed the user how to translate it into French, what would we say?
[13:58:23 CDT(-0500)] <heidi> colinclark create your own template
[13:58:31 CDT(-0500)] <colinclark> ok
[13:58:33 CDT(-0500)] <heidi> and send it to UIO as an option
[13:58:38 CDT(-0500)] <heidi> template is an option
[13:58:42 CDT(-0500)] <colinclark> right
[13:58:43 CDT(-0500)] <heidi> for both UIO and controls
[13:59:02 CDT(-0500)] <Justin_o> heidi: would that be create your own template? or create your own templates?
[13:59:06 CDT(-0500)] <heidi> but you could just have one french one... doesn't have to use plugin control templates
[13:59:06 CDT(-0500)] <colinclark> So, anastasiac, summarize the workflow you'd document today for this customization you're trying to do?
[13:59:24 CDT(-0500)] <heidi> Justin_o whatever you want
[13:59:43 CDT(-0500)] <Justin_o> heidi: ah configuration.. i like doing whatever I want (smile)
[13:59:49 CDT(-0500)] <heidi> (smile)
[14:00:37 CDT(-0500)] <anastasiac> colinclark, I actually haven't gotten that far, I'm still learning what the workflow is, but so far my understanding is (in brief): two things necessary: 1) override the subcomponent declaration to "emptySubcomponent" and 2) provide a main template that doesn't include the section you don't want
[14:01:01 CDT(-0500)] <colinclark> That's it so far?
[14:01:02 CDT(-0500)] <anastasiac> also, you wouldn't have to provide the url to the unwanted template, of course
[14:01:06 CDT(-0500)] <colinclark> ok
[14:01:13 CDT(-0500)] <anastasiac> yep. I haven't finished testing, but that should do it
[14:01:21 CDT(-0500)] <colinclark> Okay, so here's what I'm thinking...
[14:01:35 CDT(-0500)] <colinclark> In the medium-term, we're going to want to model-ize UIO much more
[14:02:02 CDT(-0500)] <colinclark> but in the meantime, we have a kind of person we try to design simple configuration for...
[14:02:11 CDT(-0500)] <colinclark> usually a webbish person
[14:02:24 CDT(-0500)] <colinclark> Knows some CSS and HTML, maybe a bit of JavaScript and jQuery
[14:02:37 CDT(-0500)] <colinclark> So in your workflow, we're really just asking them to tweak the template
[14:02:43 CDT(-0500)] <colinclark> by remove, say, an <h2> tag or whatever
[14:02:56 CDT(-0500)] <anastasiac> right - should be simple for the audience you've described
[14:02:59 CDT(-0500)] <colinclark> and then give a somewhat confusion option to the UIOptions creator
[14:03:11 CDT(-0500)] <colinclark> So, heidi's probably hit the mark for this release
[14:03:30 CDT(-0500)] <colinclark> What does everyone else think?
[14:03:41 CDT(-0500)] <colinclark> Is that a reasonable configuration workflow to ask someone to do?
[14:04:29 CDT(-0500)] <heidi> i think so, i imagine if someone is wanting to tweak UIO at all, there'd be more than just removing a component? so creating a new template would happen anyway
[14:05:08 CDT(-0500)] <heidi> esp if more modularizing is coming down the pipe later on, it's a good 1.4 approach
[14:05:20 CDT(-0500)] <anastasiac> seems reasonable to me, for now
[14:05:45 CDT(-0500)] <colinclark> All and all, it's a lot more configurability than you'd get from most other JS toolkits
[14:05:51 CDT(-0500)] <colinclark> we just have extra-high standards (smile)
[14:05:54 CDT(-0500)] <anastasiac> indeed!
[14:05:59 CDT(-0500)] <colinclark> anastasiac: I'm quite curious about the reverse case
[14:06:09 CDT(-0500)] <colinclark> Can you walk us through the workflow of adding a new panel or section to UIO?
[14:06:13 CDT(-0500)] <anastasiac> I'm whipping of customization demos pretty easily
[14:06:19 CDT(-0500)] <colinclark> that's wicked!
[14:06:33 CDT(-0500)] <anastasiac> heidi, I'd love to hear about what would be involved to add new types of options
[14:07:08 CDT(-0500)] <anastasiac> from a template perspective, it would be pretty similar to removing, but you'd have to write a subcomponent to go with it, wouldn't you?
[14:07:43 CDT(-0500)] <heidi> anastasiac yeah i'm not sure. haven't thought about it...
[14:07:50 CDT(-0500)] <heidi> sorry brain is css mush right now
[14:08:02 CDT(-0500)] <anastasiac> hm... it will be fun to try (wink)
[14:08:08 CDT(-0500)] <heidi> (smile)
[14:09:00 CDT(-0500)] <colinclark> anastasiac: Let us know once you've had a chance to goof around with it a bit
[14:09:10 CDT(-0500)] <colinclark> I anticipate that it's a feature we're going to need sooner rather than later
[14:09:13 CDT(-0500)] <Justin_o> anastasiac, colinclark: cindyli might have an idea about that
[14:09:30 CDT(-0500)] <colinclark> Bosmon2 and I will be working on some proof of concept demos for the GPII after this release
[14:09:52 CDT(-0500)] <colinclark> and I expect we'll work with jameswy to mock up some other types of preferences, probably related to reading ability
[14:10:29 CDT(-0500)] <colinclark> So, Justin_o and mlam, I'm just getting my head around all the trouble you've had with UIO in an iFrame...
[14:10:36 CDT(-0500)] <colinclark> is there anything I can do to help?
[14:10:39 CDT(-0500)] <colinclark> it sounds pretty challenging
[14:11:30 CDT(-0500)] <Justin_o> colinclark: it's been a bit tough.. we have it rendering in the iframe, but there are problems with the inputs
[14:11:54 CDT(-0500)] <Justin_o> so databinding throws an error, and the slider you have to put focus on in the iframe and then interact with it, from the parent
[14:12:42 CDT(-0500)] <Justin_o> jameswy: are you there?
[14:12:51 CDT(-0500)] <jameswy> Justin_o: Yep.
[14:12:57 CDT(-0500)] <Justin_o> this reminds me of a question that mlam , michelled, and I had this morning
[14:13:30 CDT(-0500)] <Justin_o> jameswy: what happens if you are using the fatpanel, and then refresh the page before closing the panel.. similarly what happens if you navigate to another page before closing the panel..
[14:13:39 CDT(-0500)] <Justin_o> should the changes have saved?
[14:14:54 CDT(-0500)] <jameswy> Justin_o: Great question! Changes should be saved. The real reason UIO isn't affected by UIO until closing is to prevent disorientation to the panel itself during customization.
[14:14:56 CDT(-0500)] <cindyli> anastasiac: adding new types of options is not so easy at this moment. it includes the definitions of the selector, protoTree, corresponding action from ui enhancer etc. Those pieces are now scattered in ui options and ui enhancer. one of our next refractorings of ui options is to collect those pieces into one component each setting. at then, adding new setting would be much easier
[14:15:14 CDT(-0500)] <jameswy> Changes are live and real though. There is no "save".
[14:15:24 CDT(-0500)] <colinclark> Justin_o: I'm not sure I fully understand your second comment... "the slider you have to put focus on in the iframe and then interact with it, from the parent"
[14:15:58 CDT(-0500)] <colinclark> jameswy, Justin_o: So in UIO terminology, that means the changes are saved to the store but not applied by UIE, right?
[14:16:10 CDT(-0500)] <colinclark> until the panel is dismissed
[14:16:56 CDT(-0500)] <Justin_o> colinclark: so what that means is that you put focus on the slider, and then you scrub around in the parent page to actually change its value
[14:17:38 CDT(-0500)] <colinclark> I'm still not sure I understand that
[14:17:42 CDT(-0500)] <colinclark> (smile)
[14:17:44 CDT(-0500)] <anastasiac> cindyli, thanks for the info. I had thought that the refactoring was already done and I'd just have to write a new component with all that stuff in it, but it sounds like we're not quite ready for that yet
[14:17:50 CDT(-0500)] <michelled> that's because it's completely crazy
[14:17:50 CDT(-0500)] <Justin_o> colinclark: that's the case for UIOptions itself, but it is applied to the page right away (in regards to your question to james)
[14:18:01 CDT(-0500)] <Justin_o> colinclark: it's as crazy as it sounds
[14:18:06 CDT(-0500)] <mlam> haha
[14:18:15 CDT(-0500)] <jameswy> colinclark, Justin_o: My UIO/E parlance is pretty weak, but if that means that changes are immediately in effect for everything except the panel itself (in which changes are effected only on reopen), then yes.
[14:18:19 CDT(-0500)] <cindyli> anastasiac: ya, it becomes 1.5 target (smile)
[14:19:01 CDT(-0500)] <jameswy> If my ideas sound crazy, please splash some cold water on me
[14:22:00 CDT(-0500)] <mlam> jameswy: i have a question. If a user is having difficulties viewing the sub-components of the Fat Panel and manages to increase the size of the text with the intentions of making the other sub-component, shouldn't the UIO save and re-render in the same fashion as the live preview?
[14:22:27 CDT(-0500)] <mlam> ie. on the fly
[14:23:41 CDT(-0500)] <mlam> ^^ sorry, ** intentions of making the other sub-components' text larger
[14:25:02 CDT(-0500)] <jameswy> mlam: It's a good point, but the rationale behind a delayed UIO effect is so that the panel acts as a visual anchor for the user. If you're changing the position of the slider while sliding (e.g., when you're adjusting text size), you're making things queasy.
[14:25:20 CDT(-0500)] <jameswy> UI seasickness, if you will.
[14:41:07 CDT(-0500)] <michelled> jameswy: don't forget to bring a towel on Monday (tongue)
[14:45:57 CDT(-0500)] <colinclark> anastasiac: I think if you have the time, I'd go through the exercise of trying to add new options
[14:46:45 CDT(-0500)] <anastasiac> colinclark, I will look into it. cindyli did point out that the code is currently scattered throughout UIOptions and UIEnhancer, but I'll still look into whether or not its possible
[14:46:55 CDT(-0500)] <colinclark> yep, I think that'd be really helpful
[14:51:16 CDT(-0500)] <colinclark> michelled, Justin_o: Interesting Tweet from Richard Worth from jQuery UI...
[14:51:23 CDT(-0500)] <colinclark> "Order of magnitude speed increase minifying hundreds of files by switching a build from Ant+Java+Closure to Make+Node+Uglify."
[14:51:33 CDT(-0500)] <colinclark> I'm guessing this might well be for the jQuery UI build system, though I don't know
[14:51:48 CDT(-0500)] <colinclark> Minification is by far the slowest part of our build process, too
[14:52:11 CDT(-0500)] <colinclark> and, while we use YUICompressor instead of Closure, our processes are otherwise very similar
[14:52:18 CDT(-0500)] <Justin_o> colinclark: yes.. it's very slow
[14:52:42 CDT(-0500)] <Justin_o> colinclark: speaking of tweets, that one from scott gonzalez about replacing attr with prop was good
[14:53:23 CDT(-0500)] <colinclark> Once Bosmon2 or Bosmon4 has Kettle working, we can start to dream about how cindyli will whip up a new Builder, all with JavaScript and Infusion.
[14:53:29 CDT(-0500)] <colinclark> Justin_o: yeah, that one was funny
[14:53:36 CDT(-0500)] <colinclark> it's nice to know we weren't alone in our frustration
[14:54:13 CDT(-0500)] <Bosmon4> We need to make sure that jQuery are made aware of our namespaced id issue in IE9....
[14:55:02 CDT(-0500)] <colinclark> Bosmon4: We may need to file an "escalate" JIRA for it
[14:55:14 CDT(-0500)] <colinclark> and then maybe the King can send it along to the jQuery team once we've shipped 1.4
[14:55:18 CDT(-0500)] <Bosmon4> Good idea
[15:04:56 CDT(-0500)] <colinclark> jameswy: you still around?
[15:05:02 CDT(-0500)] <colinclark> quick Uploader question for you again today
[15:05:08 CDT(-0500)] <jameswy> colinclark: Yep
[15:05:17 CDT(-0500)] <colinclark> having these wireframes to refer to is so great
[15:05:30 CDT(-0500)] <colinclark> So, keyboard navigation
[15:06:01 CDT(-0500)] <colinclark> I imagine we're aiming for simple navigation here
[15:06:04 CDT(-0500)] <colinclark> like any other part of a web page
[15:06:19 CDT(-0500)] <colinclark> as opposed to, say, the row-by-row, desktop-style navigation above in the file queue
[15:06:43 CDT(-0500)] <colinclark> As it stands at the moment, you can tab sequentially to the "Show files"/"Hide details" link
[15:06:47 CDT(-0500)] <colinclark> as well as to the close button
[15:07:08 CDT(-0500)] <colinclark> So if you've got two sets of errors, you'll have two sets of those things to tab to
[15:07:11 CDT(-0500)] <colinclark> which seems about right ot me
[15:07:16 CDT(-0500)] <colinclark> is that what you were imagining?
[15:08:01 CDT(-0500)] <Bosmon4> Justin_o - are my IM messages getting through?
[15:08:01 CDT(-0500)] <jameswy> colinclark: Yep, exactly that.
[15:08:09 CDT(-0500)] <Bosmon4> I'm getting an error right now
[15:08:39 CDT(-0500)] <colinclark> jameswy: So, right now, there's an additional behaviour in the code
[15:08:44 CDT(-0500)] <colinclark> it's a bit strange
[15:08:48 CDT(-0500)] <colinclark> but it might or might not be a feature
[15:09:07 CDT(-0500)] <colinclark> if you have focus anywhere within an error message, you can also hit the delete key
[15:09:12 CDT(-0500)] <colinclark> to close the the panel
[15:09:24 CDT(-0500)] <colinclark> this is a bit non-standard
[15:09:27 CDT(-0500)] <colinclark> is it something we want?
[15:09:48 CDT(-0500)] <Justin_o> Bosmon4: yes.. are mine?
[15:10:01 CDT(-0500)] <Bosmon4> I didn't get any since my last two
[15:10:17 CDT(-0500)] <Bosmon4> Actually I don't see you logged on to IM any more
[15:10:18 CDT(-0500)] <Justin_o> yah.. looks like we just got disconnected there
[15:10:25 CDT(-0500)] <colinclark> jameswy: I don't see any evidence to think that a user would know that this behaviour was there
[15:11:41 CDT(-0500)] <Justin_o> Bosmon4: i think icq just died
[15:11:53 CDT(-0500)] <colinclark> yeah
[15:12:05 CDT(-0500)] <colinclark> I've still got MSN, GTalk, and our crazy XMPP server running
[15:12:07 CDT(-0500)] <colinclark> but no ICQ
[15:13:12 CDT(-0500)] <jameswy> colinclark: It definitely wasn't something I intended, but I could see how it might be useful, and almost (if not actually) sensible...
[15:13:26 CDT(-0500)] <colinclark> I think it probably is a bit confusing for people
[15:13:43 CDT(-0500)] <colinclark> jameswy: Do you see any reason not to remove it from the code until we decide it's something we really want?
[15:14:11 CDT(-0500)] <colinclark> assuming that users can still happily clear errors with the keyboard by focusing the x button?
[15:14:22 CDT(-0500)] <jameswy> colinclark: no reason at all. I agree--let's remove it until we can fully rationalize it.
[15:14:35 CDT(-0500)] <colinclark> thanks, jameswy
[15:35:56 CDT(-0500)] <heidi> Justin_o 4215 fixed and pushed
[15:36:03 CDT(-0500)] <Justin_o> heidi: thanks
[15:36:09 CDT(-0500)] <Justin_o> heidi: oh the other thing
[15:36:32 CDT(-0500)] <Justin_o> what was the issue with the tab options again
[15:36:37 CDT(-0500)] <Justin_o> the one that was giving you an error
[15:36:47 CDT(-0500)] <heidi> Justin_o yeah filed jira for that
[15:36:52 CDT(-0500)] <heidi> in pull request comment
[15:37:08 CDT(-0500)] <heidi> if you use the jq option "disabled: true" you get a js error
[15:37:31 CDT(-0500)] <Justin_o> heidi: so i think you can't set it to true
[15:37:32 CDT(-0500)] <Justin_o> http://jqueryui.com/demos/tabs/#option-disabled
[15:37:39 CDT(-0500)] <Justin_o> it seems like it takes an array
[15:37:52 CDT(-0500)] <Justin_o> to indicate which tabs you want disable
[15:37:53 CDT(-0500)] <Justin_o> d
[15:37:54 CDT(-0500)] <Justin_o> disabled
[15:38:09 CDT(-0500)] <heidi> Justin_o http://jqueryui.com/demos/tabs/#option-disabled
[15:38:19 CDT(-0500)]

<heidi> $( ".selector" ).tabs(

Unknown macro: { disabled}

);


[15:39:16 CDT(-0500)] <Justin_o> heidi: i'm not seeing that at all
[15:39:18 CDT(-0500)] <Justin_o> i have
[15:39:18 CDT(-0500)]

<Justin_o> $( ".selector" ).tabs(

Unknown macro: { disabled}

);


[15:39:37 CDT(-0500)] <heidi> look above
[15:39:47 CDT(-0500)] <heidi> disabled Boolean Default: false
[15:39:58 CDT(-0500)] <heidi> first option mentioned
[15:40:20 CDT(-0500)] <Justin_o> oh i see.. they have two disabled options
[15:40:34 CDT(-0500)] <Justin_o> i'd guess that this first one isn't supposed to be there
[15:40:37 CDT(-0500)] <Justin_o> but i could be wrong
[15:41:32 CDT(-0500)] <Justin_o> heidi: did you try this $( ".selector" ).tabs( "option", "disabled", true );
[15:44:08 CDT(-0500)]

<heidi> Justin_o i'm getting an error with options:

Unknown macro: {tabOptions}

[15:44:18 CDT(-0500)] <heidi> invalid object initializer
[15:44:21 CDT(-0500)] <Justin_o> hmm
[15:44:27 CDT(-0500)] <Justin_o> yah.. i think that set of docs is wrong
[15:44:29 CDT(-0500)] <heidi> but i think i'm having a friday 4.45pm moment? what am i missing
[15:45:16 CDT(-0500)] <Justin_o> heidi: ah.. actually you couldn't call it like that
[15:45:20 CDT(-0500)] <Justin_o> those are arguements
[15:45:30 CDT(-0500)] <Justin_o> so you would have to try just to use it directly first
[15:47:05 CDT(-0500)] <heidi> Justin_o it works if i call it directly
[15:47:32 CDT(-0500)] <Justin_o> hmm.. okay
[15:48:55 CDT(-0500)] <heidi> Justin_o i don't imagine anyone will want to disable fat panel tabs?
[15:49:09 CDT(-0500)] <heidi> but how would you send an array of args via options
[15:51:59 CDT(-0500)] <Justin_o> heidi: you wouldn't
[15:52:01 CDT(-0500)] <Justin_o> i don't think
[16:07:55 CDT(-0500)] <Bosmon4> Life is complete - in THIS basement there is now also a CATTT (smile)