[09:20:52 CST(-0600)] <harriswong> justin_o: hey justin, what is the "orientation: fluid.orientation.HORIZONTAL" supposed to do? i tried adding it to the js and taking it out; changing styles, but nothing is affected?..
[09:23:02 CST(-0600)] <justin_o> harriswong: that indicates it's main direction... this gets a little more complicated for more complex versions of the reorderer, but for the list reorderer it means it's only direction of movement.. So if you set the list reorderer to Horizontal you should expect to use the left and right arrow keys to move, if it were set to veritcal you would use the up and down arrow keys... this also determines whether drop targets appear above/below or left/right whe
[09:23:02 CST(-0600)] <justin_o> using the mouse
[09:26:44 CST(-0600)] <harriswong> justin_o: ok. do i have to do anything to the styles in order to use the orientation?
[09:27:01 CST(-0600)] <justin_o> harriswong: you shouldn't
[09:27:23 CST(-0600)] <justin_o> but if it is visually aligned in one orientation or the other it may be confusing to use
[09:28:35 CST(-0600)] <harriswong> justin_o: so say on the demo with a vertical list, if i name orientation to horizontal, the list will appears to be vertical visually, but i have to use left/right on keyboard to move the portlets?
[09:28:58 CST(-0600)] <harriswong> justin_o: and when i use the mouse to drag them, the dropMarker will appears on its left/right instead?
[09:29:21 CST(-0600)] <justin_o> harriswong: i believe so
[09:29:32 CST(-0600)] <harriswong> justin_o: k thanks
[09:29:39 CST(-0600)] <anastasiac> justin_o, I'm setting up a VM for windows screen reader testing - what version of Jaws should I be testing with?
[09:30:12 CST(-0600)] <justin_o> anastasiac: hmm... good question.. Golam had been testing with Jaws 10, 11, and 12.. i think 12 is the latest
[09:30:25 CST(-0600)] <anastasiac> ok, I'll start with the latest, I guess
[09:30:33 CST(-0600)] <justin_o> anastasiac: okay..
[09:30:42 CST(-0600)] <justin_o> that makes sense
[09:31:12 CST(-0600)] <anastasiac> justin_o, also, we'd like to test IE 8 and IE 7 if possible, right?
[09:31:23 CST(-0600)] <justin_o> anastasiac: yep
[09:31:29 CST(-0600)] <justin_o> that would be good
[09:31:30 CST(-0600)] <anastasiac> cool, thanks
[10:32:59 CST(-0600)] <heidi_> justin_o i can look at those issues today after all, matterhorn is telling me to wait a bit before diving into opencaps fixes
[12:00:26 CST(-0600)] <justin_o> anastasiac: wondering if the keyboard a11y demo is done and ready for review now, or are there more changes still being worked on?
[12:02:03 CST(-0600)] <anastasiac> justin_o, the screen reader experience is still not great at all, plus I need to enlarge the frame since you can't see the stars when the demo is in the portal
[12:04:16 CST(-0600)] <anastasiac> justin_o, I'm working on the screen reader stuff this afternoon (now that I'm finished the AODA and WHMIS training 
[12:05:30 CST(-0600)] <justin_o>
[12:05:32 CST(-0600)] <justin_o> okay.. thanks
[13:48:02 CST(-0600)] <michelled_> fluid-everyone, since we can't seem to get a good room or properly set up audio, let's try to have the dev meeting here
[13:48:26 CST(-0600)] <Bosmon> If Yura is showing stuff, perhaps he could talk in the Breeze room personally?
[13:48:42 CST(-0600)] <Bosmon> I assume we have no problem listening to people, just with having them speaking 
[13:48:56 CST(-0600)] <jessm> michelled_: breeze is foobar?
[13:50:26 CST(-0600)] <Bosmon> Oh
[13:50:33 CST(-0600)] <Bosmon> I see I was looking at the notes from 2 weeks ago
[13:51:22 CST(-0600)] <justin_o> fluid-everyone: are we going to be starting the dev meeting here?
[13:51:53 CST(-0600)] <anastasiac> do we have an agenda for the dev meeting?
[13:55:13 CST(-0600)] <michelled_> I figured you'd all have started - we know the drill 
[13:55:28 CST(-0600)] <Bosmon> What's all this "you", white man?
[13:55:34 CST(-0600)] <anastasiac> LOL
[13:55:50 CST(-0600)] <michelled_> ok, so anastasiac was going to give us some pointers on how to write good JIRAs
[13:56:08 CST(-0600)] <Bosmon> For a start - who do we actually have for this meeting?
[13:56:11 CST(-0600)] <Bosmon> I can't tell
[13:56:15 CST(-0600)] <mlam> present
[13:56:19 CST(-0600)] <colinclark> Hi everyone, sorry I'm late
[13:56:27 CST(-0600)] <colinclark> I've bee helping with tours and visits today--whew!
[13:56:36 CST(-0600)] <michelled_> then perhaps justin_o can give us a quick bug parade update
[13:56:42 CST(-0600)] <Bosmon> At the new "OCAD Theme Park"
[13:56:57 CST(-0600)] <colinclark> OCAD has a theme park?
[13:57:01 CST(-0600)] <colinclark> Are we the exhibits?
[13:57:01 CST(-0600)] <michelled_> I've heard a rumour that anastasiac wants to show us the new keyboard a11y demo
[13:57:05 CST(-0600)] <michelled_> so that's 3 items
[13:57:11 CST(-0600)] <michelled_> does anyone have any other?
[13:57:22 CST(-0600)] <colinclark> That sounds like a good agenda, michelled_
[13:58:04 CST(-0600)] <michelled_> the good thing about anastasiac giving us her guidelines in here is that we'll be able to find it on the wiki
[13:58:10 CST(-0600)] <anastasiac> So: "How to write a good JIRA"
[13:58:19 CST(-0600)] * anastasiac hadn't actually prepared anything, so this will be off the cuff
[13:58:30 CST(-0600)] <michelled_> good thing you're so good at this
[13:58:32 CST(-0600)] <anastasiac> one important thing to keep in mind is "who is the audience?"
[13:58:40 CST(-0600)] <anastasiac> I can think of two, for starters:
[13:58:56 CST(-0600)] <anastasiac> 1) other people searching the list for bugs similar to what they've found
[13:59:04 CST(-0600)] <anastasiac> 2) developers trying to fix the bug
[13:59:06 CST(-0600)] <jessm> anastasiac: i plunked some material into the wiki – lemme find the link
[13:59:13 CST(-0600)] <anastasiac> can anyone think of other audiences?
[13:59:19 CST(-0600)] <jessm> http://wiki.fluidproject.org/display/fluid/How+to+write+a+good+JIRA+ticket
[13:59:32 CST(-0600)] <jessm> perhaps we can put more info in there from this convo or even during this convo
[13:59:35 CST(-0600)] <anastasiac> jessm, thanks - maybe after this meeting, I can add more to that page
[14:00:19 CST(-0600)] <anastasiac> for audience #1, the summary is the most important. It's helpful if it describes the issue from a behavioural perspective:
[14:00:36 CST(-0600)] <anastasiac> it's doing some such thing, it's not doing some such thing; this is happening, that is happening
[14:01:08 CST(-0600)] <michelled_> I guess people trying to plan out work for important releases
[14:01:09 CST(-0600)] <anastasiac> In the description, it's good to include:
[14:01:17 CST(-0600)] <anastasiac> how to reproduce it
[14:01:40 CST(-0600)] <anastasiac> any thoughts you might have on why you think it's happening
[14:01:45 CST(-0600)] <anastasiac> or how it might be fixed
[14:02:13 CST(-0600)] <anastasiac> it's good to clarify what you would expect to happen, if it's not obvious from the description
[14:02:46 CST(-0600)] <anastasiac> It's really helpful to remember to se the component of the JIRA. Personally, I really filter by component a lot, and if you forget that, the bug report could easily get lots
[14:02:48 CST(-0600)] <anastasiac> lost
[14:03:04 CST(-0600)] <anastasiac> I suppose I forgot one important point:
[14:03:15 CST(-0600)] <anastasiac> before you file a JIRA, search to see if it's already been filed!
[14:03:37 CST(-0600)] <anastasiac> If it has, add a comment to the existing jira describing any additional information you might have
[14:03:45 CST(-0600)] <anastasiac> Other general tips:
[14:03:54 CST(-0600)] <anastasiac> if it's a visual/styling problem, attach a screen shot
[14:04:34 CST(-0600)] <anastasiac> If you can include a link to a page or test on the build site, that can make it easier for people to reproduce
[14:04:45 CST(-0600)] <anastasiac> michelled_ mentioned people planning releases:
[14:05:05 CST(-0600)] <anastasiac> it's helpful if you can remember to set the "affects" version: this is the version of the software in which you observe the problem
[14:05:24 CST(-0600)] <anastasiac> justin_o, can you suggest what we should do with this version if we observe it in trunk?
[14:05:27 CST(-0600)] <colinclark> anastasiac: Do you have an example of a particular JIRA that you could show us the "anatomy of?"
[14:05:35 CST(-0600)] <anastasiac> e.g. now: it's not 1.2, but not 1.3
[14:06:06 CST(-0600)] <anastasiac> colinclark, you must have missed the part where I said "I didn't prepare for this"
[14:06:15 CST(-0600)] <anastasiac> I can root around for one... hang on...
[14:06:16 CST(-0600)] <colinclark> lol
[14:06:20 CST(-0600)] <colinclark> sorry, anastasiac
[14:06:25 CST(-0600)] <colinclark> not to put you on the spot
[14:06:26 CST(-0600)] <anastasiac> np
[14:06:28 CST(-0600)] <colinclark> if you find someting, that's cool
[14:06:31 CST(-0600)] <colinclark> otherwise, no worries
[14:06:47 CST(-0600)] <justin_o> anastasiac: i think it if it will be fixed as part of the release we should not put an affects version, but just a fix for version. If it won't be, then the version of upcoming release
[14:07:02 CST(-0600)] <justin_o> it's likely though that it may have been in prior versions too so checking that might help too
[14:07:09 CST(-0600)] <anastasiac> cool, thanks
[14:07:23 CST(-0600)] <anastasiac> fluid-everyone: any additions, questions?
[14:09:03 CST(-0600)] <anastasiac> well, I'll update that wiki page with more of these tips. Feel free to add to the page any other things you think are good practice
[14:09:17 CST(-0600)] <michelled_> what should we do when we come across a JIRA we can't understand?
[14:10:02 CST(-0600)] <mlam> contact the author for clarification?
[14:10:15 CST(-0600)] <anastasiac> mlam, that's probably a good start
[14:10:27 CST(-0600)] <anastasiac> I think we should feel free to update the descriptions or summaries of JIRAs to make them more helpful, if we can come to an understanding
[14:11:20 CST(-0600)] <anastasiac> fluid-everyone: another suggestion: if you're working on a JIRA, it's helpful to set its status to "in progress"
[14:11:30 CST(-0600)] * michelled_ is expecting to be contacted for lots of past JIRAs which weren't clear enough
[14:11:33 CST(-0600)] <Bosmon> I guess this discussion so far has been mainly about "user-visible" JIRAs relating to observed failures in behaviour
[14:11:50 CST(-0600)] <Bosmon> We might want to distinguish perhaps the class of "framework-targetted" JIRAs which we might raise amongst ourselves
[14:12:05 CST(-0600)] <Bosmon> For example things like YURA's recent JIRA relating to incompleteness of fluid.remove_if etc.
[14:12:06 CST(-0600)] <justin_o> Bosmon: i think all jira's would be user facing though
[14:12:24 CST(-0600)] <justin_o> since our users may themselves be using the framework too
[14:12:24 CST(-0600)] <anastasiac> Bosmon, good point, though I think the advise is still relevant, with very minor tweaks
[14:12:44 CST(-0600)] <anastasiac> the summary should still be clear enough that someone who's encountered the same issue will recognize it
[14:12:57 CST(-0600)] <anastasiac> the description should include thoughts/plans on how to address it
[14:13:22 CST(-0600)] <anastasiac> Bosmon, do you have a number for Yura's issue?
[14:14:58 CST(-0600)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-3857
[14:15:40 CST(-0600)] <anastasiac> thanks
[14:16:06 CST(-0600)] <anastasiac> so here's a question for fluid-everyone: is this actually a bug, or a task? or am I splitting hairs?
[14:16:20 CST(-0600)] <Bosmon> It should really be "Improvement" I guess
[14:16:24 CST(-0600)] <Bosmon> It is certainly not a "task"
[14:16:35 CST(-0600)] <michelled_> to me there is very little difference. in the end we need to communicate clearly in our JIRA issues
[14:16:37 CST(-0600)] <Bosmon> Is "task" appropriate for anything which involves writing some new code?
[14:16:50 CST(-0600)] <anastasiac> Bosmon, why would it not be?
[14:17:13 CST(-0600)] <Bosmon> I always read "task" as "something to DO"
[14:17:24 CST(-0600)] <Bosmon> That is... in the "real world"
[14:17:31 CST(-0600)] <Bosmon> "put up a server", "write some documentation" etc.
[14:17:35 CST(-0600)] <anastasiac> hm. interesting...
[14:17:51 CST(-0600)] <Bosmon> Whereas I saw "bug" and "improvement" as two kinds of code-related tasks
[14:17:59 CST(-0600)] <Bosmon> "bug" if you could consider the existing behaviour out-and-out faulty
[14:18:13 CST(-0600)] <Bosmon> and "improvement" if the existing behaviour could in some sense be considered correct, but incomplete
[14:18:57 CST(-0600)] <anastasiac> so Bosmon, you suggested we distinguish between JIRA's like this one and more directly user-facing jiras. What kind of distinction were you thinking of?
[14:19:17 CST(-0600)] <colinclark> I typically use improvement for something like this
[14:19:17 CST(-0600)] <colinclark> Though I guess the category is, as michelled_ says, less important than clearly describing the work
[14:19:21 CST(-0600)] <Bosmon> Well, just a distinction in terms of the goals they might meet.... in terms of where you came ine, "who is the audience for this"
[14:19:45 CST(-0600)] <Bosmon> For framework-related JIRAs, I would like to see an emphasis on "intent"
[14:20:00 CST(-0600)] <Bosmon> That is, "Why do we plan to implement this functionality and who might benefit"
[14:20:24 CST(-0600)] <Bosmon> Whereas for the other kind of issue, where a "user" is reporting a fault, the purpose of fixing it would be inherently clear
[14:20:27 CST(-0600)] <anastasiac> agreed - that information would be very useful in filing a jira like that
[14:21:00 CST(-0600)] <justin_o> Bosmon: is your distinction between framework and other issues... or between bugs vs improvements?
[14:21:08 CST(-0600)] <Bosmon> The purpose would be so that the user sees the fault go away
[14:21:19 CST(-0600)] <Bosmon> justin_o: between framework and other issues
[14:22:19 CST(-0600)] <justin_o> Bosmon: but i could see yura being a user of our reporting bugs in the framework?
[14:22:26 CST(-0600)] <justin_o> sorry.. shouldn't be a question
[14:22:40 CST(-0600)] <Bosmon> So, I think this upcoming issue of YURA's will be a good test case
[14:22:57 CST(-0600)] <Bosmon> He is about to report a bug relating to "order of expansion" of material in configuration trees
[14:23:29 CST(-0600)] <Bosmon> Probably related to a timing issue affecting "value resolution" with respect to the "deferred fetch expander"
[14:24:09 CST(-0600)] <Bosmon> But I am encouraging him to actually submit it as if it were a "user issue".... that is, to provide all the context for where he was in the middle of CSpace code where he encountered this issue
[14:24:47 CST(-0600)] <anastasiac> Bosmon, that sounds good - by describing the context, it shows what the effect of the bug is on the user
[14:24:54 CST(-0600)] <anastasiac> he can provide more technical details in the description
[14:24:59 CST(-0600)] <justin_o> Bosmon: yes that makes sense
[14:25:35 CST(-0600)] <Bosmon> "I wrote the following tree" "I attached it to this component" "It issued the following AJAX" "It failed for this reason"
[14:25:44 CST(-0600)] <Bosmon> But, being a "framework issue" it sort of comes in two parts
[14:25:58 CST(-0600)] <Bosmon> Since it might be in no way clear from the description what the failure really is in or what to do about it
[14:26:58 CST(-0600)] <Bosmon> Even if the description of the failure is very clear and detailed
[14:27:10 CST(-0600)] <anastasiac> I would suggest that in a case like this, if you actually have knowledge/info/suspicions s to what the failure really is, you should add them as well- sometimes I've put this in the actual description, sometimes added as a comment after
[14:29:13 CST(-0600)] <anastasiac> that brings up a good suggestion for triage, fluid-everyone: If you're reviewing JIRAs and doing a bit of investigating but not planning to actually fix right away, please add any findings you make to the JIRA as a comment - this will save someone time later
[14:29:30 CST(-0600)] <Bosmon> Well
[14:29:36 CST(-0600)] <Bosmon> This should be essentially an axiom
[14:29:58 CST(-0600)] <Bosmon> Just as i) NEVER omit anything that appears in your mind as being relevant information from a JIRA report
[14:30:18 CST(-0600)] <Bosmon> As ii) Whenever you come across or make some code which tests an issue, ALWAYS commit it to the framework
[14:30:30 CST(-0600)] <anastasiac> yes, it should be, but it doesn't hurt to remind people, including myself!
[14:31:22 CST(-0600)] <anastasiac> so, fluid-everyone, does anyone have any more questions or comments on the topic of how to write a good JIRA?
[14:31:32 CST(-0600)] <michelled_> and iii) when you talk to someone about an issue - whether it is you reporting it or explaining it - put the outcomes of the conversation on the JIRA
[14:31:43 CST(-0600)] <anastasiac> michelled_, good one!
[14:33:18 CST(-0600)] <justin_o> michelled_: to that point, if there is a discussion on list or in the channel about it, providing a link to the log/archive would be good
[14:33:56 CST(-0600)] <michelled_> sounds good
[14:34:13 CST(-0600)] <michelled_> justin_o: since you are talking - do you want to give us a quick update on 1.3 progress?
[14:34:20 CST(-0600)] <justin_o> michelled_: sure
[14:34:30 CST(-0600)] <justin_o> There are just over 2 weeks left on bug parade, which finishes Dec 9.
[14:34:38 CST(-0600)] <michelled_> anastasiac: thanks so much for the overview!
[14:35:08 CST(-0600)] <justin_o> Most things are moving along well. There have been some code reviews, which have lead to jiras being closed, and re-opened as needed. There's still a bunch of little stuff for Pager, Inline Edit, and etc. Plus all the big work on Uploader and Reorderer. mlam and colinclark seem to be making good progress on uploader.
[14:35:14 CST(-0600)] <anastasiac> np - I'm glad it was in the channel - now I can review to update the wiki
[14:35:31 CST(-0600)] <justin_o> Bosmon: Anything you can tell us about the progress of the reorderer?
[14:35:44 CST(-0600)] <heidi_> im noticing the css "inline-block" is getting used a lot in demos/components , but it doesn't work in IE8
[14:35:56 CST(-0600)] <justin_o> heidi_: really
[14:35:57 CST(-0600)] <Bosmon> Not a great deal - there is a branch containing my "little component" which Colin has been using for uploader
[14:36:01 CST(-0600)] <heidi_> yeah
[14:36:07 CST(-0600)] <Bosmon> The work is requiring a fair amount of refactoring of Reorderer which is still underway
[14:36:13 CST(-0600)] <anastasiac> heidi_, is there an alternative that is cross-browser?
[14:36:13 CST(-0600)] <Bosmon> I will look at it more tomorrow
[14:36:18 CST(-0600)] <justin_o> heidi_: guess that's why the styling is off for inlineEdit in IE8 then eh?
[14:36:34 CST(-0600)] <heidi_> its in inline edit, and it was in keyboard a11y demo too
[14:36:38 CST(-0600)] <heidi_> ya i think so
[14:37:01 CST(-0600)] <Bosmon> I had got to the decision point where I thought it was the best thing to make the Reorderer dependent on IoC, at least for "new functionality"
[14:37:03 CST(-0600)] <heidi_> i took it out of kb demo
[14:37:10 CST(-0600)] <Bosmon> Even though clearly we can't change its API for "old functionality"
[14:37:22 CST(-0600)] <Bosmon> There's no point writing "new stuff" in a crappy and antique fashion
[14:37:30 CST(-0600)] <justin_o> Bosmon: okay.. thanks... Harris is looking into a bug with reorder, not sure if it may be related to any recent changes you may have made, or that were made for the wrapping
[14:37:44 CST(-0600)] <Bosmon> I haven't made any commits to trunk yet
[14:37:59 CST(-0600)] <Bosmon> The last change to Reorderer was the big patch that we worked on with golam
[14:38:03 CST(-0600)] <justin_o> Bosmon: okay.. guess it's something else..
[14:38:28 CST(-0600)] <justin_o> Bosmon: won't that make the reorderer dependent on the IoC stuff though
[14:38:30 CST(-0600)] <Bosmon> But there are certainly a number of outstanding bugs wich the Reorderer
[14:38:47 CST(-0600)] <Bosmon> Can you give a brief characterisation of the issue harris is seeing?
[14:38:53 CST(-0600)] <Bosmon> Yes, it will
[14:38:56 CST(-0600)] <heidi_> the inline-block is pretty essential to inline edit right now... hmm
[14:39:02 CST(-0600)] <justin_o> harriswong: could you describe the bug you are working on?
[14:39:11 CST(-0600)] <Bosmon> But I think we have to accept that IoC is going to be positioned as a part of the "core framework"
[14:39:16 CST(-0600)] <harriswong> Bosmon: http://issues.fluidproject.org/browse/FLUID-3862
[14:39:19 CST(-0600)] <Bosmon> At least, this is the impression I have been getting from chats with colinclark
[14:39:34 CST(-0600)] <justin_o> Bosmon: is this dependency something we want to add, is it for code that everyone using reorderer will use.. or just extra optional stuff?
[14:40:07 CST(-0600)] <harriswong> Bosmon: In brief, setting orientation to horizontal doesn't allow the keyboard to navigate portlet using left and right arrow keys
[14:40:11 CST(-0600)] <Bosmon> Well, the reorderer won't work without it... unless we are "tricksy" about how it initialises itself
[14:40:19 CST(-0600)] <justin_o> Bosmon: I see what you're saying now... i guess it sort of goes back to a question i asked a few months ago, which was should we have Production components depending on sneak peek code?
[14:40:23 CST(-0600)] <heidi_> (sorry to interrupt dev meeting!)
[14:40:43 CST(-0600)] <Bosmon> justin_o: Yes... I think we got to some kind of answer for that question?
[14:40:48 CST(-0600)] <Bosmon> I'm not sure if I remember right
[14:41:36 CST(-0600)] <justin_o> heidi_: no problem... any thoughts on how to get around it.. i suppose for inlineEdit it is really just an issue for an edge case
[14:41:46 CST(-0600)] <justin_o> Bosmon: yah.. i can't remember the answer off hand either
[14:42:08 CST(-0600)] <heidi_> justin_o i wonder if no text is an edge case? seems like something ppl would use a lot for forms etc
[14:42:11 CST(-0600)] <Bosmon> harriswong: Is it possible this issue has the same cause as http://issues.fluidproject.org/browse/FLUID-3677 ?
[14:43:28 CST(-0600)] <Bosmon> justin_o: What I remember from the discussion is that we decided that it was OK, so long as the dependency was not passed on to the user in terms of some visible API usage
[14:43:59 CST(-0600)] <justin_o> Bosmon: okay...
[14:44:36 CST(-0600)] <justin_o> as for the issue harriswong is working on, it is different... basically setting the orientation to horizontal or vertical has no affect, it always behaves vertically
[14:45:33 CST(-0600)] <Bosmon> I see, that's interesting
[14:45:48 CST(-0600)] <Bosmon> Is the issue the same if you try with the Infusion 1.2 final release?
[14:45:52 CST(-0600)] <harriswong> Bosmon, justin_o: They might be related though, the behaviors sound similar.
[14:46:13 CST(-0600)] <justin_o> harriswong: have you had a chance to double check that
[14:46:27 CST(-0600)] <harriswong> Bosmon: i will give 1.2 a try. 1.1.3 works fine though.
[14:46:39 CST(-0600)] <harriswong> justin_o: ^
[14:46:48 CST(-0600)] <justin_o> harriswong: thanks
[14:48:14 CST(-0600)] <justin_o> fluid-everyone: I think that was it for the bug parade stuff
[14:48:51 CST(-0600)] <justin_o> heidi_: i suppose, but I wonder if there would be some default text.. you see that sometimes for things like phone numbers where there is a sample of how it should look like in the field to start with
[14:49:18 CST(-0600)] <michelled_> cool - anastasiac thoughts on whether you can manage a code tour in this format?
[14:49:38 CST(-0600)] <heidi_> justin_o putting a " " (one space) for default view text breaks stuff totally
[14:49:41 CST(-0600)] <heidi_> in IE
[14:49:48 CST(-0600)] <heidi_> hmm
[14:50:15 CST(-0600)] <justin_o> heidi_: i suppose that would be the case too if someone entered " " as the edited text
[14:50:21 CST(-0600)] <anastasiac> michelled_, I might be able to, if everyone was able to bring the code up in an environment that supported line numbers. But it's almost 4pm - we've been at this for a while...
[14:50:35 CST(-0600)] <heidi_> justin_o yes you're right
[14:50:38 CST(-0600)] <anastasiac> do we want to keep going, or wrap up for this week?
[14:50:44 CST(-0600)] <heidi_> entering a space makes it no longer clickable
[14:51:09 CST(-0600)] <justin_o> heidi_: ah okay.. so that was the issue that was in that jira i think
[14:51:15 CST(-0600)] <heidi_> yeah
[14:51:27 CST(-0600)] <heidi_> from the manual test page
[14:51:42 CST(-0600)] <anastasiac> it does seem sub-optimal to do a code tour here...
[14:51:54 CST(-0600)] <michelled_> ok, let's leave then
[14:51:59 CST(-0600)] <harriswong> Bosmon, justin_o: tag/infusion-1.2 works fine with horizontal orientation
[14:53:10 CST(-0600)] <justin_o> harriswong: thanks.. that's good, glad we didn't ship with it broken
[14:53:55 CST(-0600)] <Bosmon> Ok
[14:53:59 CST(-0600)] <Bosmon> So that is an interesting regression
[14:54:09 CST(-0600)] <Bosmon> I guess it is likely that some part of the "wrapping" work broke it
[14:55:55 CST(-0600)] <justin_o> harriswong: you may want to check out the code just before and just after the no-wrap option was added
[14:56:30 CST(-0600)] <harriswong> Bosmon: could be. I traced it to Reorderer.js line 576 (rev. 10304), the condition (dirorient === orientation) gives 4===1 which should had been 4===4.
[14:56:39 CST(-0600)] <harriswong> justin_o: Will try that now.
[14:57:18 CST(-0600)] <harriswong> justin_o: give me a min, dealing w/ conflicts on layoutReorderer...
[14:58:07 CST(-0600)] <justin_o> harriswong: no problem
[15:10:22 CST(-0600)] <colinclark> Sorry that I haven't been able to follow the conversation here very well
[15:10:53 CST(-0600)] <colinclark> justin_o and Bosmon, yes we did agree that dependency on IoC is okay for production-level components, as long as it is not passed on public to users in terms of the API
[15:11:19 CST(-0600)] <justin_o> colinclark: okay.. thanks
[15:11:24 CST(-0600)] <colinclark> In other words, we can use IoC in production components even while it's still sneak peek. We just don't want to do anything that will force our users to use IoC APIs directly
[15:25:04 CST(-0600)] <harriswong> justin_o, Bosmon: I did a quick check on SVN, rev 9948 works, rev 9949 breaks. 9949 is related to fluid-3675.
[15:36:57 CST(-0600)] <anastasiac> fluid-everyone: I've updated the wiki based on our JIRA discussions today (and renamed the page): http://wiki.fluidproject.org/display/fluid/JIRA+Best+Practices Feel free to keep adding to this page
[15:37:38 CST(-0600)] <michelled> thanks anastasiac
Manage space
Manage content
Integrations