fluid-work IRC Logs-2011-02-11
[09:02:35 CST(-0600)] <jhung> ping athena
[09:05:44 CST(-0600)] <jhung> ^forgot, it's Seattle time...
[09:09:45 CST(-0600)] <Justin_o> yura_: for 4058 did you get an alternative solution?
[09:11:14 CST(-0600)] <yura_> Justin_o: no i closed it as won't fix, i basically realized that you cant be merging arrays in options and the only safe way is to provide all defaults along with the optional elements in the array through options and make sure that the mergepolicy for the particular array option is set to replace
[09:11:33 CST(-0600)] <yura_> this was you guarantee that the elements won't get merged by the index
[09:19:24 CST(-0600)] <Justin_o> yura_: okay... will this work for you.. you seemed to not want to do that the other day... or i could have just misunderstood
[09:24:00 CST(-0600)] <michelled> good morning heidi_
[09:24:09 CST(-0600)] <heidi_> hi michelled
[09:24:25 CST(-0600)] <michelled> I'm looking at the 4037 branch and I had a question for you
[09:24:46 CST(-0600)] <heidi_> shoot
[09:24:47 CST(-0600)] <michelled> what part of the view gets updated when refresh view is called? is it the scroller?
[09:25:00 CST(-0600)] <michelled> or the region being scrolled?
[09:25:07 CST(-0600)] <heidi_> it's the fl-table-scrollable-scroller div
[09:25:33 CST(-0600)] <heidi_> the height on the scrollable region ya
[09:26:27 CST(-0600)] <michelled> ok, thanks - I'm going to change the comment a little - I think your comment is a good and worthwhile one but I'm going to move it closer to the implementation (inside the refreshView function) and add a different comment for the public API for refreshView
[09:26:58 CST(-0600)] <heidi_> michelled Justin_o do fluid folk know about this? http://weba.im/wxtk ...gov of ontario js framework for accessible web tools
[09:27:24 CST(-0600)] <michelled> I hadn't seen that heidi_
[09:27:39 CST(-0600)] <michelled> one more question heidi_ - when would you expect people to call refreshView?
[09:28:02 CST(-0600)] <heidi_> michelled the uploader would call it when files are added/deleted
[09:28:39 CST(-0600)] <heidi_> basically when the size of the scrollable region is changed
[09:29:47 CST(-0600)] <michelled> heidi_, anastasiac: what do you think of this comment? Updates the view of the scrollable region. This should be called when the content of the scrollable region is changed.
[09:29:59 CST(-0600)] <michelled> is it accurate heidi_?
[09:30:04 CST(-0600)] <michelled> is it understandable anastasiac?
[09:30:31 CST(-0600)] * anastasiac catching up
[09:30:34 CST(-0600)] <Justin_o> heidi_: is FLUID-3887 ready for review/push ?
[09:30:46 CST(-0600)] <heidi_> michelled content could change without affecting size.... maybe specify when the content changes the size of the scrollable?
[09:31:02 CST(-0600)] <heidi_> justin_o yep
[09:31:25 CST(-0600)] <michelled> well, a user might not know that and also I'm guess that the refreshView implementation details might change in the future
[09:31:37 CST(-0600)] <heidi_> michelled true x 2
[09:31:46 CST(-0600)] <michelled> I don't think it's a big overhead to call it when the content changes but I'm not sure
[09:32:11 CST(-0600)] <heidi_> michelled it's prob good practice to do that if more will be added to refreshview someday
[09:32:47 CST(-0600)] <Justin_o> heidi_: could you please mark it as "Needs Commit" on the jira and send a pull request through github
[09:32:52 CST(-0600)] <anastasiac> michelled, going only by the conversation, your suggested comment seems reasonable
[09:33:02 CST(-0600)] <michelled> cool thx
[09:33:20 CST(-0600)] <heidi_> colinclark have you seen http://weba.im/wxtk ?
[09:33:27 CST(-0600)] <heidi_> justin_o will do
[09:34:11 CST(-0600)] <michelled> heidi_: I have another question about refreshView - do we need to reset the height to "" every time we refresh the view or can we do it on component initialization?
[09:36:36 CST(-0600)] <heidi_> michelled thinking... i think it's only wise to do in refreshView. it's in there for the file-delete scenerio, where the size of the scrollable region has become smaller.
[09:39:11 CST(-0600)] <colinclark> heidi_: I hadn't seen this whole overview, but pieces of it
[09:39:23 CST(-0600)] <colinclark> Someone on this team tweeted about using Infusion for this: http://tbs-sct.ircan.gc.ca/projects/gcwwwmobile?lang=eng
[09:40:44 CST(-0600)] <heidi_> michelled the thing about refreshview is that height gets over-ridden, in order to have the size be dynamic. if someone doesn't want the size to be changing, i imagine they wouldn't call refreshview
[09:41:20 CST(-0600)] <heidi_> colinclark yeah it looks pretty cool/similar... worth looking into more maybe
[09:42:24 CST(-0600)] <heidi_> ah, the reorderers
[09:42:28 CST(-0600)] <michelled> ok, thanks heidi_ I'm going to take the maxheight calculation out of refresh view so it only happens once on component init - do you think that makes sense?
[09:45:29 CST(-0600)] <heidi_> michelled the var maxheight line? sounds good
[09:45:44 CST(-0600)] <michelled> good
[09:53:54 CST(-0600)] <jhung> bosmon: ping
[09:56:05 CST(-0600)] <heidi_> justin_o how do i do a pull request again?
[09:56:31 CST(-0600)] <heidi_> basically it's like saying 'hey origin master, include me!" right?
[09:58:04 CST(-0600)] <Justin_o> heidi_: yes.. you go to your github repo and there should be a button at the top call pull request
[10:02:57 CST(-0600)] <heidi_> thanks Justin_o
[10:17:34 CST(-0600)] <heidi_> for those following egypt, mubarak has stepped down
[10:18:54 CST(-0600)] <jessm> hey everyone – i have a Decapod call at 11:30 with JSTOR and Jan has a mtg. with Cathy Berry so we'll both miss standup – can someone let everyone know?
[10:23:41 CST(-0600)] <Justin_o> jessm: okay... i'll let them know
[10:24:47 CST(-0600)] <jessm> thanks!
[10:28:17 CST(-0600)] <michelled> heidi_: 4037 has been pushed to the infusion project repo
[10:28:31 CST(-0600)] <heidi_> thanks for the review michelled , appreciated
[10:28:32 CST(-0600)] <michelled> if you are content that the JIRA is now complete can you close it?
[10:28:39 CST(-0600)] <heidi_> will do
[10:52:22 CST(-0600)] <michelled> heidi_: is 3837 in a patch on the JIRA or on github?
[10:52:44 CST(-0600)] <heidi_> michelled github
[10:53:58 CST(-0600)] <michelled> heidi_: can you put a link to it on the JIRA?
[10:54:07 CST(-0600)] <heidi_> yep
[10:54:12 CST(-0600)] <michelled> thx
[10:55:14 CST(-0600)] <heidi_> michelled er, it is a patch. sorry getting confused. it's the FLUID-3837-j-cleanup.patch
[10:55:57 CST(-0600)] <michelled> ok, thx heidi_
[11:35:01 CST(-0600)] <heidi_> michelled i pulled from upstream into my master, but uploader looks weird. look ok on your end?
[11:35:20 CST(-0600)] <heidi_> not sure what's up .. looking into it
[11:36:19 CST(-0600)] <heidi_> i think my Uploader.css is out of sync
[11:39:10 CST(-0600)] <heidi_> Justin_o is there a http://build.fluidproject.org for git ?
[11:39:49 CST(-0600)] <Justin_o> heidi_: not yet
[11:39:57 CST(-0600)] <Justin_o> jamon and I are working on it
[11:40:00 CST(-0600)] <heidi_> cool
[11:41:32 CST(-0600)] <michelled> heidi_: only 4037 has gone in as per the order that I sent to the list
[11:41:49 CST(-0600)] <michelled> heidi_: right now I'm looking at 3837 but the patch didn't apply cleanly
[11:41:53 CST(-0600)] <michelled> I'm manually applying it
[11:41:56 CST(-0600)] <heidi_> ok
[12:11:11 CST(-0600)] <jhung1> bosmon: ping. I have a question for you about demos.
[12:13:05 CST(-0600)] <jhung1> ping athena too.
[12:13:14 CST(-0600)] * athena waves
[12:18:37 CST(-0600)] <jamon_> oh hi athena, while you're here, want to chat next week about retooling our uportal build sometime?
[12:18:57 CST(-0600)] <athena> yes, sounds great
[12:19:29 CST(-0600)] <jamon> terrific, thanks, should be fun
[12:25:20 CST(-0600)] * jhung1 waves back
[12:25:35 CST(-0600)] <jhung1> athena, do you use any of the Infusion demos online?
[12:25:41 CST(-0600)] <athena> yep
[12:25:45 CST(-0600)] <athena> frequently
[12:26:15 CST(-0600)] <jhung1> which ones and what do you use them for?
[12:36:46 CST(-0600)] <athena> sorry - in a meeting
[12:36:59 CST(-0600)] <athena> typically use the demos as a code-copying example
[12:37:17 CST(-0600)] <Bosmon> Hi jhung1
[12:37:24 CST(-0600)] <Bosmon> Yes athena - we feared people used them for this
[12:37:27 CST(-0600)] <Bosmon>
[12:37:41 CST(-0600)] <Bosmon> I have been insisting for a while that the real standard for demo code should be an "ultimate" one
[12:37:46 CST(-0600)] <athena> but of course we do
[12:37:53 CST(-0600)] <Bosmon> Rather than writing them simply to prove some didactic point
[12:37:57 CST(-0600)] <athena> well, i think it probably makes sense to have a couple levels of demos
[12:38:01 CST(-0600)] <Bosmon> Yes
[12:38:15 CST(-0600)] <athena> maybe not everyone actually wants to see all the complicated stuff we do in uportal
[12:38:18 CST(-0600)] <jhung1> athena, bosmon, I think we're heading that direction in our demos.
[12:38:18 CST(-0600)] <athena> cuz that's like, confusing
[12:38:48 CST(-0600)] <jhung1> bigger demos showing lots of options and features, and smaller demos to demonstrate a single option / function.
[12:39:07 CST(-0600)] <Bosmon> Yes, I think we concluded that there should be a couple of levels - but, all the same, whenever there was any real sample of actually working code, it should actually be written the way we intend such code to be written
[12:39:14 CST(-0600)] <Bosmon> And everything else should be just "snippets"
[12:40:26 CST(-0600)] <jhung1> so what I'm reading from athena is that you would like to see smaller examples that isn't as confusing. bosmon, I agree with that totally.
[12:41:39 CST(-0600)] <jhung1> but what I'm trying to concentrate on is the existing demo portal. I want to know what works, and what doesn't. Just so we know what should go into the next incarnation.
[12:41:54 CST(-0600)] <jhung1> So multiple levels of demos - complex ones to smaller simpler ones.
[12:42:25 CST(-0600)] <jhung1> Good well written demos if needed, otherwise code fragments should suffice (is that right bosmon?)
[12:44:00 CST(-0600)] <Bosmon> Yes, I think that's right
[12:44:08 CST(-0600)] <Bosmon> colinclark and I were looking at the jquery docs, for example
[12:44:31 CST(-0600)] <Bosmon> When they illustrate some new API or concept, often they will just have a "1 line snippet", which basically just shows how to call a particular function with correct syntax
[12:45:01 CST(-0600)] <Bosmon> Whereas if we have a demo that actually does something, I think we should make sure that it doesn't "pull any punches"
[12:45:28 CST(-0600)] <Bosmon> That is, that all parts of it are written in the way we would recommend, even if this involves the use of some framework features that are not the ones primarily being demoed
[12:45:47 CST(-0600)] <Bosmon> Since, as athena just observed, the first thing that happens with demo code is that it is used for copying
[12:45:57 CST(-0600)] <athena> but of course
[12:45:59 CST(-0600)] <athena> the demos work!
[12:46:04 CST(-0600)] <jhung1>
[12:47:11 CST(-0600)] <jhung1> bosmon: yes. I don't know if all the demos have gone through that scrutiny. We should definitely take a close look.
[12:47:26 CST(-0600)] <jhung1> we don't want people taking our bad examples.
[12:48:20 CST(-0600)] <Bosmon> I left some comments making a review of a demo of AC's last month which I think kicked off this discussion on the first place
[12:48:21 CST(-0600)] <jhung1> in that respect, it may be easier to keep smaller demos well written and up to date than the larger complex ones.
[12:48:31 CST(-0600)] <Bosmon> I can't quite remember which demo it was now
[12:48:51 CST(-0600)] <Bosmon> Oh yes
[12:48:53 CST(-0600)] <jhung1> ah, maybe the accessibility plugin demo
[12:48:54 CST(-0600)] <Bosmon> "5-star widget demo"
[12:48:56 CST(-0600)] <jhung1> yes
[12:48:59 CST(-0600)] <Bosmon> Does that ring a bell?
[12:49:01 CST(-0600)] <Bosmon> ok
[12:49:31 CST(-0600)] <Bosmon> So, for example, I observed that the demo didn't make use of the DOM binder properly, or even define a Fluid component at all
[12:50:02 CST(-0600)] <Bosmon> Which are all things that we would expect that a user of our framework "naturally would do", even if these points didn't illustrate anything relevant to the particular plugin being demoed
[12:51:53 CST(-0600)] <jhung1> true.
[12:52:32 CST(-0600)] <jhung1> I'll be sure to create a jira for this so it doesn't get lost.
[12:53:18 CST(-0600)] <Bosmon> cool - thanks, jhung1
[12:53:43 CST(-0600)] <jhung1> Anything about the demos we should improve? Anything with respect to the usability of the portal in particular? Line numbering, syntax highlighting, positioning of the demo etc.
[12:54:30 CST(-0600)] <jhung1> bosmon: I guess a question I'd like to ask you is, what do you use the demos for as a developer on Infusion?
[12:56:20 CST(-0600)] <Bosmon> me? I use them for reviewing them
[12:56:43 CST(-0600)] <Bosmon> Please send me any others you would like reviewed
[12:57:45 CST(-0600)] <jhung1> So in reviewing them, do you use the portal or you use a repository copy?
[12:59:37 CST(-0600)] <colinclark> jameswy: Here's Allen Wirfs-Brock's blog, which I just mentioned to you in person: http://www.wirfs-brock.com/allen/
[13:03:03 CST(-0600)] <Bosmon> I would probably just look at the code
[13:03:36 CST(-0600)] <jhung1> bosmon: thanks!
[13:04:06 CST(-0600)] <Bosmon> I mean, it's clearly important for our presentation that we have a nice layout of the code separate from just the junk in github
[13:04:18 CST(-0600)] <Bosmon> We have to cater to a spectrum of audiences
[13:18:28 CST(-0600)] <jhung1> yes. I'm finding the broad audience very interesting which is why the multiple levels of demos makes sense. One person's entree may be another person's appetizer.
[13:39:56 CST(-0600)] <colinclark> jhung1: A big priority for me with the demo portal is getting rid of the iFrames
[13:40:13 CST(-0600)] <colinclark> we will have to dig up our Screen Navigator code from Engage to do so
[13:40:30 CST(-0600)] <colinclark> The visual space we provide the demos is too constrained for them to look hot
[13:40:41 CST(-0600)] <colinclark> they always look squeezed or even wrap unpleasantly sometimes
[13:40:52 CST(-0600)] <colinclark> A diversity of examples of how you can configure a component will be cool to have
[13:41:00 CST(-0600)] <colinclark> rather than having to guess from the API documentation
[13:41:36 CST(-0600)] <colinclark> And a consistently high level of visual hotness would cool, too
[13:41:56 CST(-0600)] <jessm> and consistency across them wrt instructions, explanations, etc.
[13:42:01 CST(-0600)] <jessm> we have an opportunity there
[13:45:14 CST(-0600)] <jhung1> colinclark: very good points. I feel the same on those issues. Visual hotness? It's what's inside the demo that counts.
[13:45:40 CST(-0600)] <colinclark> lol
[13:49:40 CST(-0600)] <jhung1> jessm, colinclark: I'm making note of what is being mentioned.
[13:49:46 CST(-0600)] <colinclark> cool
[13:50:27 CST(-0600)] <jhung1> colinclark: I wonder what you think about the "doneness" vocabulary we're using for the demos. i.e. "Production", "Sneak Peek" etc. We don't seem to use this terminology anywhere else?
[13:51:28 CST(-0600)] <colinclark> Hmm
[13:51:55 CST(-0600)] <colinclark> I think the distinction is probably fairly important in terms of knowing what you can expect from the component over time
[13:52:23 CST(-0600)] <colinclark> We use the terms "Sneak Peek" and "Production" in various places, including in the portal, the README, and the wiki
[13:52:45 CST(-0600)] <colinclark> I don't know that we necessarily have to organize the portal based on these statuses, though
[13:53:37 CST(-0600)] <colinclark> is that what you mean, jhung1?
[13:55:00 CST(-0600)] <jhung1> colinclark: yes. Thanks for answering that. Do you think the state of a particular component is worth indicating on the Builder page or do we expect people to be informed using those other methods?
[13:55:21 CST(-0600)] <colinclark> That's a good question
[13:55:32 CST(-0600)] <colinclark> jessm and I were recently having a conversation related to this
[13:55:35 CST(-0600)] <jhung1> for example: athena thinks it would be a pretty cool thing to indicate in the builder.
[13:56:07 CST(-0600)] <colinclark> and I think the outcome of it, roughly, was that the Builder may well become a place where people go to see what's in Infusion
[13:56:21 CST(-0600)] <colinclark> so it might not be a bad thing
[13:56:48 CST(-0600)] <jhung1> yes. I just wrote a user scenario where someone just jumped to the Download page as a way of getting through the door.
[13:57:03 CST(-0600)] <colinclark> yep
[13:57:17 CST(-0600)] <colinclark> It won't be terribly long before the Download button leads directly to the Builder, I expect
[13:57:31 CST(-0600)] <colinclark> I hope that by 1.5 we'll just stop creating pre-built bundles altogether
[13:57:44 CST(-0600)] <colinclark> As soon as there is solid support for exclusions in the Builder, I think that should be doable
[13:57:55 CST(-0600)] <jhung1> cool
[13:58:20 CST(-0600)] <jhung1> so what was the outcome of the "doneness" conversation w Jess or was that it?
[13:59:42 CST(-0600)] <colinclark> I think it wasn't so much about doneness as whether we should treat the Builder as an early starting point for people learning about the Builder
[13:59:43 CST(-0600)] <colinclark> a
[13:59:52 CST(-0600)] <colinclark> and I think the general consensus was "yes," right jessm?
[14:00:47 CST(-0600)] <jhung1> I see. So more of a generalk starting point which would leads to conveying such information (somewhere and somehow).
[14:01:02 CST(-0600)] <jessm> builder as an early starting point for ppl. learning about infusion, no?
[14:01:39 CST(-0600)] <jessm> jhung1: the convo became very existential very quickly which was overwhelming, but we were interested in the implications of the builder, what we're really saying, who we're saying it to, and how effectively we do that
[14:01:45 CST(-0600)] <colinclark> lol
[14:01:49 CST(-0600)] <colinclark> "blame colinclark"
[14:01:58 CST(-0600)] <jhung1> lol
[14:01:59 CST(-0600)] <jessm> i was right there with ya dude
[14:02:11 CST(-0600)] <colinclark> you're the one with the philosophy degree, after all
[14:02:20 CST(-0600)] <jessm> i think i feel a burden in everything we do on the web to represent ourselves that we get the messaging right
[14:02:27 CST(-0600)] <jessm> ugh, liability that degree
[14:03:22 CST(-0600)] <colinclark> So, that conversation suggests, jessm, that we might want to provide the component status on the Builder page, right?
[14:03:33 CST(-0600)] <colinclark> I mean, I don't feel passionately about it
[14:03:38 CST(-0600)] <colinclark> but it sorts of leads us in that direction
[14:03:49 CST(-0600)] <jessm> status meaning prod, sneak peak, etc.?
[14:03:53 CST(-0600)] <colinclark> yep
[14:04:15 CST(-0600)] <jessm> fer shur
[14:04:16 CST(-0600)] <jessm> we must
[14:04:36 CST(-0600)] <jessm> i think we need to be consistent and redundant across our web space
[14:04:57 CST(-0600)] <colinclark> that's an interesting point
[14:05:03 CST(-0600)] <jhung1> I agree, and I think that was the point athena was making.
[14:05:10 CST(-0600)] <colinclark> repetition and reinforcement across all of the places we talk about Infusion
[14:05:42 CST(-0600)] <jessm> colinclark: what were you thinking about this?
[14:10:36 CST(-0600)] <colinclark> jessm: me?
[14:10:50 CST(-0600)] <jessm> yes
[14:10:55 CST(-0600)] <colinclark> this?
[14:11:05 CST(-0600)] * colinclark is suddenly stricken with confusion
[14:11:15 CST(-0600)] <jessm> you thought it was an interesting point
[14:11:24 CST(-0600)] <jessm> but earlier said you didn't feel passion
[14:11:31 CST(-0600)] <colinclark> Ah
[14:11:33 CST(-0600)] <jessm> i suggested we say it often and consistently
[14:11:37 CST(-0600)] <jessm> thoughts?
[14:11:40 CST(-0600)] <colinclark> I meant
[14:11:57 CST(-0600)] <colinclark> I don't feel passionately about the topic of putting component statuses on the Builder
[14:12:03 CST(-0600)] <colinclark> I think it's a good idea
[14:12:12 CST(-0600)] <colinclark> but if someone argued to keep it simple, I'd be intrigued by that, too
[14:12:42 CST(-0600)] <colinclark> I think often and consistently is a great idea
[14:12:42 CST(-0600)] <jessm> colinclark: i'm thinking if we go straight there from download it might be important
[14:12:52 CST(-0600)] <colinclark> jessm: Yeah, I buy that argument
[14:12:59 CST(-0600)] <colinclark> it makes a lot of sense
[14:13:39 CST(-0600)] <jessm> coolio
[14:14:09 CST(-0600)] <jhung1> so this brings us to a technicality, some components have subcomponents that vary in status. i.e. Inline Edit: Simple vs. Rich.
[14:14:46 CST(-0600)] <jessm> jhung1: i like to think of these things as opportunities
[14:15:18 CST(-0600)] <jhung1> jessm: indeed. It's an interesting opportunity.
[14:16:06 CST(-0600)] <colinclark> jhung1: That's an interesting point
[14:16:08 CST(-0600)] <jessm> so, these are the latest musings of a web gadfly
[14:16:16 CST(-0600)] <jessm> if i'm way off target i'll depend on someone to tell me
[14:16:43 CST(-0600)] <colinclark> it all seems sensible
[14:16:52 CST(-0600)] <colinclark> jhung1: Do we have many of those "technicality components?"
[14:17:02 CST(-0600)] <jessm> we had heard that it was hard to 1. find the demo portal and 2. find the status' of components
[14:17:10 CST(-0600)] <colinclark> I guess Rich Text and Dropdown inline edit are both sneak peek, but anything else?
[14:17:17 CST(-0600)] <jessm> i like how jameswy header addresses 1 and the status' being explicit takes care of 2
[14:17:59 CST(-0600)] <colinclark> this makes a ton of sense, jessm
[14:18:38 CST(-0600)] <jessm> oh thanks goodness
[14:19:08 CST(-0600)] <jhung1> colinclark: I don't know the components well enough to know what else has this technicality. I suspect the demo portal's listing isn't 100% complete since drop-down isn't there.
[14:20:01 CST(-0600)] <colinclark> jhung1: Ah, that's right
[14:20:05 CST(-0600)] <colinclark> dropdown is pre-sneak peek
[14:20:11 CST(-0600)] <colinclark> it's just a terrible implementation
[14:20:24 CST(-0600)] <colinclark> I was actually in the midst of trying to update it to the jQuery selectmenu last night
[14:20:33 CST(-0600)] <colinclark> which would be enough to vault it into sneak peek status
[14:20:42 CST(-0600)] <jhung1> jessm: regarding status', we'll need to make sure we're consistent and frequent with using it. I can see the API and How-To material having to indicate this frequently if it doesn't already.
[14:20:56 CST(-0600)] <michelled> colinclark: this is the book I mentioned: http://www.amazon.ca/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
[14:21:12 CST(-0600)] <jessm> jhung1: i think there are a few things emerging that will need to be reused
[14:21:23 CST(-0600)] <jessm> jhung1: can you link me and colinclark to the wiki page with the builder text again?
[14:21:26 CST(-0600)] <jhung1> jessm: and that's a good thing.
[14:21:27 CST(-0600)] <Justin_o> colinclark, Bosmon, jamon : when would be a good time to meet to talk about the daily build stuff
[14:21:40 CST(-0600)] <jessm> the text for the frameworks is what sent us into an existential tailspin
[14:21:47 CST(-0600)] <jessm> yes, jhung1 that's a very good thing
[14:21:48 CST(-0600)] <colinclark> Justin_o: I'm fairly flexible
[14:21:51 CST(-0600)] <jamon> i would prefer before noon on monday Justin_o
[14:21:54 CST(-0600)] <jhung1> jessm, colinclark: http://wiki.fluidproject.org/display/fluid/Infusion+Builder+Interface+Text
[14:22:19 CST(-0600)] <jessm> jhung1: i think you and i have a few more components to work on
[14:22:49 CST(-0600)] <jessm> one thing that bothered me was it felt sort of silly to describe something so seemingly self-evident like 'uploader' – this is where the existentialism came in too
[14:23:06 CST(-0600)] <jessm> we have two components that aren't self-evident from name: ui options and reorderer
[14:23:08 CST(-0600)] <jessm> are their others?
[14:23:40 CST(-0600)] <jhung1> jessm: Tooltip Wrapper is a weird one. Tooltip is obvious, but wrapper is not.
[14:24:00 CST(-0600)] <Justin_o> Bosmon: what time are you free.. would you be available before noon our time on monday?
[14:24:21 CST(-0600)] <jessm> jhung1: yes, tooltip was giving me convulsions
[14:25:31 CST(-0600)] <jhung1> jessm: Do you want to go through the text now?
[14:25:34 CST(-0600)] <Bosmon> Monday is fine
[14:25:49 CST(-0600)] <colinclark> Before noon is often awkward for Bosmon to schedule
[14:25:52 CST(-0600)] <colinclark> I'm free as well
[14:25:58 CST(-0600)] <Bosmon> Later in the day would be better
[14:26:06 CST(-0600)] <colinclark> Jamon and I have a meeting from 1-2 pm on Monday
[14:26:10 CST(-0600)] <colinclark> I'm free afterwards
[14:26:21 CST(-0600)] <jessm> jhung1: sure, but let's jump on skype if you don't mind
[14:27:23 CST(-0600)] <colinclark> Justin_o: ^
[14:27:48 CST(-0600)] <jhung1> jessm: sure
[14:28:45 CST(-0600)] <michelled> heidi_: my attempt to apply this patch 3837-j-cleanup manually is not going well
[14:28:55 CST(-0600)] <michelled> heidi_: any chance you can regenerate it?
[14:29:16 CST(-0600)] <heidi_> michelled - what conflicts are you getting when you tried to apply the patch?
[14:29:46 CST(-0600)] <michelled> none of changes in the CSS file are matching
[14:30:07 CST(-0600)] <Justin_o> colinclark, Bosmon, jamon: I'm okay anytime on monday... as long as it's not too late
[14:30:13 CST(-0600)] <Justin_o> jamon: are you free at all in the afternoon?
[14:30:37 CST(-0600)] <jamon> sometime after 14:00 works yes Justin_o
[14:30:59 CST(-0600)] <heidi_> michelled the two files (uploader.css and .html) are drastically different than older versions. to regenerate i would update my branch to the latest then try to apply the patch?
[14:31:57 CST(-0600)] <colinclark> hey harriswong, do you have a fork on Github for FLUID-3878, or is your -c patch the latest and greatest?
[14:35:06 CST(-0600)] <colinclark> hey jamon, whenever you get a free moment, can you look into the wiki's daily change emails? I've noticed they haven't been sent since around the time we did the username renaming early this week.
[14:35:08 CST(-0600)] <Justin_o> colinclark, michelled, Bosmon : i just pushed up heidi's patch. You can see the network graph now https://github.com/fluid-project/infusion/network
[14:35:17 CST(-0600)] <Justin_o> i used the --no-ff option as well
[14:35:39 CST(-0600)] <Justin_o> but the merge commit probably would have happened anyways i think
[14:35:39 CST(-0600)] <heidi_> michelled yeah the uploader cleanup in general was tricky. i'm not surprised it's still being painful heh
[14:35:46 CST(-0600)] <heidi_> but let me try
[14:38:56 CST(-0600)] <harriswong> colinclark: Yes, I forked a copy from infusion, and created a branch called FLUID-3878. I am not too sure if this URL will work but this is the branch: https://github.com/harriswong/infusion/tree/FLUID-3878
[14:39:01 CST(-0600)] <heidi_> git is so enthusiastic, i like it "Already up-to-date. Yeeah!"
[14:39:12 CST(-0600)] <colinclark> cool, thanks harriswong!
[14:39:53 CST(-0600)] <harriswong> colinclark: This branch is waiting for the #FLUID-3837 clean up though. The HTML and CSS might have been modified by #3837 and thus this branch will need to be tweaked afterwards.
[14:43:48 CST(-0600)] <colinclark> good to know, thanks
[14:43:59 CST(-0600)] <colinclark> michelled asked me to "pre-review" it
[14:51:30 CST(-0600)] <harriswong> EricDalquist: Hello Eric, would you like me to push my unit test to github for you try? Or is it more convenient for you if I attach the .js there on the jira thread?
[14:51:50 CST(-0600)] <EricDalquist> you can just attach it in the jira thread
[14:52:06 CST(-0600)] <EricDalquist> you may have to help me a little since I've never run a unit test in js before
[14:53:20 CST(-0600)] <harriswong> EricDalquist: Sure, np! I will attach it. I am still working on the unit test file so it might not be as clean as it should. Having that said, it should still be able to demonstrate the problem though..
[15:07:41 CST(-0600)] <Bosmon> michelled, Justin_o... do we consider this "new method" worked ok?
[15:08:01 CST(-0600)] <Justin_o> Bosmon: i think it is what we wanted
[15:08:05 CST(-0600)] <Bosmon> cool
[15:08:28 CST(-0600)] <Bosmon> Tom described the "other" method of accepting changes as named "cherrypicking"
[15:08:29 CST(-0600)] <Justin_o> i used the --no-ff with a merge... seems the same as doing it with a pull
[15:08:49 CST(-0600)] <Bosmon> That is what gives rise to those special kinds of messages we see with "committer" separate from "author"
[15:08:54 CST(-0600)] <Bosmon> but he seemed to prefer the --no-ff method
[15:08:56 CST(-0600)] <Justin_o> Bosmon: i think cherry-picking allows you to pick which commits you want when doing a merge
[15:09:16 CST(-0600)] <Bosmon> Justin_o: I'm puzzled.... isn't the meaning of --no-ff to simply mean to DO a merge?
[15:09:23 CST(-0600)] <Bosmon> It would seem impossible to request a merge, without getting a merge
[15:09:51 CST(-0600)] <Justin_o> well.. yes.. but i meant that instead of doing git pull --no-ff i did git merge --no-ff
[15:09:59 CST(-0600)] <Bosmon> Oh, I see
[15:10:04 CST(-0600)] <heidi_> michelled k it's here https://github.com/heidiv/infusion/tree/FLUID-3837 , but i'm going to test it a bit more on windows etc. also i just found a bug with scroller, when deleting a file with keyboard something odd is happening
[15:10:13 CST(-0600)] <Bosmon> Is it conceivable that "git merge" might not do a merge but instead a ff?
[15:11:29 CST(-0600)] <michelled> heidi_: thanks
[15:11:45 CST(-0600)] <michelled> heidi_: if you think the keyboard bug is a new one maybe you should file another JIRA?
[15:11:48 CST(-0600)] <michelled> what do you think?
[15:12:12 CST(-0600)] <Justin_o> Bosmon: yes.. it could happen
[15:12:39 CST(-0600)] <heidi_> michelled yeah maybe. it's related to 4037 which is already in, so that might be cleanest
[15:13:29 CST(-0600)] <heidi_> michelled is harris's error handling stuff in? i want to make sure i didn't mess up his css. but i think he's waiting on 3837 right?
[15:13:44 CST(-0600)] <Bosmon> Well.... that seems a little perplexing.... is there any difference between the behaviour of git pull and git merge in this case?
[15:13:49 CST(-0600)] <michelled> ya, there is a lot of dependency in these patches
[15:14:01 CST(-0600)] <michelled> heidi_: it's making to job of getting them in more complicated
[15:14:05 CST(-0600)] <Justin_o> Bosmon: basically pull does a merge underneath as i understand.. but you could merge a branch that already contains changes that the other branch also has.. which would cause the fastforward
[15:14:11 CST(-0600)] <heidi_> i hear ya
[15:14:27 CST(-0600)] <Justin_o> Bosmon: git pull is like doing a git fetch followed by git merge
[15:14:40 CST(-0600)] <Bosmon> ...
[15:14:43 CST(-0600)] <michelled> heidi_: so the keyboard bug is part of 4037 or a new JIRA related to 4037?
[15:14:45 CST(-0600)] <Bosmon> Well what is git merge like doing then
[15:14:59 CST(-0600)] <michelled> half a pull
[15:15:05 CST(-0600)] <Bosmon> In these terms you could similarly say, "git merge is like doing a git fetch followed by a git merge"
[15:15:05 CST(-0600)] * michelled is being a jerk
[15:15:08 CST(-0600)] <Bosmon> And THEN were would we be
[15:15:40 CST(-0600)] <Bosmon> A "jerk" is a kind of "impulsive tension"...
[15:15:45 CST(-0600)] <Bosmon> Very similar to a "pull".....
[15:15:46 CST(-0600)] <heidi_> michelled i'm not sure. it's all so confusing! i'll create a new jira
[15:16:07 CST(-0600)] <michelled> lol
[15:16:47 CST(-0600)] <michelled> ok, thx heidi_. have you tested 3837 enough? can that go in as far as behaviour goes?
[15:16:53 CST(-0600)] <Justin_o> Bosmon: so doing a pull will fetch the changes and automatically attempt to merge it
[15:17:32 CST(-0600)] <heidi_> michelled let me test windows and ie6 ... sec. also im checking if the bug is in the master or the new branch. if master then it's 4037's fault i think
[15:17:54 CST(-0600)] <athena> hey jhung1 - i miss anything while i was off demoing?
[15:17:54 CST(-0600)] <michelled> ok, sounds good
[15:18:50 CST(-0600)] <Bosmon> Justin_o - well sure - and how is that different from what a "merge" will do?
[15:19:00 CST(-0600)] <Bosmon> By "merge"... meaning, the command named "merge"
[15:19:21 CST(-0600)] <heidi_> michelled the bug's in master too. tho maybe it was there pre-4037. whatevs - new jira!
[15:19:34 CST(-0600)] <Justin_o> Bosmon: merge will just "merge" one branch into another.. it won't grab the data down from the remote
[15:19:50 CST(-0600)] <Bosmon> Justin_o: Surely it will... if you name a remote branch
[15:20:15 CST(-0600)] <michelled> I don't think so Bosmon. I think you need to fetch it
[15:21:11 CST(-0600)] <Justin_o> Bosmon: that remote branch you see when you do git branch -a is on your machine as far as i can tell
[15:21:35 CST(-0600)] <michelled> athena: I think jhung1 is in a meeting
[15:21:41 CST(-0600)] <Justin_o> so if there are more updates on the remote before you fetch you won't get those
[15:21:59 CST(-0600)] <jhung1> athena: yes, sorry in a meeting. I'll ping you later?
[15:22:04 CST(-0600)] <EricDalquist> harriswong: I grabbed the two .js files you just uploaded
[15:22:18 CST(-0600)] <EricDalquist> do you have a pointer to some docs on how to run the unit tests?
[15:22:51 CST(-0600)] <athena> yep!
[15:22:53 CST(-0600)] <athena> i'll be here
[15:22:55 CST(-0600)] <michelled> EricDalquist: the beauty of Qunit based javascript tests is that all you need to do is open the html file containing the test in your browser
[15:23:34 CST(-0600)] <michelled> harriswong: which html file are you tests part of?
[15:23:59 CST(-0600)] <harriswong> EricDalquist: http://issues.fluidproject.org/browse/FLUID-4045, this one: src/webapp/tests/component-tests/pager/html/Pager-test.html
[15:24:02 CST(-0600)] <harriswong> oops
[15:24:14 CST(-0600)] <harriswong> michelled: ^
[15:26:47 CST(-0600)] <harriswong> EricDalquist: What i do is I run this URL on my Windows Firefox: file:///C:/fluid/infusion/src/webapp/tests/component-tests/pager/html/Pager-test.html, you should then see #12 fails.
[15:26:55 CST(-0600)] <EricDalquist> got it
[15:27:12 CST(-0600)] <Justin_o> Bosmon: i have to leave, but if you find anything else interesting out about pull vs. merge please let me know
[15:27:25 CST(-0600)] <EricDalquist> ok so I need to grab Pager-test.html from the fluid source control then?
[15:27:39 CST(-0600)] <harriswong> EricDalquist: If you want to speed up the load time, you can skip all the other test by double-clicking #12, then it will run only #12
[15:28:13 CST(-0600)] <EricDalquist> do you have a quick pointer to where I can check out the fluid source to get Pager-test.html?
[15:28:24 CST(-0600)] <EricDalquist> sorry to be so new to this side of the project
[15:28:48 CST(-0600)] <michelled> EricDalquist: no need to be sorry! thanks for your help