...
[14:10:01 CDT(-0500)] <colinclark> So, I guess to wrap up the main part of this
[14:10:09 CDT(-0500)] <colinclark> 1. Sorry to distract you all with going over this again
[14:10:14 CDT(-0500)] <colinclark> 2. It's been very informative
[14:10:30 CDT(-0500)] <colinclark> 3. We should, before shipping 1.5, provide this kind of affordance for users
[14:10:48 CDT(-0500)] <colinclark> 4. I'll send out an email to users of the preferences framework giving them a heads up that the renaming has happened
[14:11:43 CDT(-0500)] <colinclark> 5. We still need to figure out if we've got a subtle problem related to the CSS renaming
[14:11:59 CDT(-0500)] <colinclark> I think michelled is on that latter mission
[14:12:33 CDT(-0500)] <michelled> there is definitely use of uio theme names in the oercommons source
[14:12:58 CDT(-0500)] <michelled> it's actually the strategy that we recommend to make a site conform nicely when a theme is chosen
[14:13:24 CDT(-0500)] <colinclark> that's exactly what I was afraid of
[14:13:31 CDT(-0500)] <colinclark> Can you also check out they instantiate UIO?
[14:13:45 CDT(-0500)] <colinclark> does it more or less reflect our tutorial, or are they doing anything fancy?
[14:16:16 CDT(-0500)] <Justin_o> sorry about the delay.. my computer decided to lock up for a bit.. probably all the instances of sublime i'm running
[14:16:24 CDT(-0500)] <Justin_o> http://pastie.org/private/pftaoeghqsg12wn6anjqg
[14:16:25 CDT(-0500)] <colinclark> no worries 
[14:17:24 CDT(-0500)] <Justin_o> Bosmon, colinclark, anastasiac: does it look okay?
[14:18:33 CDT(-0500)] <Bosmon> Justin_o - something like that, yes - although it might be more helpful if we could get some insight into what the constructed grade name actually is in any case, and guide it to be something helpful
[14:18:40 CDT(-0500)] <anastasiac> it looks lovely
[14:18:53 CDT(-0500)] <Bosmon> I guess by default it will be something like fluid.uiOptions.constructed.something?
[14:19:07 CDT(-0500)] <anastasiac> the constructed grade name is now in the "fluid.prefs.constructed"
[14:19:14 CDT(-0500)] <anastasiac> you get "prefsEditor" and "uio"
[14:19:23 CDT(-0500)] <anastasiac> so "fluid.prefs.constructed.prefsEditor"
[14:19:36 CDT(-0500)] <anastasiac> if you override the namespace with "footer" you can then use "foofer.prefsEditor"
[14:19:53 CDT(-0500)] <anastasiac> s/footer/foofer
[14:21:04 CDT(-0500)] <Bosmon> So perhaps we could achieve fluid.uiOptions.prefsEditor?
[14:21:09 CDT(-0500)] <Bosmon> Simply through configuration to the builder?
[14:21:28 CDT(-0500)] <anastasiac> yes, easily
[14:21:33 CDT(-0500)] <Justin_o> Bosmon: yes, that would be easy
[14:22:23 CDT(-0500)] <Justin_o> Bosmon: the question would be is that what we'd want?
[14:22:46 CDT(-0500)] <Bosmon> I think it has some things in its favour
[14:22:58 CDT(-0500)] <Justin_o> i just really mean the name
[14:23:03 CDT(-0500)] <Bosmon> For example, it helps to bridge the gaps between the worlds of users #1 and #2
[14:23:06 CDT(-0500)] <Bosmon> yes
[14:23:07 CDT(-0500)] <Justin_o> i like the 1 less step
[14:23:13 CDT(-0500)] <Bosmon> It is a name that can be "naturally achieved"
[14:23:21 CDT(-0500)] <Bosmon> And so it is clearer to users how they might naturally achieve other things
[14:23:34 CDT(-0500)] <Bosmon> As well as giving them easy access to all the other grade names that are constructed in the same step
[14:24:49 CDT(-0500)] <Justin_o> fluid-everyone: are you okay with fluid.uiOptions.prefsEditor as the packaged component for the preference framework
[14:25:02 CDT(-0500)] <colinclark> yup, I'm fine with it
[14:25:12 CDT(-0500)] <colinclark> and other prefsEditors will likely mirror this approach?
[14:25:20 CDT(-0500)] <colinclark> pga.explorationTool.prefsEditor?
[14:25:26 CDT(-0500)] <colinclark> or whatever
[14:25:56 CDT(-0500)] <anastasiac> seems ok to me
[14:26:03 CDT(-0500)] <Justin_o> okay.. i'll just reopen FLUID-5161 and we can make the necessary changes
[14:26:37 CDT(-0500)] <Justin_o> cindyli: did you want to make these changes or would you like me too.. i don't mind doing it.. up to you
[14:27:49 CDT(-0500)] <cindyli> Justin_o: go ahead to make changes since you seem to be more clear about all these
[14:28:41 CDT(-0500)] <Justin_o> cindyli: okay
[14:29:51 CDT(-0500)] <cindyli> thanks, Justin_o
[14:41:17 CDT(-0500)] <michelled> colinclark: in terms of your earlier question, oercommons is mostly following the tutorial. There is one listener being added programatically in the green site, but it should be a simple fix
[14:41:28 CDT(-0500)] <colinclark> ok
[14:41:31 CDT(-0500)] <colinclark> well, there you go
[14:41:39 CDT(-0500)] <colinclark> so the CSS issue isn't a trivial one
[14:41:50 CDT(-0500)] <colinclark> Have the stylesheets changed much amidst all this refactoring, Justin_o?
[14:41:54 CDT(-0500)] <michelled> nope, it's not
[14:41:59 CDT(-0500)] <colinclark> aside from the names
[14:46:26 CDT(-0500)] <colinclark> michelled: do you think it would be crazy to ship two copies of the UIO stylesheets?
[14:46:42 CDT(-0500)] <colinclark> Or doubled definitions of everything, half of them marked deprecated?
[14:52:01 CDT(-0500)] <michelled> I'd rather see two copies of the stylesheets instead of double definitions
[14:52:25 CDT(-0500)] <michelled> I imagine we could modify the css generation code to generate the two copies
[14:52:49 CDT(-0500)] <michelled> or maybe we should make another build target?
[14:53:20 CDT(-0500)] <colinclark> Either one would be fine
[14:53:55 CDT(-0500)] <colinclark> Despite my typically aggressive "I want to break backwards compatibility" stance these days, I think we should plan for something before we cut 1.5
[14:54:16 CDT(-0500)] <colinclark> I worry that the "accessibility is too hard" set will just see this as further fuel for the fire