fluid-work IRC Logs-2011-07-29

[05:50:32 CDT(-0500)] <lahabana> Bosmon: Hi are you here?
[07:35:16 CDT(-0500)] <lahabana> Hi colinclark
[07:35:30 CDT(-0500)] <colinclark> Hey
[07:35:46 CDT(-0500)] <colinclark> Congrats on getting your first pull request in to the Infusion framework
[07:35:47 CDT(-0500)] <lahabana> sorry to get on you so early but I've been kind of stuck all morning
[07:35:50 CDT(-0500)] <colinclark> ok
[07:35:52 CDT(-0500)] <lahabana> thx
[07:36:10 CDT(-0500)] <lahabana> It's with the renderer (still )
[07:36:34 CDT(-0500)] <lahabana> I've been trying to put the controllers as a rendererComponent
[07:36:43 CDT(-0500)] <lahabana> but I've got a few little problems
[07:37:26 CDT(-0500)] <lahabana> first just to be sure refreshView remove everything and readds it with its new values no?
[07:38:32 CDT(-0500)] <lahabana> if it's the case is it possible to not update some elements
[07:38:57 CDT(-0500)] <lahabana> In my case: I've got in that controller the scrubber which is a subComponent everything works well
[07:39:33 CDT(-0500)] <lahabana> however everytime I call refreshView the scrubber just disappears from the html...
[07:40:30 CDT(-0500)] <lahabana> also my other issue is that the controller view also has the currentTime display
[07:40:53 CDT(-0500)] <colinclark> yes, you're correct
[07:41:03 CDT(-0500)] <lahabana> and in order to make it update I need to call refreshView everytime the time of the videoChanges (which is really often...)
[07:41:21 CDT(-0500)] <colinclark> Every time the Renderer re-renders, it's going to have to remove all the elements and replace them with fresh versions
[07:41:37 CDT(-0500)] <lahabana> I see
[07:41:51 CDT(-0500)] <lahabana> so I think me using refreshView there is wrong
[07:41:56 CDT(-0500)] <colinclark> Yeah, you probably won't want to be calling refresh view as the result of a timechange event
[07:42:10 CDT(-0500)] <colinclark> The render simply is not made for that level of change
[07:42:10 CDT(-0500)] <colinclark> an
[07:42:25 CDT(-0500)] <lahabana> so I still need to link them to a changeModel listener no?
[07:42:30 CDT(-0500)] <colinclark> Sure
[07:42:32 CDT(-0500)] <colinclark> not a big deal
[07:42:59 CDT(-0500)] <lahabana> ok I thought there was a way to deal with outside updates too
[07:43:17 CDT(-0500)] <lahabana> ok so that solves a part of my problems
[07:43:32 CDT(-0500)] <colinclark>
[07:44:04 CDT(-0500)] <lahabana> I thought that autoBinding and and refreshView would enable me to deal with all the changes in the model
[07:44:13 CDT(-0500)] <lahabana> I misunderstood a part of it
[07:44:18 CDT(-0500)] <lahabana> that's great!
[07:44:23 CDT(-0500)] <colinclark> Well, it will
[07:44:31 CDT(-0500)] <colinclark> but not every case is appropriate for the renderer
[07:44:40 CDT(-0500)] <lahabana> yes
[07:44:50 CDT(-0500)] <lahabana> It good but not magic
[07:45:12 CDT(-0500)] <lahabana> so my other question
[07:45:33 CDT(-0500)] <lahabana> the main videoPlayer usually uses the video tag
[07:45:41 CDT(-0500)] <lahabana> however IE doesn't like it
[07:46:02 CDT(-0500)] <colinclark> yes, that's right
[07:46:18 CDT(-0500)] <lahabana> so is it possible to have a conditionnal template? or something of the kind?
[07:46:34 CDT(-0500)] <lahabana> that would change the video to a div for eg
[07:46:48 CDT(-0500)] <colinclark> what's the context?
[07:47:07 CDT(-0500)] <lahabana> which context?
[07:47:13 CDT(-0500)] <lahabana> fluid.videoPlayer
[07:47:19 CDT(-0500)] <colinclark> What are you actually trying to do?
[07:47:33 CDT(-0500)] <colinclark> Do you have a renderer template, which has a video tag in it?
[07:47:45 CDT(-0500)] <lahabana> not yet but I will soon
[07:47:54 CDT(-0500)] <colinclark> And you're having errors when the Renderer renders it, because IE doesn't like injecting "foreign" elements?
[07:47:57 CDT(-0500)] <colinclark> Is that what you mean?
[07:48:15 CDT(-0500)] <lahabana> well I haven't coded it
[07:48:44 CDT(-0500)] <lahabana> but that error will occur if I do generate a file with a video
[07:48:46 CDT(-0500)] <lahabana> tag
[07:49:07 CDT(-0500)] <lahabana> so I was wondering what could be done to avoid that
[07:49:17 CDT(-0500)] <colinclark> I have a few ideas
[07:49:23 CDT(-0500)] <colinclark> give me a minute to take a look
[07:49:29 CDT(-0500)] <lahabana> ok
[07:49:56 CDT(-0500)] <colinclark> As far as how you'd accomplish something like this in the Renderer...
[07:50:07 CDT(-0500)] <colinclark> you'd have two different chunks of markup
[07:50:15 CDT(-0500)] <colinclark> as you say, one with a <video> tag
[07:50:19 CDT(-0500)] <colinclark> another with a <div>
[07:50:27 CDT(-0500)] <colinclark> both of which would have selectors defined for them
[07:50:38 CDT(-0500)] <colinclark> but you'd omit a "component" in the prototree for one of them
[07:51:11 CDT(-0500)] <colinclark> If there isn't an entry in the component tree to match a selector, the Renderer will not render that element
[07:51:11 CDT(-0500)] <lahabana> ho ok
[07:51:30 CDT(-0500)] <colinclark> but there may be another optoin
[07:51:35 CDT(-0500)] <lahabana> so when I'll generate the tree I'll will just "jump" through one
[07:52:58 CDT(-0500)] <colinclark> yep
[07:53:05 CDT(-0500)] <colinclark> exactly
[07:53:36 CDT(-0500)] <colinclark> Hey Justin_o, are you around?
[07:53:48 CDT(-0500)] <Justin_o> hello
[07:54:09 CDT(-0500)] <colinclark> I'm wondering if your element creation trick might cause IE to behave itself when attempting to inject HTML5 elements
[07:54:19 CDT(-0500)] <colinclark> you know, this: https://github.com/jobara/workshops/blob/master/examples/HTML5-inputs/js/HTML5-backcompat.js
[07:54:41 CDT(-0500)] <lahabana> colinclark: Ok thanks a lot then!
[07:54:52 CDT(-0500)] <lahabana> I think I'm not stuck anymore
[07:54:55 CDT(-0500)] <colinclark> that's great
[07:55:16 CDT(-0500)] <Justin_o> colinclark: it should help with any unknown element tags
[07:55:35 CDT(-0500)] <colinclark> lahabana: You could probably get around the whole issue with Justin's thing
[07:56:04 CDT(-0500)] <colinclark> You can see how he uses it in this example: https://github.com/jobara/workshops/blob/master/examples/HTML5-inputs/html/HTML5-inputs.html#L14-19
[07:56:18 CDT(-0500)] <colinclark> with an IE conditional comment, no less!
[07:56:19 CDT(-0500)] <lahabana> hmm I'll have a look
[07:56:32 CDT(-0500)] <colinclark> This would likely mean you could just render out the <video> tag, and IE wouldn't complain
[07:56:46 CDT(-0500)] <colinclark> I believe this trick was inspired by Modernizr, right Justin_o?
[07:57:17 CDT(-0500)] <lahabana> hmm could be really good indeed!
[07:57:34 CDT(-0500)] <colinclark> It's worth a try, anyway
[07:57:34 CDT(-0500)] <lahabana> I'll try it when I'll be done with the controller
[07:57:36 CDT(-0500)] <lahabana> thx
[07:59:33 CDT(-0500)] <Justin_o> colinclark: it was inspired by http://diveintohtml5.org/ but i think also modernizr
[07:59:38 CDT(-0500)] <colinclark> ah, right
[07:59:44 CDT(-0500)] <colinclark> Dive into HTML5 is so good
[07:59:49 CDT(-0500)] <colinclark> Justin_o: Thanks so much for sending out the email with the list of bug parade, by the way
[08:00:02 CDT(-0500)] <colinclark> I didn't notice the issue of Rhino in our build scripts among them
[08:00:12 CDT(-0500)] <colinclark> do you want me to look at for this release, still?
[08:01:05 CDT(-0500)] <Justin_o> colinclark: oh right… yes.. we should probably do that for this release
[08:01:18 CDT(-0500)] <colinclark> I'll see what I can do this morning
[08:01:18 CDT(-0500)] <Justin_o> i don't think there's a jira filed for that yet
[08:01:30 CDT(-0500)] <colinclark> I'll file one now
[08:01:58 CDT(-0500)] <colinclark> I'll leave you to decide if we should add it to the parade
[08:02:11 CDT(-0500)] <colinclark> I forget what we decided...
[08:02:22 CDT(-0500)] <colinclark> we were going to just ask people to download the jars themselves?
[08:02:48 CDT(-0500)] <Justin_o> colinclark: i think so… and ask them to put it in their user lib folder for ant
[08:02:59 CDT(-0500)] <colinclark> yep
[08:03:15 CDT(-0500)] <colinclark> This is really not too ideal
[08:03:22 CDT(-0500)] <colinclark> but I guess it's probably the best we can do
[08:03:28 CDT(-0500)] <colinclark> I'm trying to think if we could do some kind of Maven
[08:03:29 CDT(-0500)] <colinclark> "
[08:03:32 CDT(-0500)] <colinclark> "no-op" thing
[08:03:51 CDT(-0500)] <colinclark> I guess we'll probably get rid of Maven when we get rid of everything
[08:03:53 CDT(-0500)] <colinclark>
[08:04:49 CDT(-0500)] <Justin_o> colinclark: true.. it's a shame we couldn't make use of ant's -lib argument programattically
[08:05:06 CDT(-0500)] <colinclark> I guess we can
[08:05:10 CDT(-0500)] <colinclark> how are you thinking it would help?
[08:05:17 CDT(-0500)] <colinclark> I must be missing something
[08:05:51 CDT(-0500)] <Justin_o> i think from that link you sent me the other day that you could use the -lib to specify any folder for the lib files.. then we could still ship them in the package
[08:06:01 CDT(-0500)] <Justin_o> and reference the a lib folder there
[08:06:49 CDT(-0500)] <lahabana> Ho btw I've got a question: when I write a function for a modelChanged listener what is the best to do: use the changeRequest.value parameter or use directly the model value. I know there's no actual difference I'm more thinking about code understandability and about what's done on the rest of the code
[08:07:37 CDT(-0500)] <colinclark> Justin_o: hmmm
[08:07:38 CDT(-0500)] <colinclark> yes
[08:07:40 CDT(-0500)] <colinclark> let me think about that
[08:08:00 CDT(-0500)] <Justin_o> colinclark: okay.. let me know what you think
[08:08:50 CDT(-0500)] <colinclark> lahabana: I'd have a look at what some of the other components do
[08:09:25 CDT(-0500)] <lahabana> colinclark: well I had but most of them use another method
[08:09:30 CDT(-0500)] <lahabana> let me find an example
[08:14:11 CDT(-0500)] <lahabana> ok so InlineEdit uses the model directly
[08:14:20 CDT(-0500)] <lahabana> it actually depends
[08:14:42 CDT(-0500)] <lahabana> but apparently when it's inside the same object it uses the model directly
[08:23:14 CDT(-0500)] <harriswong> colinclark: Is there any security settings I need to adjust on IE9(windows 7) in order to use the uploader?
[08:23:41 CDT(-0500)] <colinclark> harriswong: Not from a server, no
[08:23:54 CDT(-0500)] <colinclark> Locally, you'll have to do the usual Flash security settings
[08:24:20 CDT(-0500)] <colinclark> lahabana: I'd go with the approach that you think makes most sense for your code, and if there's some consistency with the other components, that's good too
[08:24:43 CDT(-0500)] <lahabana> colinclark: ok great Thx
[08:28:20 CDT(-0500)] <harriswong> colinclark: if i don't have flash on IE9, should i expect a blank screen for the uploader demo page?
[08:28:43 CDT(-0500)] <colinclark> Expecting a blank screen any time sort of seems like a bad idea, eh, harriswong?
[08:28:44 CDT(-0500)] <colinclark>
[08:29:08 CDT(-0500)] <colinclark> If you don't have Flash on any platform, you should see the basic single file upload widget
[08:30:19 CDT(-0500)] <harriswong> colinclark: mm. For some strange reasons, IE9 on Windows 7 gives me a blank page on the build site demo.
[08:30:29 CDT(-0500)] <colinclark> Any errors?
[08:32:25 CDT(-0500)] <harriswong> colinclark: not that i am aware of on the console. I have log messages though.
[08:33:09 CDT(-0500)] <harriswong> colinclark: i also tried swapping between "browse mode" and "document mode", it's the same
[08:33:22 CDT(-0500)] <colinclark> Wouldn't hurt to fire up the debugger and see if you can see what's happening
[08:34:07 CDT(-0500)] <colinclark> This is on the build server, right?
[08:34:12 CDT(-0500)] <harriswong> correct
[08:38:49 CDT(-0500)] <colinclark> Sounds like a bug to me
[08:40:31 CDT(-0500)] <harriswong> should I add a jira for it?
[08:40:54 CDT(-0500)] <colinclark> harriswong: yep
[08:41:14 CDT(-0500)] <colinclark> And, if you can, do some poking around in the debugger and see if you can figure out what's going on
[08:42:09 CDT(-0500)] <harriswong> currently poking furiously at the IE 9 "almighty debugger"
[08:48:26 CDT(-0500)] <harriswong> colinclark: i have added the log messages to FLUID-4382
[09:12:23 CDT(-0500)] <colinclark> michelled and yura_, there should be a simple way around this IE7 and JSON silliness in the CollectionSpace project
[09:12:48 CDT(-0500)] <colinclark> You can wrap the script tag for JSON2.js in an IE conditional comment
[09:13:05 CDT(-0500)] <colinclark> I was reminded of this technique when I was looking at Justin_o's HTML5 shim this morning
[09:13:15 CDT(-0500)] <colinclark> Here's an example: https://github.com/jobara/workshops/blob/master/examples/HTML5-inputs/html/HTML5-inputs.html#L14-19
[09:14:01 CDT(-0500)] <colinclark> The real solution, I think, is for kasper to step up and make it clear that he made his platform support decisions in order to ensure that we could reasonably support a small set of browsers with comprehensive QA testing.
[09:14:37 CDT(-0500)] <michelled> ya, I'm going to respond to his browser support thread today
[09:15:04 CDT(-0500)] <michelled> the bigger issue is that we made the decision not to support IE so we actually have no idea what works and what doesn't in IE in cspace
[09:15:23 CDT(-0500)] <colinclark> I'm keen to hear kasper make one of his typically inspiring, clear, and definitive comments about this issue, michelled
[09:15:25 CDT(-0500)] <michelled> so it's not so simple to just look at the surface bug - but fair enough when it's found we can fix it
[09:16:19 CDT(-0500)] <michelled> colinclark: thanks for pointing me at IE conditional comments - it certainly is a good technique
[09:26:01 CDT(-0500)] <colinclark> michelled: "Good techniques," yes
[09:26:29 CDT(-0500)] <colinclark> It's an insane technique, but IE is awfully extreme
[09:27:23 CDT(-0500)] <michelled> I suppose it's a nice use of IE only functionality
[10:02:12 CDT(-0500)] <colinclark> Justin_o: Quick question?
[10:02:22 CDT(-0500)] <Justin_o> colinclark: sure
[10:02:41 CDT(-0500)] <colinclark> So, you're right that we can't do anything programmatic with -lib, for the obvious reasons
[10:02:57 CDT(-0500)] <colinclark> What about the idea of just asking people to do their choice of two things:
[10:03:07 CDT(-0500)] <colinclark> 1. add the -lib lib/rhino flag when they run the build
[10:03:22 CDT(-0500)] <colinclark> 2. copy the contents of lib/rhino to their ~/.ant/lib
[10:03:24 CDT(-0500)] <colinclark> based on preference
[10:03:28 CDT(-0500)] <colinclark> both of these are kludgy
[10:03:34 CDT(-0500)] <colinclark> but I wonder if everything is kludgy
[10:03:47 CDT(-0500)] <Justin_o> colinclark: it may all be
[10:04:10 CDT(-0500)] <Justin_o> so the ant script itself would be the same for both these cases right?
[10:04:22 CDT(-0500)] <colinclark> yep
[10:04:29 CDT(-0500)] <Justin_o> colinclark: okay.. then i think that's probably fine
[10:04:37 CDT(-0500)] <colinclark> And we'd continue to do my evil thing of keeping those Rhino jars in Git
[10:04:41 CDT(-0500)] <colinclark> Linus would not approve
[10:04:46 CDT(-0500)] <Justin_o>
[10:05:20 CDT(-0500)] <Justin_o> i like that we're giving the user the option to not have to modify their version of rhino
[10:07:04 CDT(-0500)] <colinclark> I guess in both cases we're telling them not to
[10:07:29 CDT(-0500)] <colinclark> and in the -lib case, they needn't even worry about having it overridden by the presence of an earlier-loaded copy in ~/.ant/lib
[10:07:40 CDT(-0500)] <colinclark> Maybe that's what you actually meant
[10:08:12 CDT(-0500)] <colinclark> Justin_o: On another topic...
[10:08:32 CDT(-0500)] <colinclark> at some point, I would love to talk you through this plan that jhung and I put together yesterday afternoon http://wiki.fluidproject.org/display/fluid/Decapod+Roadmap
[10:08:38 CDT(-0500)] <colinclark> It can wait until the release is out
[10:08:52 CDT(-0500)] <Justin_o> colinclark: okay sure.. i'll take a peak at it now though
[10:08:57 CDT(-0500)] <colinclark> But, in short, we tried to narrow in on a "minimum viable application" or maybe "user experience" for Decapod
[10:09:24 CDT(-0500)] <colinclark> And trying to modularize out any of the potential instability of the application due to different, research-level approaches for dewarping
[10:09:47 CDT(-0500)] <colinclark> So we'll start with an app that can import images from any source, but that already meets some basic criteria for good enough quality
[10:10:05 CDT(-0500)] <colinclark> and from there will make a really great UX for organizing and tweaking your book and generating a searchable PDF from it
[10:10:43 CDT(-0500)] <heidi_> jameswy you are okay with colours not being AA or AAA compliant ?
[10:10:46 CDT(-0500)] <Justin_o> colinclark: ah makes sense.. then the different types of capture can be completely different apps or work flow plugins to decapod
[10:11:26 CDT(-0500)] <colinclark> heidi_: lol, that's a loaded question!
[10:11:36 CDT(-0500)] <colinclark> Justin_o: yep, exactly
[10:11:47 CDT(-0500)] <heidi_> jameswy for IDI site!
[10:12:29 CDT(-0500)] <jameswy> heidi_: Yes. greggy1, Jon, Jan and I had a chat about this a while back. We came to the agreement that non-AA/AAA compliant colour schemes are acceptable, so long as there's an alternative being offered. That's what UIO is here for.
[10:12:55 CDT(-0500)] <heidi_> jameswy yikes!
[10:13:21 CDT(-0500)] <heidi_> even i had trouble seeing chi's blue - i think be default it has to be easy to read, no?
[10:13:33 CDT(-0500)] <jameswy> I don't think it's a good idea to have contrasts that no one can read, but so long as the default is reasonably readable, I have no issue with it not meeting full compliance if we have alternatives offered.
[10:13:44 CDT(-0500)] <jameswy> Yes. See ^
[10:14:01 CDT(-0500)] <heidi_> jameswy wouldn't "easy to read" reflect compliance?
[10:15:30 CDT(-0500)] <heidi_> Justin_o when can i had UIO to idi site? hoping to launch round one next week...
[10:15:35 CDT(-0500)] <heidi_> *add not had
[10:15:45 CDT(-0500)] <Justin_o> heidi_:
[10:15:45 CDT(-0500)] <jameswy> heidi_: I don't think so--not completely, anyways. What if the IDI site were a strict white-on-black by default (and thus AAA compliant), but the user (as some do) found it easier to read black-on-yellow?
[10:15:48 CDT(-0500)] <colinclark> jameswy and heidi_: I offer this up for your enjoyment: http://contrastrebellion.com/
[10:16:17 CDT(-0500)] <Justin_o> heidi_: i guess it's up-to-you.. you could probably add a pre-release version if you like. Infusion 1.4 won't be out next week
[10:16:29 CDT(-0500)] <colinclark> heidi_: Johnny's already done it with a prerelease version in his WordPress theme
[10:16:39 CDT(-0500)] <jameswy> colinclark: Cool site!
[10:17:04 CDT(-0500)] <colinclark> jameswy: The irony of it is that it flickers horrendously on an iPad
[10:17:08 CDT(-0500)] <colinclark> contrast, indeed
[10:17:44 CDT(-0500)] <colinclark> I like things like this, as sort of "new era public awareness campaigns"
[10:18:15 CDT(-0500)] <jameswy> heidi_: In the end, I don't think we need full AA/AAA compliance by default. I'd just like it to be "easily readable by most" by default. And I don't think that necessarily means full AA/AAA compliance.
[10:18:41 CDT(-0500)] <heidi_> jameswy interesting...
[10:19:43 CDT(-0500)] <heidi_> colinclark emailing johnny now!
[10:20:19 CDT(-0500)] <colinclark> just to see how he's doing?
[10:22:19 CDT(-0500)] <heidi_> colinclark he hasn't sent me his theme yet so a nudge
[10:22:30 CDT(-0500)] <colinclark> great idea
[10:22:37 CDT(-0500)] <colinclark> I want to use it for my personal blog, too
[10:22:39 CDT(-0500)] <heidi_> and asking him his thoughts on websitey semantics added to theming
[10:22:52 CDT(-0500)] <colinclark> I'm sure he'll have tons of thought, with some time
[10:23:04 CDT(-0500)] <heidi_> jameswy are we going with chi's orig blue then? maybe i'll get her to make it at least a bit darker
[10:23:15 CDT(-0500)] <jameswy> heidi_: No, Chi's working on adjust the colours.
[10:23:19 CDT(-0500)] <heidi_> ok
[10:23:19 CDT(-0500)] <jameswy> adjusting*
[10:24:01 CDT(-0500)] <heidi_> k cool thanks jameswy
[10:24:43 CDT(-0500)] <heidi_> will also need the "fallback" bg colours for browsers that can't do css3 grads
[10:25:02 CDT(-0500)] <Justin_o> mlam: are you working on space now?
[10:27:44 CDT(-0500)] <jameswy> heidi_: The whole "easier to read" deal is a bit of a convoluted problem, I think. WCAG tried to simplify the situation by giving us quantifiable equations to calculate a line where on one side we have "not easy to read" and the other "easy to read". It's a really strict, artificial binary, and I'm really not comfortable with it. "Easy to read" is more nuanced than one or two lines in the sand.
[10:28:23 CDT(-0500)] <heidi_> jameswy i hear ya. i guess it would be a case of pleasing the majority by default?
[10:28:44 CDT(-0500)] <heidi_> and providing options for others (UIO)
[10:29:26 CDT(-0500)] <jameswy> I think that's the idea, yeah. Be reasonable and sensible, and make sure the majority can read it easily, and provide the means to adjust it if you're in a state or context that you can't.
[10:29:54 CDT(-0500)] <heidi_> jameswy i guess i'm wondering if WCAG's guidelines would reflect that "majority" best default
[10:30:01 CDT(-0500)] <heidi_> i feel like that would be the case
[10:30:30 CDT(-0500)] <mlam> Justin_o: Yah, i'm pairing with yura right now . he's taking me through a code tour
[10:30:42 CDT(-0500)] <heidi_> ya'll coming to stand up?
[10:30:57 CDT(-0500)] <Justin_o> mlam: okay.. can i move the tasks you had added back to the pile?
[10:31:04 CDT(-0500)] <jameswy> heidi_: I think it probably goes well above and beyond the "majority best default", and heavily limits the designer's choice of colour palettes.
[10:31:07 CDT(-0500)] <Justin_o> or did you happen to finish them yesterday?
[10:31:47 CDT(-0500)] <heidi_> jameswy ah
[10:36:35 CDT(-0500)] <Justin_o> fluid-everyone: Apparently Adobe connect and Lion don't get along. I can't click any of the options in the modal dialog for choosing the camera and the audio. Anyways, my update is that I sent out e-mails this morning regarding the Infusion 1.4 release. We are code freezing/Testing everything except for UIO, ToC, and FSS. I also sent out a list of the issues that the walkthrough of UIO with James and Michell
[10:36:35 CDT(-0500)] <Justin_o> unearthed
[10:44:01 CDT(-0500)] <mlam> Justin_o: yes pls
[10:44:06 CDT(-0500)] <Justin_o> michelled, colinclark: was there a decision made about the url issue for the uio themes
[10:44:09 CDT(-0500)] <Justin_o> mlam: thanks
[10:45:55 CDT(-0500)] <colinclark> Justin_o: Remind me again of the issue
[10:47:33 CDT(-0500)] <Justin_o> colinclark: because we are putting the UIO generated themes in a new location, the relative paths to their images are all wrong
[11:04:05 CDT(-0500)] <michelled> Justin_o: not sure if you and colinclark talked about this already - I think we decided to change the build so that we fix the urls when we generate the stylesheets
[11:04:16 CDT(-0500)] <colinclark> oh yes, right
[11:04:23 CDT(-0500)] <colinclark> "our parser is earning its keep"
[11:04:48 CDT(-0500)] <Justin_o> michelled, colinclark : okay thanks
[11:04:57 CDT(-0500)] <colinclark> who should do it?
[11:06:06 CDT(-0500)] <michelled> Justin_o, colinclark: I can start it after I'm done the cspace meeting and I've looked at pull requests
[11:06:23 CDT(-0500)] <michelled> Justin_o: do we have a JIRA for it yet?
[11:06:35 CDT(-0500)] <Justin_o> michelled: i don't think so
[11:06:36 CDT(-0500)] <michelled> Justin_o: there are also the failing tests - I'd looked at them but not fixed them
[11:06:47 CDT(-0500)] <Justin_o> oh forgot about that
[11:06:56 CDT(-0500)] <Justin_o> do you know what's caused them
[11:07:12 CDT(-0500)] <michelled> yes, the change in the theme names
[11:07:23 CDT(-0500)] <michelled> but I think we actually decided that the tests are not reasonable
[11:07:29 CDT(-0500)] <michelled> I'd need to look at them again
[11:08:00 CDT(-0500)] <Justin_o> michelled: okay..
[11:12:42 CDT(-0500)] <colinclark> So, michelled, can you take the lead on those two issues...
[11:12:50 CDT(-0500)] <colinclark> and delegate to me wherever you need?
[11:21:17 CDT(-0500)] <Justin_o> colinclark, michelled: i filed a jura for the path issues with the generated stylesheets http://issues.fluidproject.org/browse/FLUID-4383
[11:45:33 CDT(-0500)] <anastasiac> cindyli, in your options-munging branch (FLUID-4353), have the demos been updated to use the new options-munging format yet?
[11:45:56 CDT(-0500)] <cindyli> yes, anastasiac
[11:48:11 CDT(-0500)] <anastasiac> cindyli, have you pushed your changes to github? I'm looking at the demos now, and unless I'm completely misunderstanding the new format, it doesn't look like it: https://github.com/cindyli/infusion/blob/FLUID-4353/src/webapp/demos/uiOptions/FullPreviewUIOptions/html/uiOptions.html#L67
[11:49:12 CDT(-0500)] <cindyli> yes, that's the new change. u feel anything wrong?
[11:50:37 CDT(-0500)] <anastasiac> no, cindyli, I guess I just misunderstood. I thought the idea was to move options like tocTemplate up, something like "previewEnhancers.*.tocTemplate" I'm reading Bosmon's email from Wednesday. Is that not the way it's being implemented?
[11:52:16 CDT(-0500)] <cindyli> move tocTemplate up is one of the goals. the main goal of "options munging" is to config all the sub-componets as component inital options, instead of thru commands block
[11:53:24 CDT(-0500)] <anastasiac> ok. So that format that Bosmon described in his email, with the * in the paths, is the way an integrator would customize subcomponent options?
[11:54:08 CDT(-0500)] <cindyli> anastasiac: no, the integrator doesn't need to care about the "*"
[11:54:17 CDT(-0500)] <cindyli> let me find the code, easier to explain
[11:55:51 CDT(-0500)] <cindyli> anastasiac: https://github.com/cindyli/infusion/blob/FLUID-4353/src/webapp/components/uiOptions/js/UIOptions.js#L199-210
[11:56:11 CDT(-0500)] <anastasiac> right, cindyli, I get that
[11:56:23 CDT(-0500)] <cindyli> anastasiac: the only thing you and the integrator care about is the right side of the config
[11:56:59 CDT(-0500)] <anastasiac> so to customize, the integrator will have a "config" block in their options, with paths like these, with * in them?
[11:57:10 CDT(-0500)] <anastasiac> ah, no
[11:57:11 CDT(-0500)] <anastasiac> I get it
[11:57:18 CDT(-0500)] <cindyli> haha
[11:57:22 CDT(-0500)] <anastasiac> the integrator uses an option name taken from the right column
[11:57:29 CDT(-0500)] <anastasiac> is that right, cindyli?
[11:57:32 CDT(-0500)] <cindyli> exactly
[11:57:38 CDT(-0500)] <anastasiac> ok, cool
[11:57:44 CDT(-0500)] <anastasiac> I'll work with that and test it out
[11:57:47 CDT(-0500)] <anastasiac> thanks, cindyli
[11:57:50 CDT(-0500)] <cindyli> thanks, anastasiac
[12:00:32 CDT(-0500)] <heidi_> jameswy do you know what the css3 texture style is called
[12:01:07 CDT(-0500)] <anastasiac> so, cindyli, on my first attempt, I'm finding a problem I want to override the preview subcomponent's templateUrl, but there's nothing in the "config" for that
[12:04:40 CDT(-0500)] <cindyli> anastasiac: so, basically, u want to config subcomponent "preview"?
[12:04:59 CDT(-0500)] <cindyli> isn't that mapping to "preview"
[12:05:40 CDT(-0500)] <anastasiac> cindyli, I have a demo that customizes the path to the template file i.e. my template file is not in the default location, or doesn't have the default file name, so I need to specify that somehow. Currently, that's the "templateUrl" option of the preview subcomponent
[12:06:21 CDT(-0500)]

[12:06:30 CDT(-0500)] <anastasiac> i.e. keep the "options" sub-block for preview?
[12:07:13 CDT(-0500)] <anastasiac> so, cindyli, the config blocks surface the subcomponents themselves, but not their options. Is that correct?
[12:07:52 CDT(-0500)] <cindyli> no, but the options surface along with the subcomponent
[12:08:18 CDT(-0500)] <cindyli> anastasiac: let me pastie the code that might be what u want
[12:09:10 CDT(-0500)] <cindyli> anastasiac: http://pastie.org/2290830
[12:09:51 CDT(-0500)] <anastasiac> yes, right - that's what I was trying to describe (obviously not succeeding!)
[12:09:56 CDT(-0500)] <anastasiac> that's what I wanted to know, thanks cindyli
[12:10:10 CDT(-0500)] <cindyli> cheers, anastasiac
[12:14:10 CDT(-0500)] <anastasiac> cindyli, I'm going to bug you again
[12:14:28 CDT(-0500)] <cindyli> sure, anastasiac
[12:14:42 CDT(-0500)] <anastasiac> I've always wondered why uiOptions itself has options for textSize and lineSpacing. Wouldn't these be options for textControls?
[12:15:04 CDT(-0500)] <cindyli> yes, u r certainly right
[12:15:25 CDT(-0500)] <anastasiac> would your current refactoring be a good time to change that?
[12:15:44 CDT(-0500)] <cindyli> at the initial design, uiOptions component is a top-level component, we had textSize and lineSpacing for easier configuration
[12:16:01 CDT(-0500)] <cindyli> anastasiac: i certainly could change that
[12:16:10 CDT(-0500)] <cindyli> probably with a new jira after options munging
[12:16:24 CDT(-0500)] <anastasiac> I think it would make the API much more consistent if you do. I can file the JIRA if you like
[12:16:35 CDT(-0500)] <cindyli> sure, anastasiac. thanks
[12:20:07 CDT(-0500)] <anastasiac> Justin_o, cindyli and I were just discussing an oddity in the UIO API that seems to be a holdover from the past, one which is even less necessary now with the new options-munging: some textControls options are present right on UIO, when they really shouldn't be. I'm filing a JIRA for this, separate from the options-munging work itself. I'm not sure if I should file this as "fix-for" 1.4, or blocker, or what?
[12:21:16 CDT(-0500)] <Justin_o> anastasiac: i'm not sure i fully understand.. where are the rest of the options?
[12:22:29 CDT(-0500)] <anastasiac> the rest of the textControls options are properly part of the textControls subcomponent, i.e. defaults are in its defaults, block, etc. But two (textSize and lineSpacing) are in the UIO defaults directly, and passed to textControls via IoC
[12:22:51 CDT(-0500)] <anastasiac> this was done a while ago to make it easier to customize, but it doesn't seem necessary now
[12:22:59 CDT(-0500)] <anastasiac> and it's pretty inconsistent with everything else
[12:23:27 CDT(-0500)] <huslage> hey
[12:23:40 CDT(-0500)] <Justin_o> anastasiac: ah i see… okay seems reasonable to fix that now
[12:23:53 CDT(-0500)] <anastasiac> "now" i.e. a blocker for 1.4, Justin_o?
[12:25:45 CDT(-0500)] <Justin_o> anastasiac: sure.. if it proves to be too complicated and not worth the time then we may change the priority.. but if you think it's a straightforward fix then I think we should get it in
[12:26:03 CDT(-0500)] <anastasiac> ok, thanks, Justin_o
[12:26:34 CDT(-0500)] <Justin_o> np, thanks for spotting that
[12:58:12 CDT(-0500)] <michelled> Justin_o: what does it mean to have 'relative indentation'?
[12:58:29 CDT(-0500)] <michelled> I'd like to test harriswong's fix but I'm not sure what I'm looking for
[12:59:49 CDT(-0500)] <Justin_o> michelled: the terminology around that stuff is all pretty confusing.. i think it means that indentation should indicate dependency but necessarily be 1 to 1 with level.. so if you got from H1 to H3 there will only be 1 level of indentation
[13:00:02 CDT(-0500)] <Justin_o> michelled: jameswy should be able to clarify it further
[13:01:40 CDT(-0500)] <jameswy> michelled: Justin_o explained it well. In case it helps any further: relative indentation takes into account the headers' relative nesting to each other.
[13:02:18 CDT(-0500)] <michelled> ok, thx
[13:21:26 CDT(-0500)] <Justin_o> michelled, colinclark: can you tell me how to add additional rules to the css generation.. i think we might have to add !importants to the border-color too
[13:21:40 CDT(-0500)] <colinclark> Justin_o: sure, it's pretty easy
[13:21:43 CDT(-0500)] <colinclark> let me just pull up the code
[13:22:24 CDT(-0500)] <Justin_o> colinclark: thanks
[13:23:34 CDT(-0500)] <colinclark> Oh, this is interesting
[13:23:44 CDT(-0500)] <colinclark> It looks like we're not actually putting !important on all the things we should have
[13:23:53 CDT(-0500)] <colinclark> https://github.com/fluid-project/infusion/blob/master/build-scripts/uiOptions/js/StylesheetImportant.js#L27-33
[13:24:08 CDT(-0500)] <colinclark> So at line 31, you can see this data structure
[13:24:17 CDT(-0500)] <colinclark> I believe it's been "dehydrated" a bit for convenience
[13:24:41 CDT(-0500)] <colinclark> The left hand side identifies which selectors to apply the rule to
[13:24:49 CDT(-0500)] <colinclark> In this case, we're using a special symbol for "all selectors"
[13:25:03 CDT(-0500)] <colinclark> The right hand side can be a list of declarations
[13:25:21 CDT(-0500)] <Justin_o> colinclark: okay..
[13:25:30 CDT(-0500)] <colinclark> So you should be able to modify it to look like this: ["background-color", "border-color", ...]
[13:25:34 CDT(-0500)] <colinclark> but I'm really confused
[13:25:36 CDT(-0500)] <colinclark> We had a list
[13:25:42 CDT(-0500)] <colinclark> I remember having actually written that list out
[13:25:45 CDT(-0500)] <colinclark> but this isn't it anymore
[13:25:51 CDT(-0500)] <colinclark> I wonder if somehow I regressed it
[13:26:38 CDT(-0500)] <colinclark> It looks like it always looked like that
[13:26:40 CDT(-0500)] <colinclark> Was I dreaming?
[13:26:48 CDT(-0500)] <michelled> you wrote a list on the JIRA for sure
[13:27:04 CDT(-0500)] <michelled> or maybe in an list mail?
[13:27:39 CDT(-0500)] <Bosmon> I am often dreaming I have done stuff
[13:27:57 CDT(-0500)] <colinclark>
[13:28:28 CDT(-0500)] <colinclark> Freaking JIRA
[13:28:41 CDT(-0500)] <colinclark> I search for the string "!important"
[13:28:43 CDT(-0500)] <colinclark> and it responds with
[13:28:45 CDT(-0500)] <colinclark> "Invalid start character '!'"
[13:28:50 CDT(-0500)] <Justin_o>
[13:29:06 CDT(-0500)] <Justin_o> colinclark: http://issues.fluidproject.org/browse/FLUID-4219
[13:29:07 CDT(-0500)] <Bosmon> At least it doesn't respond by finding everything which DOESN'T contain the string "important"
[13:29:35 CDT(-0500)] <colinclark> okay, so writing a comment in JIRA is not the same as writing something in code, right?
[13:29:46 CDT(-0500)] <colinclark> http://issues.fluidproject.org/browse/FLUID-4219?focusedCommentId=20853&amp;page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-20853
[13:30:12 CDT(-0500)] <Justin_o> which leads me to something i've been wondering for a bit… why does !important mean "don't override" instead of "not important"
[13:30:24 CDT(-0500)] <colinclark>
[13:31:09 CDT(-0500)] <Justin_o> i wonder if this will solve a lot of our jiras
[13:31:19 CDT(-0500)] <Justin_o> will that "border" declaration also do "border-color" ?
[13:32:15 CDT(-0500)] <colinclark> It will likely lose in the face of a more specific declaration, Justin_o
[13:33:56 CDT(-0500)] <Justin_o> colinclark: hmm.. i tried adding that bit from the jira and now nothing works
[13:35:02 CDT(-0500)] <Bosmon> Justin_o - it was clearly designed by those who worked on the BBC Microcomputer, rather than those who worked in C
[13:35:55 CDT(-0500)] <colinclark> Justin_o: hmm
[13:36:00 CDT(-0500)] <colinclark> when you say nothing works, can you elaborate?
[13:36:27 CDT(-0500)] <Justin_o> sure.. i change the contrast, save and apply it.. and nothing changes
[13:37:11 CDT(-0500)] <Justin_o> colinclark: oops.. hold on a second.. i think i forgot to regenerate the files
[13:39:03 CDT(-0500)] <Justin_o> okay.. i did forget to regenerate them
[13:42:24 CDT(-0500)] <Bosmon> Hi there cindyli - checking in on today
[13:42:28 CDT(-0500)] <Bosmon> How is FatPanel looking today?
[13:42:45 CDT(-0500)] <cindyli> Bosmon: it's done!!!
[13:42:49 CDT(-0500)] <Bosmon> !!!
[13:42:50 CDT(-0500)] <Bosmon> Stupendous!
[13:43:24 CDT(-0500)] <cindyli> what i'm doing now is trying to get rid of the demands block in FullPreview.js and FullNoPreview.js
[13:43:44 CDT(-0500)] <cindyli> Bosmon: if succeding, will extend to fat panel
[13:43:49 CDT(-0500)] <cindyli> what do u think?
[13:44:27 CDT(-0500)] <Bosmon> cindyli - that will be excellent
[13:44:33 CDT(-0500)] <cindyli> cool
[13:47:28 CDT(-0500)] <Bosmon> Which ones in particular were you thinking of getting rid of?
[13:47:42 CDT(-0500)] <cindyli> at the top of fullNoPreview.js
[13:48:07 CDT(-0500)] <cindyli> there are 2 demands block, one for templateLoader, the other for uiOptions
[13:48:15 CDT(-0500)] <cindyli> that's the ones i'm working on
[13:48:38 CDT(-0500)] <cindyli> i plan to move them into defaults block of "fluid.uiOptions.fullNoPreviewUIOptions"
[13:49:51 CDT(-0500)] <cindyli> the thought is to have one more option in defaults, say "fullNoPreviewOptions", in finalInit, i fetch this using fluid.defaults, merged with sent-in argument "options", then pass into fluid.uiOptions.mapOptions() for conversion
[13:49:55 CDT(-0500)] <Bosmon> templateLoader one should certainly die, yes
[13:50:10 CDT(-0500)] <Bosmon> cindyli - can you explain more?
[13:50:24 CDT(-0500)] <cindyli> mistake, not in finalInit
[13:50:36 CDT(-0500)] <cindyli> since it's no longer an autoInit component
[13:51:05 CDT(-0500)] <cindyli> i meant in instantiation function of fluid.uiOptions.fullNoPreviewUIOptions(container, options)
[13:51:13 CDT(-0500)] <Bosmon> What would this type-specific argument do?
[13:51:16 CDT(-0500)] <Bosmon> When it reached mapOptions()?
[13:51:27 CDT(-0500)] <Justin_o> michelled, colinclark: so i guess i'll add in the missing properties that get !importants, did you want me to do that all in my pull-request for fixing the border colours, or did you want that as part of FLUID-4219
[13:51:57 CDT(-0500)] <cindyli> Bosmon: to manually retrieved the extra options defined in fluid.defaults("fluid.uiOptions.fullNoPreviewUIOptions")
[13:52:06 CDT(-0500)] <cindyli> *retrieve
[13:52:28 CDT(-0500)] <Bosmon> But surely... you are already retrieving them
[13:52:38 CDT(-0500)] <Bosmon> Since you are fetching the defaults for the correct component?
[13:52:45 CDT(-0500)] <Bosmon> What extra work could the type name do?
[13:53:47 CDT(-0500)] <michelled> it's up to you Justin_o
[13:54:11 CDT(-0500)] <Justin_o> michelled: okay.. thanks
[13:54:15 CDT(-0500)] <cindyli> one sec, Bosmon, i'm pastie
[13:54:20 CDT(-0500)] <Bosmon> Thanks
[13:56:22 CDT(-0500)] <cindyli> Bosmon: http://pastie.org/2291274
[13:56:54 CDT(-0500)] <cindyli> the upper part is w/o the type name, to retrieve defaults on uiOptions and templateLoader, i need 2 lines,
[13:57:31 CDT(-0500)] <cindyli> uiOptionsOption = fluid.defaults("fluid.uiOptions.fullNoPreviewUIOptions").uiOptions;
[13:57:31 CDT(-0500)] <cindyli> templateLoaderOption = fluid.defaults("fluid.uiOptions.fullNoPreviewUIOptions").templateLoader;
[13:57:48 CDT(-0500)] <cindyli> with the bottom part with type name,
[13:58:09 CDT(-0500)] <cindyli> defaultsOption = fluid.defaults("fluid.uiOptions.fullNoPreviewUIOptions").fullNoPreviewOptions;
[13:59:02 CDT(-0500)] <Bosmon> Hmm
[13:59:05 CDT(-0500)] <Bosmon> This is all a bit strange
[13:59:10 CDT(-0500)] <cindyli> aha
[13:59:31 CDT(-0500)] <Bosmon> Surely you should be customising the options to mapOptions, rather than juggling within the defaults in this way
[13:59:42 CDT(-0500)] <cindyli> exactly
[13:59:45 CDT(-0500)] <Bosmon> That is, the difference between the components is a difference in their "transformation record"
[13:59:57 CDT(-0500)] <Bosmon> The thing which I guess is still called "uiOptionsTransform" or something like that
[14:00:06 CDT(-0500)] <Bosmon> A *CATT* is drinking his **CATT WATTTER"
[14:01:14 CDT(-0500)] <cindyli> that's totally ordinary
[14:01:25 CDT(-0500)] <cindyli> u don't expect a cat not drinking his water
[14:01:33 CDT(-0500)] <Bosmon> If you dig out my mail about this on Monday or so, you can see a suggested solution, involving having mapOptions recognizing special kinds of RH argument
[14:01:38 CDT(-0500)] <Bosmon> Clearly if the RH argument is an object, you know what to do
[14:01:39 CDT(-0500)] <cindyli> i saw it
[14:01:45 CDT(-0500)] <cindyli> ya, u remind me
[14:01:57 CDT(-0500)] <Bosmon> The only other case you need to distinguish is whether the RH value if it is a string, represents a path or not
[14:03:12 CDT(-0500)] <Bosmon> One solution to this is to say that in ALL cases if the RH is an object, it represents a value, and the value is held at a member named "value"
[14:03:20 CDT(-0500)] <Bosmon> And that all strings represent paths
[14:03:45 CDT(-0500)] <Bosmon> Well, for a long time the CATT didn't drink his water
[14:03:54 CDT(-0500)] <Bosmon> Now he has a special CATT FFOUNTAIN he is more enthusiastic about it
[14:04:35 CDT(-0500)] <cindyli> ah, that's why. i doubt how he survived w/o water tho
[14:04:57 CDT(-0500)] <cindyli> ok, i see what u mean about the string
[14:05:43 CDT(-0500)] <colinclark> I'm going to have to hit the road momentarily. Justin_o and michelled, are you guys good?
[14:05:44 CDT(-0500)] <cindyli> it means that we turn string value into an object. so the string always represents a path
[14:06:42 CDT(-0500)] <Justin_o> colinclark: i'm alright.. i'm about to take off too
[14:06:57 CDT(-0500)] <colinclark> cool
[14:07:11 CDT(-0500)] <colinclark> Hey fluid-everyone, thanks for all your hard work this week
[14:07:14 CDT(-0500)] <colinclark> Have a really good long weekend
[14:07:27 CDT(-0500)] <cindyli> you too
[14:07:29 CDT(-0500)] <colinclark> and I look forward to freezing 1.4 with you guys next week--we're really close
[14:07:29 CDT(-0500)] <clown> you too colinclark
[14:07:38 CDT(-0500)] <heidi_> happy weekend cc
[14:13:22 CDT(-0500)] <Bosmon> I look forward to a freezing anything
[14:13:24 CDT(-0500)] <Bosmon> Have a good time
[14:27:46 CDT(-0500)] <cindyli> Bosmon: there's my thing i feel odd but haven't figured out why is - https://github.com/cindyli/infusion/blob/FLUID-4353/src/webapp/demos/uiOptions/FatPanelUIOptions/js/fatPanelUIOptions.js#L27
[14:27:58 CDT(-0500)] <cindyli> this is the template path supplied into fat panel
[14:28:19 CDT(-0500)] <cindyli> before, it was the relative path between the caller html (uiOptions.html) to where the templates are located
[14:29:10 CDT(-0500)] <cindyli> after my code change with options munging, it becomes the relative between the ifram html (fatPanelIframd.html) to directory where the templates locate
[14:29:20 CDT(-0500)] <cindyli> i never expect my code change has this effect
[14:30:02 CDT(-0500)] <cindyli> it's actually a pretty bad result, since the integrator now has to be aware of the location of fatPanelIframe.html
[14:34:04 CDT(-0500)] <Bosmon> cindyli - I guess it is because the URL is now only resolved in the "hidden world"
[14:34:14 CDT(-0500)] <Bosmon> Although it's odd to imagine it was ever resolved anywhere else
[14:34:36 CDT(-0500)] <Bosmon> Still... you know the URL offset between the two worlds, so it should be easy enough to compensate, if this really is the change....
[14:55:00 CDT(-0500)] <anastasiac> cindyli, I'm curious about the new names for the different UIOs. With the new namespacing, might we be able to shorten the names, e.g. "fluid.uiOptions.fullNoPreview" instead of "fluid.uiOptions.fullNoPreviewUIOptions" ?
[14:55:28 CDT(-0500)] <cindyli> anastasiac: we surely can
[14:55:32 CDT(-0500)] <anastasiac> I believe the shorter form is what Bosmon was suggesting in his email
[14:56:21 CDT(-0500)] <Bosmon> Ah, I thought that was what had been implemented
[14:58:06 CDT(-0500)] <care> anastasiac: I recieved your email about the gsoc docs camp, i need to review the info and my availability, i'll have to get back to you monday
[14:58:41 CDT(-0500)] <anastasiac> np, care, I'm just suggesting we think about it
[14:59:31 CDT(-0500)] <anastasiac> cindyli, will the options munging also be implemented for UIEnhancer, to make it easier to customize the settingsStore's defaultSiteSettings?
[14:59:53 CDT(-0500)] * anastasiac is worried cindyli is going to throw something at her for asking all these questions!
[15:00:06 CDT(-0500)] <cindyli> haha, that's fine
[15:00:25 CDT(-0500)] <care> anastasiac: great. Thanks for the suggestion
[15:00:37 CDT(-0500)] <cindyli> anastasiac: "defaultSiteSettings" part hasn't been implemented
[15:00:50 CDT(-0500)] <care> oh actually monday is a holiday so the office will be closed
[15:01:14 CDT(-0500)] <anastasiac> I know cindyli, - I was wondering if it was in the plans
[15:01:14 CDT(-0500)] <care> tuesday then
[15:01:23 CDT(-0500)] <Bosmon> !
[15:01:25 CDT(-0500)] <anastasiac> right, tuesday care
[15:01:26 CDT(-0500)] <Bosmon> Another holiday!
[15:01:29 CDT(-0500)] <Bosmon> What is it this time!
[15:01:38 CDT(-0500)] <anastasiac> it's a civic holiday
[15:01:43 CDT(-0500)] <anastasiac> in some provinces
[15:01:53 CDT(-0500)] <michelled> Simcoe day in Toronto
[15:02:15 CDT(-0500)] <anastasiac> http://en.wikipedia.org/wiki/Civic_Holiday
[15:02:27 CDT(-0500)] <anastasiac> interesting: "historically linked to the abolition of slavery in the British Empire in 1834"
[15:02:32 CDT(-0500)] <Bosmon> Not named after Anthony SIMCOE
[15:03:05 CDT(-0500)] <cindyli> anastasiac: i can add it into the plan
[15:03:24 CDT(-0500)] <anastasiac> no, John Graves Simcoe
[15:03:55 CDT(-0500)] <Bosmon> Ah, such a shame he didn't live long enough to participate in setting fire to the White House
[15:05:17 CDT(-0500)] <anastasiac> cindyli, if tableOfContents is a subcomponent of UIEnhancer, it would probably make sense to "munge" the TOC template resource url up to the top level somehow?
[15:05:32 CDT(-0500)] <Bosmon> anastasiac - not to worry, all this will be done
[15:05:36 CDT(-0500)] <Bosmon> ALL will be munged, in time
[15:05:36 CDT(-0500)] <anastasiac> get rid of the need for the demands block?
[15:05:44 CDT(-0500)] <anastasiac> yay! a munging party!
[15:05:59 CDT(-0500)] <Bosmon> Although soon "munging" will become the same as "chewing"
[15:06:41 CDT(-0500)] <anastasiac> hm. "chewing party" doesn't quite have the same ring to it
[15:06:45 CDT(-0500)] <cindyli> anastasiac: uienhancer toc template resource url has been munged, in my branch
[15:06:52 CDT(-0500)] <anastasiac> ah, excellent!
[15:06:55 CDT(-0500)] <anastasiac> thanks, cindyli
[15:06:59 CDT(-0500)] <cindyli> np
[15:07:39 CDT(-0500)] <Bosmon> hah... Simcoe is responsible for naming LONDON...