fluid-work IRC Logs-2011-06-15

[08:43:24 CDT(-0500)] <huslage> mornin
[09:06:45 CDT(-0500)] <heidi> Justin_o jacob did do the fl-layout-linear * thing
[09:07:41 CDT(-0500)] <heidi> he sets the width: 100% differently tho
[09:07:57 CDT(-0500)] <heidi> so maybe for things we don't want to linearize, like the slider, we can use absolute as the over-ride...
[09:15:30 CDT(-0500)] <heidi> Justin_o_ jacob's fl-linear also messes up slider
[09:34:37 CDT(-0500)] <anastasiac> jhung1 and jameswy, do you have a minute for a docs design/interaction question?
[09:34:53 CDT(-0500)] <jameswy> anastasiac: Sure, what's up?
[09:34:58 CDT(-0500)] <jhung1> anastasiac: sure
[09:35:09 CDT(-0500)] <anastasiac> I'm looking at the designs for the new docs space, in particular the sidebar: http://wiki.fluidproject.org/display/fluid/Infusion+documentation+redesign+%28April+2011%29#Infusiondocumentationredesign%28April2011%29-API
[09:35:28 CDT(-0500)] <anastasiac> my first question is: are the lines that can be expanded also links to their own page?
[09:35:44 CDT(-0500)] <anastasiac> for example, in that mock-up, the "Inline Edit" line has the arrow at the end
[09:35:48 CDT(-0500)] <anastasiac> so it's expandable
[09:35:58 CDT(-0500)] <jameswy> anastasiac: Yes.
[09:36:03 CDT(-0500)] <anastasiac> but is there also an "inline edit" page I can get to by clicking the name?
[09:36:27 CDT(-0500)] <jameswy> Correct. The arrow will expand, clicking on the text will get you to an independent "inline edit" page.
[09:36:39 CDT(-0500)] <anastasiac> so where is the border between "click here to go to inline edit" and "click here to expand"?
[09:36:52 CDT(-0500)] <jameswy> It's arrow vs text.
[09:36:53 CDT(-0500)] <anastasiac> what if I click the blue space in between?
[09:37:11 CDT(-0500)] <jameswy> Must you ask difficult questions?
[09:37:18 CDT(-0500)] <jameswy> jhung: What are your thoughts on that one?
[09:37:18 CDT(-0500)] <anastasiac> that's my job
[09:37:56 CDT(-0500)] <jhung> anastasiac: "blue space in between?"
[09:38:08 CDT(-0500)] <jameswy> I'm thinking it just expands (i.e., only way to get to the page is if you click on the text)
[09:38:09 CDT(-0500)] <jhung> you mean the empty space?
[09:38:17 CDT(-0500)] <anastasiac> yes the empty space
[09:38:31 CDT(-0500)] <jhung> I think it should expand, unless it's the text specifically clicked on.
[09:38:44 CDT(-0500)] <jhung> yes what Jameswy said.
[09:38:48 CDT(-0500)] <anastasiac> ok, cool - thanks for the clarification, guys
[09:43:59 CDT(-0500)] <jhung> heidi: I'm going to work on the icons.
[09:45:04 CDT(-0500)] <jhung> heidi: Do you think it's okay if we create a new directory /images/default so it matches the themes?
[09:47:00 CDT(-0500)] <heidi> jhung i think that makes sense.... if that helps organise stuff. are there any images in /images that aren't default?
[09:47:40 CDT(-0500)] <jhung> heidi: maybe select_arrow? That's not really theme specific, right?
[09:48:09 CDT(-0500)] <heidi> jhung what's that one used for?
[09:48:37 CDT(-0500)] <jhung> heidi: I honestly don't know. I didn't come across it during my edits. Hoping you'd know.
[09:48:46 CDT(-0500)] <jhung> heidi: I'll check the css now...
[09:48:50 CDT(-0500)] <heidi> k
[09:49:00 CDT(-0500)] <heidi> if it's not used it can go
[09:50:20 CDT(-0500)] <jhung> heidi: Searched all CSS files, didn't find it.
[09:50:26 CDT(-0500)] <jhung> heidi: I'll delete it.
[09:50:30 CDT(-0500)] <heidi> k
[10:17:56 CDT(-0500)] <jhung> jameswy, Re: uio slider knob. Do you want the Circle design or the 3 vericle lines design for the knob?
[10:30:15 CDT(-0500)] <jessm> fluid-everyone i can't see to fire up connect.ocad.ca/fluid-work
[10:30:35 CDT(-0500)] <anastasiac> jessm, same here
[10:30:46 CDT(-0500)] <jameswy> ditto.
[10:31:07 CDT(-0500)] <anastasiac> I suppose we could try york's again?
[10:31:14 CDT(-0500)] <anastasiac> does anyone remember the URL
[10:31:28 CDT(-0500)] <anastasiac> http://connect.yorku.ca/fluidwork
[10:31:38 CDT(-0500)] <anastasiac> jameswy, jessm, will we try that?
[10:31:53 CDT(-0500)] <jessm> anastasiac: trying
[10:32:02 CDT(-0500)] <Bosmon4> That doesn't seem to work for me either
[10:32:04 CDT(-0500)] <jhung> nope.
[10:32:09 CDT(-0500)] <Bosmon4> Poo
[10:32:10 CDT(-0500)] <jhung> Same here.
[10:32:12 CDT(-0500)] <jessm> bah!
[10:32:15 CDT(-0500)] <Bosmon4>
[10:32:23 CDT(-0500)] <jessm> the intertubes are clogged
[10:32:35 CDT(-0500)] <Bosmon4> Ah
[10:32:37 CDT(-0500)] <anastasiac> not here, either
[10:32:40 CDT(-0500)] <jhung> I got York loaded.
[10:32:41 CDT(-0500)] <Bosmon4> I got a login page from yorku now
[10:32:49 CDT(-0500)] <Bosmon4> Perhaps it was sleeping
[10:32:52 CDT(-0500)] <Bosmon4> Through months of disuse
[10:33:01 CDT(-0500)] <colinclark> I'm in a GPII standards meeting this morning, so will miss standup today
[10:33:08 CDT(-0500)] <Bosmon4> Or perhaps it was on a journey
[10:33:08 CDT(-0500)] <jameswy> fluid-everyone: http://breeze.yorku.ca/fluidwork just worked for me. Took a really long time.
[10:33:12 CDT(-0500)] <colinclark> Hoping to run some code by Bosmon4 today
[10:33:27 CDT(-0500)] <jessm> fluid-everyone york it is
[10:33:27 CDT(-0500)] <Bosmon4> colinclark - I won't be around for much longer - could you mail it?
[10:33:31 CDT(-0500)] <jessm> just like old times
[10:33:33 CDT(-0500)] <Bosmon4> What kind of code is it?
[10:33:59 CDT(-0500)] <colinclark> It's the refactored error messages for the Uploader, Bosmon4
[10:34:08 CDT(-0500)] <colinclark> I think you'll appreciate it
[10:34:17 CDT(-0500)] <colinclark> just want a quick sanity check
[10:34:39 CDT(-0500)] <jameswy> And http://breeze.yorku.ca/fluidwork isn't working for me either.
[10:35:20 CDT(-0500)] <Bosmon4> Sounds awesome, colinclark
[10:35:30 CDT(-0500)] <Bosmon4> Do you mean messages or progress bars?
[10:35:49 CDT(-0500)] <colinclark> error messages
[10:35:51 CDT(-0500)] <Bosmon4> I thought the messages stuff had been looking good... but perhaps I mixed it up with the reworked "image gallery thing"
[10:35:57 CDT(-0500)] <colinclark> this is for the real uploader
[10:39:25 CDT(-0500)] <Bosmon4> Great
[10:41:32 CDT(-0500)] <colinclark> Bosmon4: I still owe you a test case for my problems with referring to items within a parent's DOM Binder
[10:41:34 CDT(-0500)] <colinclark> will work on that today
[10:42:34 CDT(-0500)] <colinclark> So, Bosmon4: The original implementation for the new error messages view in the Uploader was this: https://github.com/mlam/infusion/blob/FLUID-3878/src/webapp/components/uploader/js/Uploader.js#L739-915
[10:43:08 CDT(-0500)] <colinclark> I'll paste a link to the newly refactored implementation in a sec
[10:43:40 CDT(-0500)] <jessm> eek, just updated huslage on the "fluid-everyone" being a hot phrase for IRC to get "everyone"
[10:43:44 CDT(-0500)] <Bosmon4> That's cool, colinclark
[10:43:50 CDT(-0500)] <colinclark> Bosmon4: https://github.com/colinbdclark/infusion/blob/FLUID-3878/src/webapp/components/uploader/js/ErrorsView.js
[10:43:51 CDT(-0500)] <Bosmon4> Also, what do you think about FLUID-4285?
[10:43:53 CDT(-0500)] <huslage> fixed. thanks jessm
[10:43:56 CDT(-0500)] <colinclark> Can you have a look?
[10:44:04 CDT(-0500)] <Bosmon4> ok, will do
[10:44:08 CDT(-0500)] <colinclark> Bosmon4: I'll look today
[10:44:10 CDT(-0500)] <colinclark> sorry for the delay
[10:44:25 CDT(-0500)] <Bosmon4> Not to worry, the release is put back quite a bit after all
[10:45:09 CDT(-0500)] <colinclark> Bosmon4: Here are the wireframes for the error messages, for reference: http://wiki.fluidproject.org/display/fluid/Uploader+Wireframes+%28Error+Handling%29
[10:45:46 CDT(-0500)] <Bosmon4> Lines 74-79 are classic "go away in the next release" code
[10:46:00 CDT(-0500)] <Bosmon4> I was very happy to see that the first actual code I saw in the file was code that we planned to destroy
[10:46:14 CDT(-0500)] <colinclark>
[10:46:16 CDT(-0500)] <Bosmon4> 74-84 I mean
[10:46:21 CDT(-0500)] <Bosmon4> CSpace is full of stuff like this too
[10:47:52 CDT(-0500)] <Justin_o> Bosmon4: hello, did you say you'd have a chance to look over the stuff mlam and I have been working on, now or later?
[10:48:09 CDT(-0500)] <Bosmon4> colinclark - why does the loop at line 203 omit the last file?
[10:48:15 CDT(-0500)] <Bosmon4> Justin_o pretty much now would be good
[10:48:25 CDT(-0500)] <Bosmon4> Ah, I see it now
[10:48:33 CDT(-0500)] <colinclark> Bosmon4: The loop is appending a delimiter to the end of each file
[10:48:34 CDT(-0500)] <Bosmon4> Perhaps a use of .join() would be better here?
[10:48:38 CDT(-0500)] <colinclark> ah, much
[10:48:40 CDT(-0500)] <colinclark>
[10:49:04 CDT(-0500)] <Bosmon4> JavaScript does supply the occasional amenity
[10:49:05 CDT(-0500)] <colinclark> much much
[10:49:07 CDT(-0500)] <colinclark>
[10:49:30 CDT(-0500)] <Bosmon4> The code looks generally awesome
[10:50:07 CDT(-0500)] <Justin_o> Bosmon4: i'll try to make sure our latest stuff is pushed up... one second
[10:50:15 CDT(-0500)] <Bosmon4> Thanks, Justin_o
[10:51:21 CDT(-0500)] <cindyli> Bosmon4: while Justin_o is pushing up his thing, i have a question about the prefix issue. http://pastie.org/2072875 is the old one and the new one i'm planning
[10:52:06 CDT(-0500)] <cindyli> Bosmon4: u will notice that i move the template for uiOptions, the main template with 3 placeholder for control templates, out of the "templates" option
[10:52:45 CDT(-0500)] <colinclark> thanks, Bosmon4
[10:53:00 CDT(-0500)] <cindyli> Bosmon4: because this main template has various name depending on the view of the ui options that the implementor chooses
[10:53:48 CDT(-0500)] <cindyli> for example, it has to be "fatPanel..html" for fat panel, and "fullpreview.." for full page with preview, etc
[10:53:59 CDT(-0500)] <Bosmon4> colinclark - I thought about your "sections" a bit at lines 30-60 but I think that the solution you have there is generally ok
[10:54:07 CDT(-0500)] <cindyli> Bosmon4, do u think this change is ok, or other thoughts?
[10:54:16 CDT(-0500)] <Bosmon4> The configuration could be "condensed" a bit but only at the cost of reducing the scope for polymorphism
[10:54:38 CDT(-0500)] <Bosmon4> Ok, cindyli, I look at your pastie now
[10:54:45 CDT(-0500)] <cindyli> thanks
[10:54:59 CDT(-0500)] <Bosmon4> cindyli - I was expecting a placeholder to appear for the prefix in the configuration
[10:55:20 CDT(-0500)] <Bosmon4> Otherwise the user can't make it clear whether they want to employ the prefix or not
[10:56:10 CDT(-0500)] <Bosmon4> For example, "%prefix../html/UIOptionsTemplate-text.html"
[10:56:22 CDT(-0500)] <mlam> colinclark: the new error handler is great stuff!
[10:56:26 CDT(-0500)] <cindyli> Bosmon4: yes, exactly
[10:57:15 CDT(-0500)] <Bosmon4> cindyli - I assume this will come with a demands block which will ferry the user's top-level "prefix" option applied to the overall UIOptions into your uiOptionsTemplate parameter
[10:57:27 CDT(-0500)] <Bosmon4> ero, controlTemplatesPrefix
[10:58:24 CDT(-0500)] <Bosmon4> cindyli - why did you make the uiOptionsTemplate not subject to the template prefix (I assume)?
[10:58:36 CDT(-0500)] <Bosmon4> Isn't it likely that in the default case, they will all be loaded from the same directory?
[10:59:07 CDT(-0500)] <Bosmon4> The parameter "controlTemplatesPrefix" makes it sound like this prefix might only apply to the templates inside "controlTemplates"
[10:59:22 CDT(-0500)] <Bosmon4> But without writing the placeholder into the URLs, it is not clear in any case
[10:59:49 CDT(-0500)] <cindyli> yes, that's what i meant, vecause the name of the html filefor "uiOptionsTemplate" varies all the time
[11:00:17 CDT(-0500)] <cindyli> yes, the placeholder will be like: http://pastie.org/2072930
[11:00:29 CDT(-0500)] <Bosmon4> cindyli - the name varies, but surely the directory generally doesn't?
[11:00:59 CDT(-0500)] <Bosmon4> I don't think that "controlTemplatesPrefix" is a good name for this parameter
[11:01:45 CDT(-0500)] <Bosmon4> Also, watch out! You have written a "/" after the prefix name which may cause problems
[11:01:50 CDT(-0500)] <Bosmon4> What if the user supplies the empty string?
[11:02:11 CDT(-0500)] <Justin_o> Bosmon4: I just pushed up the latest to my github branch. If you checked out my FLUID-3761 branch before, please remove it and re-add it, as I've created a new one and moved the previous stuff to FLUID-3761-old
[11:02:13 CDT(-0500)] <cindyli> right, i thought about that, the empty == "./"
[11:03:05 CDT(-0500)] <Bosmon4> ok - there might need to be custom logic to implement that
[11:04:08 CDT(-0500)] <cindyli> Bosmon4, the directory stays same, the resouces block needs to provide a default template name, we have 3 templates for the main template, i cannot just pick one of them as default, can i?
[11:04:43 CDT(-0500)] <Bosmon4> cindyli - I don't quite understand - why does that mean that the prefix doesn't apply to the main template name?
[11:05:14 CDT(-0500)] <cindyli> Bosmon4, if the implementor decides to use another view, they have to use "templates" option again by providing all the main and controls templates
[11:05:31 CDT(-0500)] <cindyli> so, what i'm thinking is that the implementor has to pick a view and provide a main template anyway
[11:06:24 CDT(-0500)] <Bosmon4> cindyli - why do they need to respecify all the controls templates if they choose anothe view?
[11:07:18 CDT(-0500)] <cindyli> Bosmon4: if only one of the options, "prefix" or "templates", will be in action
[11:07:34 CDT(-0500)] <cindyli> that is, if "prefix" is provided, ignore "templates"
[11:07:40 CDT(-0500)] <Bosmon4> cindyli - I thought we agreed yesterday that "prefix" would ALWAYS be in action?
[11:07:45 CDT(-0500)] <Bosmon4> You seemed to like that idea then
[11:07:53 CDT(-0500)] <Bosmon4> And that it seemed simpler
[11:08:38 CDT(-0500)] <cindyli> how "prefix" collaborates with "templates" then?
[11:08:53 CDT(-0500)] <Bosmon4> The templates either contain a placeholder reference to the prefix, or they don't
[11:09:08 CDT(-0500)] <Bosmon4> The user controls whether the prefix is required by either including the placeholder, or omitting it
[11:09:51 CDT(-0500)] <cindyli> ah, now i think i understand what u meant
[11:10:41 CDT(-0500)] <cindyli> i thought prefix placeholder is in the "resources" option of each component, instead of in the "templates" option of the templateLoader
[11:11:54 CDT(-0500)] <cindyli> great. now i'm in action. thanks, Bosmon4
[11:12:11 CDT(-0500)] <Bosmon4> Cheers, cindyli
[11:12:28 CDT(-0500)] <cindyli> cheers!
[11:12:29 CDT(-0500)] <Bosmon4> Ok, now to Justin_o ... the 3rd musketeer
[11:12:43 CDT(-0500)] <Justin_o> Bosmon4:
[11:12:59 CDT(-0500)] <Bosmon4> So Justin_o - did you get past the original problem of your "createOnEvent" components not starting up at all?
[11:13:02 CDT(-0500)] <Bosmon4> What was the issue there?
[11:13:08 CDT(-0500)] <Bosmon4> And what is your current stumbling block
[11:13:34 CDT(-0500)] <Justin_o> Bosmon4: so that was a problem with the demands blocks.. there was a demands block in the demo that was overriding it.. so we moved that bit into the defaults
[11:14:20 CDT(-0500)] <Justin_o> Bosmon4: the new issue that mlam and I are having is that there is an IoC issue about having the wrong instantiator or something..
[11:14:40 CDT(-0500)] <Justin_o> it seems to be caused by the createOnEvent option
[11:15:03 CDT(-0500)] <Justin_o> Bosmon4: here's the error
[11:15:04 CDT(-0500)]

[11:15:43 CDT(-0500)] <Bosmon4> Hmm
[11:15:48 CDT(-0500)] <Bosmon4> Somehow my git fetch command failed
[11:15:53 CDT(-0500)] <Bosmon4> I thought I had understood why this stuff worked
[11:15:54 CDT(-0500)] <Justin_o> really
[11:15:55 CDT(-0500)] <Bosmon4> er how
[11:16:00 CDT(-0500)] <Justin_o> what did you do?
[11:16:05 CDT(-0500)] <Bosmon4> bash-4.1$ git fetch jobara FLUID-3761:jobara/FLUID-3761
[11:16:05 CDT(-0500)] <Bosmon4> fatal: Refusing to fetch into current branch refs/heads/jobara/FLUID-3761 of non-bare repository
[11:16:09 CDT(-0500)] <Bosmon4> What is wrong with typing this?
[11:16:42 CDT(-0500)] <Justin_o> Bosmon4: hmm.. didn't know you could do that
[11:16:45 CDT(-0500)] <Bosmon4> !
[11:16:48 CDT(-0500)] <Justin_o> i think you have to fetch the entire repo
[11:16:49 CDT(-0500)] <Bosmon4> What else could I do
[11:16:54 CDT(-0500)] <Bosmon4> Surely not
[11:16:55 CDT(-0500)] <Justin_o> git fetch jobara
[11:17:01 CDT(-0500)] <Bosmon4> That is how I fetched it in the first place
[11:17:09 CDT(-0500)] <Bosmon4> Perhaps I always misunderstood what I was doing
[11:17:09 CDT(-0500)] <Justin_o> git checkout FLUID-3761
[11:17:28 CDT(-0500)] <Justin_o> Bosmon4: do you have a FLUID-3761 branch still?
[11:17:48 CDT(-0500)] <Bosmon4> Well, I ran this command yesterday
[11:17:54 CDT(-0500)] <Bosmon4> To get the branch in the first place
[11:18:08 CDT(-0500)] <Justin_o> Bosmon4: i completely changed that branch... so that could be the problem..
[11:18:10 CDT(-0500)] <Bosmon4> It was ok then, but apparently it is not ok to do it again
[11:18:13 CDT(-0500)] <Justin_o> try deleting it first
[11:18:14 CDT(-0500)] <Bosmon4> Justin_o ah, I see, ok
[11:18:25 CDT(-0500)] <Bosmon4> You surreptitious branch-changer, you
[11:18:29 CDT(-0500)] <colinclark> Justin_o with his tricky source code revisionism
[11:18:34 CDT(-0500)] <Bosmon4> Yes!
[11:18:37 CDT(-0500)] <Bosmon4> He is a REVISIONIST!!
[11:19:00 CDT(-0500)] <Justin_o> colinclark, Bosmon4: I'm just trying to control history, that's all
[11:19:12 CDT(-0500)] <Bosmon4> DOWN THE MEMORY HOLE!
[11:19:54 CDT(-0500)] <Bosmon4> Ok, I deleted the branch and that command worked a 2nd time
[11:20:18 CDT(-0500)] <Bosmon4> Also the fetch seems to be idempotent, so this looks like one of those rare cases where git gives a misleading error message
[11:20:44 CDT(-0500)] <Bosmon4> I guess it is barely possible to understand "refusing to fetch INTO current branch" as somewhat leading to the correct explanation
[11:20:58 CDT(-0500)] <Bosmon4> Unlike the instantiator error message you are getting
[11:21:02 CDT(-0500)] <Justin_o> Bosmon4: yes.. i guess it didn't like that they were so differnt
[11:21:07 CDT(-0500)] <Justin_o> different
[11:21:11 CDT(-0500)] <Justin_o>
[11:21:21 CDT(-0500)] <harriswong> Justin_o: I think the ToC tests are ready if you have some time to take a look at it
[11:21:43 CDT(-0500)] <Justin_o> harriswong: sure.. probably a bit later today.. i guess after soccer
[11:22:04 CDT(-0500)] <harriswong> Justin_o: sure.
[11:22:38 CDT(-0500)] <Justin_o> harriswong: did you want to also take a look at some refactoring.. for example changing the name of the levels subcomponent to something more descriptive of what it actually does
[11:22:51 CDT(-0500)] <Justin_o> i think it should be safer to do those changes now that you have the tests in place
[11:23:00 CDT(-0500)] <Bosmon4> Justin_o - will the current state of your branch fail?
[11:23:06 CDT(-0500)] <Justin_o> Bosmon4: yes
[11:23:15 CDT(-0500)] <Justin_o> it should throw an error on instantiation
[11:23:21 CDT(-0500)] <Bosmon4> I don't actually see the "createOnEvent" annotation sitting on the markupRenderer right now
[11:23:44 CDT(-0500)] <Justin_o> Bosmon4: hmm
[11:24:06 CDT(-0500)] <Justin_o> Bosmon4: it's on eventBinder and uiOptionsBridge
[11:24:13 CDT(-0500)] <harriswong> Justin_o: you mean TableOfCOntents.js?
[11:24:19 CDT(-0500)] <Justin_o> harriswong: yes
[11:24:21 CDT(-0500)] <Bosmon4> Justin_o - but the error seems to be thrown when instantiating the markupRenderer
[11:24:31 CDT(-0500)] <Bosmon4> Do you say that removing it on the other two components makes the error go away?
[11:24:40 CDT(-0500)] <Justin_o> Bosmon4: i believe so
[11:24:47 CDT(-0500)] <harriswong> Justin_o: sure
[11:24:50 CDT(-0500)] <Justin_o> but i could have just messed up the event injection stuff
[11:25:45 CDT(-0500)] <Bosmon4> Justin_o - which file do I open to test this?
[11:26:03 CDT(-0500)] <mlam> Bosmon4 the uiOptions.html page in the demo director
[11:26:04 CDT(-0500)] <mlam> y
[11:26:50 CDT(-0500)] <mlam> in the fatPanelUIOPtions directory
[11:29:20 CDT(-0500)] <Bosmon4> colinclark - I thikn some messages are not getting through somehow in ICQ
[11:29:27 CDT(-0500)] <Bosmon4> I saw you just fall off it too
[11:29:32 CDT(-0500)] <Bosmon4> Thanks mlam, I can see the failure now
[11:29:46 CDT(-0500)] <colinclark> Hey Bosmon4, I missed the chance to chat with you yesterday afternoon. Do you want to try to catch up sometime today?
[11:31:49 CDT(-0500)] <Justin_o> colinclark: are you trying to steal Bosmon4 from mlam and I
[11:32:10 CDT(-0500)] <colinclark> lol
[11:32:27 CDT(-0500)] <colinclark> Justin_o, mlam: He's all yours today, dudes
[11:32:32 CDT(-0500)] <mlam>
[11:32:37 CDT(-0500)] <colinclark> I just need to whip up that test case showing a potential bug in IoC
[11:32:44 CDT(-0500)] <Justin_o> colinclark: so we can frog Bosmon4 ?
[11:33:03 CDT(-0500)] <colinclark> As much as Bosmon4 is amenable to frogging in general, yes
[11:33:04 CDT(-0500)] <Justin_o> colinclark: ohh.. anything to do with createOnEvent by any chance?
[11:33:09 CDT(-0500)] <colinclark> Justin_o: hmmm
[11:33:26 CDT(-0500)] <colinclark> Only in the sense that createOnEvent provides a working workaround, I believe
[11:33:33 CDT(-0500)] <colinclark> No, this is the case I've now encountered twice
[11:33:40 CDT(-0500)] <colinclark> yet am perplexed by the fact that it works elsewhere
[11:33:57 CDT(-0500)] <Justin_o> colinclark: oh strange.. but i guess it's not related to our issue then eh?
[11:34:00 CDT(-0500)] <colinclark> where I request an element from a parent component's DOM Binder via IoC as the container to a child component
[11:34:04 CDT(-0500)] <colinclark> and it fails
[11:34:04 CDT(-0500)] <Bosmon4> aha yes
[11:34:11 CDT(-0500)] <colinclark> with the now-famous "that is null" error
[11:34:12 CDT(-0500)] <colinclark> famous to me
[11:34:14 CDT(-0500)] <Bosmon4> Well, I was just coming to this idea myself
[11:34:21 CDT(-0500)] <Bosmon4> This does appear to be some kind of framework bug
[11:34:35 CDT(-0500)] <colinclark> Bosmon4: Justin_o and mlam's issue, you mean?
[11:34:44 CDT(-0500)] <mlam> ^^ was just about to ask the same
[11:34:45 CDT(-0500)] <Bosmon4> Related to the fact that in some cases (?all?), that components constructed with "createOnEvent" seem to be constructing with the "wrong" instantiator
[11:35:00 CDT(-0500)] <Bosmon4> But for the life of me I can't guess yet where this instantiator with id 11 actually comes from
[11:35:21 CDT(-0500)] <Justin_o> Bosmon4: okay.. we had the same reaction
[11:35:39 CDT(-0500)] <Bosmon4> The one with id 13 is the genuine one
[11:35:44 CDT(-0500)] <Bosmon4> Which has all the constructed stuff in it
[11:36:16 CDT(-0500)] <Bosmon4> I continue to be SO glad that we put in deterministic ids for every component
[11:36:25 CDT(-0500)] <Bosmon4> Since this code is otherwise quite difficult to debug
[11:36:33 CDT(-0500)] <Bosmon4> Especially with the extra "stack noise" cause by fluid.tryCatch.....
[11:37:28 CDT(-0500)] <Bosmon4> Oh carp
[11:39:01 CDT(-0500)] <Bosmon4> carp carp carp
[11:39:07 CDT(-0500)] <Bosmon4> Ok, I think I can understand this bug
[11:39:24 CDT(-0500)] <Justin_o> Bosmon4: cool... i guess that's a good thing right?
[11:39:24 CDT(-0500)] <colinclark> lots of carp
[11:39:29 CDT(-0500)] <colinclark> like in lake ontario
[11:39:32 CDT(-0500)] <Justin_o> school of fish
[11:39:38 CDT(-0500)] <Bosmon4> Yes
[11:39:45 CDT(-0500)] <Bosmon4> The fix OUGHT to be quite simple too......
[11:40:28 CDT(-0500)] <colinclark> ok, i'm going to hop on my bike and visit the office
[11:40:29 CDT(-0500)] <Bosmon4> It would be massively cool if it could fix colinclark's bug too.....
[11:40:37 CDT(-0500)] <colinclark> just in time for you all to go play soccer
[11:40:38 CDT(-0500)] <Bosmon4> Were all the dodgy cases you saw to do with createOnEvent too?
[11:40:48 CDT(-0500)] <colinclark> me, Bosmon4?
[11:41:22 CDT(-0500)] <Bosmon4> Yes, you, colinclark
[11:41:35 CDT(-0500)] <colinclark> No, my situation has nothing to do with createOnEvent, unfortunately
[11:41:41 CDT(-0500)] <colinclark> I really do need to write that test case
[11:41:47 CDT(-0500)] <colinclark> which can only be done by remaining on this couch
[11:41:53 CDT(-0500)] <colinclark> instead of being on a bicycle
[11:43:10 CDT(-0500)] <Bosmon4> Ok Justin_o - I have a fix which makes the immediate problem go away
[11:43:17 CDT(-0500)] <Bosmon4> Although of course it runs into a subsequent problem
[11:43:35 CDT(-0500)] <Bosmon4> But a probably more tractable one
[11:45:06 CDT(-0500)] <Justin_o> Bosmon4: okay.. great.. so i guess we'll have to make that one a blocker then
[11:54:07 CDT(-0500)] <Bosmon4> Justin_o: http://issues.fluidproject.org/browse/FLUID-4290
[11:55:07 CDT(-0500)] <Justin_o> Bosmon4: thanks.. i've added that one to bug parade
[11:55:19 CDT(-0500)] <Bosmon4> I'll make a pull request shortly
[11:56:52 CDT(-0500)] <Justin_o> Bosmon4: great thanks
[12:12:25 CDT(-0500)] <jhung> heidi, jameswy: I pushed out changes to UIO.
[12:35:29 CDT(-0500)] <colinclark> Bosmon4: I'm pretty puzzled
[12:35:45 CDT(-0500)] <colinclark> I can't, so far, get a failing test case for this DOM Binder/IoC issue I've been seeing
[12:35:58 CDT(-0500)] <colinclark> but it's really happening
[12:36:06 CDT(-0500)] <colinclark> I guess I'll have to go hunting for typos in my configuration to start
[12:36:26 CDT(-0500)] <colinclark> anyway, I've at least added a bit of test coverage
[12:59:56 CDT(-0500)] <heidi> jhung so is fat panel "done" now /
[12:59:58 CDT(-0500)] <heidi> ?
[13:01:32 CDT(-0500)] <jhung> heidi: almost. One last issue: default font in the tab content is not the same as the themes.
[13:02:02 CDT(-0500)] <heidi> jhung not sure what you mean
[13:03:18 CDT(-0500)] <jhung> If you check out my latest changes and switch from default to any of the themes, you can see the typeface change in size. Looks like the font size is changing?
[13:04:10 CDT(-0500)] <heidi> jhung i'll grab your changes, sec
[13:05:28 CDT(-0500)] <heidi> jhung no size changes on my end
[13:06:04 CDT(-0500)] <heidi> jhung this is looking good tho!
[13:06:47 CDT(-0500)] <jhung> heidi: I think I know what it is. Borders are added to some of the input fields causing the text to shift slightly downward.
[13:07:34 CDT(-0500)] <jhung> Also, some of the icons still don't look black. Going to have to check those.
[13:09:49 CDT(-0500)] <heidi> jhung which theme in particular? ff on mac looks fine, no shifting
[13:10:07 CDT(-0500)] <heidi> jhung did you merge in my 4228 stuff? not sure if that would affect anything but worth checking
[13:10:23 CDT(-0500)] <jhung> heidi: okay. I'll merge.
[13:16:42 CDT(-0500)] <heidi> jhung did that help?
[13:17:08 CDT(-0500)] <jhung> heidi: just wrapping a change to icons. Will check it out in a sec.
[13:24:27 CDT(-0500)] <heidi> jhung looks like reset icon missing from default
[13:26:14 CDT(-0500)] <jhung> k
[13:31:26 CDT(-0500)] <jhung> heidi: hmm conflicted.
[13:31:43 CDT(-0500)] <jhung> heidi when I try to merge your 4228 branch
[13:32:26 CDT(-0500)] <jhung> heidi: ah minor conflict. Fixing it now.
[13:35:36 CDT(-0500)] <michelled_> fluid-everyone: who am I skyping into dev meeting today?
[13:35:50 CDT(-0500)] <colinclark> Me and Adele
[13:36:17 CDT(-0500)] <michelled_> Adele?
[13:36:17 CDT(-0500)] <colinclark> http://en.wikipedia.org/wiki/Adele_%28singer%29
[13:36:40 CDT(-0500)] <colinclark> One of the joys of working at home, I'm sure jessm and heidi can attest
[13:38:10 CDT(-0500)] <michelled_> Bosmon4, cindyli you joining us?
[13:38:35 CDT(-0500)] <cindyli> yes, michelled_
[13:38:58 CDT(-0500)] <michelled_> Justin_o: you coming?
[14:18:23 CDT(-0500)] <heidi> fluid-everyone the other linearize all the components issue is that the components need to use fss, which i don't think many (any?) do
[14:18:46 CDT(-0500)] <heidi> i guess they don't necessarily need to, but that should be part of the fixing
[14:36:43 CDT(-0500)] <colinclark> heidi: So Uploader is unusable with fl-linearize?
[14:36:52 CDT(-0500)] <colinclark> or rather fl-layout-linear
[14:37:04 CDT(-0500)] <heidi> yeah, can't click 'browse'
[14:37:17 CDT(-0500)] <colinclark> aha
[14:37:21 CDT(-0500)] <colinclark> yes
[14:37:26 CDT(-0500)] <colinclark> there's a floating button
[14:37:32 CDT(-0500)] <colinclark> in the case of both HTML5 and Flash
[14:37:40 CDT(-0500)] <colinclark> there's a hidden element floating on top of the browse button
[14:37:47 CDT(-0500)] <heidi> yeah i think that's where things will get tricky.. the layer-y stuff we sometimes do
[14:37:52 CDT(-0500)] <heidi> i think inline edit has some layery stuff
[14:39:07 CDT(-0500)] <heidi> inline edit still works, just the pencil is on top of the text ... but i'm actually thinking that's osmething linear shouldn't do, is strip padding eh Justin_o
[14:39:45 CDT(-0500)] <heidi> it's an issue whenever there's a bg image and padding used to make space for it
[14:40:27 CDT(-0500)] <Justin_o> heidi: i'm not sure why that was there, but i guess it's because it would cause the element to push out when linearized
[14:40:34 CDT(-0500)] <Justin_o> if it was for something other than the bg image
[14:40:44 CDT(-0500)] <heidi> Justin_o it's there so everything aligns nicely to the left etc
[14:41:08 CDT(-0500)] <Justin_o> colinclark, michelled: did one of you want to push Bosmon4's pull request. It looks like it's helped
[14:41:51 CDT(-0500)] <heidi> Justin_o but i think busting bg image space might be more of a concern than aligning nicely? padding still sort sucks in the cases where there are no bg ims
[14:42:49 CDT(-0500)] <heidi> Justin_o i thought also about ditching bg imgs totally but that's a little too much
[14:42:53 CDT(-0500)] <Justin_o> heidi: i guess it would depend on what is more common
[14:43:05 CDT(-0500)] <Justin_o> probably
[14:43:26 CDT(-0500)] <heidi> Justin_o i think it's more common to not have bg imgs. and then to have custom linearize that makes space for one if there
[14:43:46 CDT(-0500)] <Justin_o> heidi: makes sense
[14:43:49 CDT(-0500)] <heidi> k
[14:48:40 CDT(-0500)] <heidi> michelled we have styles in UIOptions.css for a vertical slider.. was that ever a thing?
[14:53:25 CDT(-0500)] <heidi> jhung did you figure out fat panel css ok?
[14:54:17 CDT(-0500)] <jhung> heidi: yes. There's only 1 issue left - could use your help on that.
[14:54:33 CDT(-0500)] <cindyli> Justin_o: i've created a jira for ui options template prefix issue and added it into the bug parade: http://issues.fluidproject.org/browse/FLUID-4291
[14:54:40 CDT(-0500)] <heidi> jhung what is it? should i update from yr branch
[14:54:58 CDT(-0500)] <jhung> heidi: yes update.
[14:55:12 CDT(-0500)] <Justin_o> cindyli: thanks.. i was just talking to heidi about that today
[14:55:16 CDT(-0500)] <jhung> heidi: the issue is input field styling being added by the contrast themes.
[14:55:53 CDT(-0500)] <cindyli> Justin_o: any conclusion?
[14:56:08 CDT(-0500)] <heidi> jhung the colour of the border around the text inputs?
[14:56:11 CDT(-0500)] <Justin_o> cindyli: no.. i was just telling her that you'd work on it
[14:56:21 CDT(-0500)] <cindyli> ah, great
[14:56:39 CDT(-0500)] <heidi> cindyli yeah i was just seeing how the implementer had to do much more now, but glad you'll be simplifying it!
[14:57:00 CDT(-0500)] <jhung> heidi: yes. it's adding background color and border color. (i.e. line 19 of fss-theme-hc.css)
[14:57:06 CDT(-0500)] <cindyli> yeah!
[14:57:21 CDT(-0500)] <heidi> jhung is that bad/
[14:57:54 CDT(-0500)] <jhung> heidi: not terrible. But it does shift the page contents slightly.
[14:58:09 CDT(-0500)] <jhung> heidi: which is why I didn't fix it.
[14:58:11 CDT(-0500)] <heidi> jhung i don't get any shifting
[14:58:18 CDT(-0500)] <jhung> yeah?
[14:58:49 CDT(-0500)] <jhung> heidi: but the border on the input fields changes though, right?
[14:59:06 CDT(-0500)] <heidi> jhung changes colour which is totally fine
[14:59:53 CDT(-0500)] <jhung> heidi: k. It's a little different on my end. But it's minor I think. We'll see if jameswy thinks it's worth fixing.
[15:00:02 CDT(-0500)] <heidi> jhung k great
[15:00:26 CDT(-0500)] <heidi> jameswy are you able to finish fat panel list today?
[15:00:57 CDT(-0500)] <heidi> jhung if you have time, can you try the different layouts on different browsers
[15:01:02 CDT(-0500)] <jameswy> heidi: Sadly no--haven't been able to touch UIO at all today. First thing tomorrow!
[15:01:11 CDT(-0500)] <heidi> jameswy sounds good thanks!
[15:04:28 CDT(-0500)] <jhung> heidi: sure. I'll take them for a spin.
[15:04:36 CDT(-0500)] <heidi> jhung thanks buddy
[15:05:53 CDT(-0500)] <jhung> heidi: at some point we'll have to do a review of the CSS. I noticed what appears to be a copy and paste of styles from the jquery contrast themes in the fatpanel.css file.
[15:06:31 CDT(-0500)] <heidi> that sounds odd. yes for sure a css review - i think there are lots of old styles we're not using, and duplicates etc
[15:06:40 CDT(-0500)] <jhung> yeah