/
fluid-work IRC Logs-2009-05-25

fluid-work IRC Logs-2009-05-25

May 25, 2009

[06:20:13 EDT(-0400)] * davetrey (n=davetrey@73-35-245.uoc.es) has joined #fluid-work
[08:24:52 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:28:47 EDT(-0400)] * jsilvaa (n=jsilva@142.150.82.73) has joined #fluid-work
[08:31:36 EDT(-0400)] * laurel (n=Laurel@142.150.154.178) has joined #fluid-work
[08:45:53 EDT(-0400)] * hydee (n=hydee@bas5-oshawa95-1176469582.dsl.bell.ca) has joined #fluid-work
[09:01:04 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined #fluid-work
[09:12:04 EDT(-0400)] * yura (n=yura@142.150.82.64) has joined #fluid-work
[09:26:37 EDT(-0400)] * davetrey (n=davetrey@94.pool85-50-156.dynamic.orange.es) has joined #fluid-work
[09:32:24 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:42:48 EDT(-0400)] <anastasiac> Justin_o (and laurel, and fj4000, and anyone else doing code reviews): I'll have a look at FLUID-2756 to start today off
[09:43:05 EDT(-0400)] <Justin_o> anastasiac: thank you
[09:43:36 EDT(-0400)] <anastasiac> I encourage everyone to drop a note in the channel regarding what you're reviewing, so that we don't duplicate each other's effort
[09:53:52 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[09:59:44 EDT(-0400)] <anastasiac> Justin_o: FLUID-2756 reviewed and commented on: +1
[10:00:30 EDT(-0400)] <Justin_o> anastasiac: thank you, i'll update bug parade
[10:00:42 EDT(-0400)] <anastasiac> I'll review FLUID-2722 now
[10:05:43 EDT(-0400)] <anastasiac> Justin_o: FLUID-2722 reviewed and commented on: +1
[10:07:35 EDT(-0400)] <anastasiac> Justin_o et al: I'll review FLUID-2650 next
[10:07:56 EDT(-0400)] <Justin_o> anastasiac: thank you
[10:15:40 EDT(-0400)] <Justin_o> to all, just going to do a quick rebuild of the daily build site
[10:26:16 EDT(-0400)] * heidi_ (n=thesumme@bas5-oshawa95-1176469582.dsl.bell.ca) has joined #fluid-work
[10:32:48 EDT(-0400)] * davetrey (n=davetrey@73-35-245.uoc.es) has joined #fluid-work
[10:41:37 EDT(-0400)] * dtrelles (n=davetrey@73-32-144.uoc.es) has joined #fluid-work
[10:47:55 EDT(-0400)] <anastasiac> Justin_o: I've commented on FLUID-2650: It was escalated because it's caused by a jQuery bug, but laurel did come up with a good workaround. I attached a new patch that tweaked her workaround. The question now is whether or not we should apply the change, given that it's a workaround to a jQuery bug.
[10:48:31 EDT(-0400)] <Justin_o> anastasiac: good question, any thoughts on that
[10:51:09 EDT(-0400)] <anastasiac> justin_o: I think the user experience is much better with laurel's patch - quite disconcerting if the dialog is not even onscreen.
[10:51:33 EDT(-0400)] <anastasiac> we should try to keep an eye on the jQuery ticket, and revert our fix if we upgrade to the fixed jQuery
[10:51:37 EDT(-0400)] <anastasiac> but I think we should patch our code for now
[10:51:53 EDT(-0400)] <anastasiac> maybe file a new JIRA for the "reversion" so that we don't forget.
[10:52:30 EDT(-0400)] <anastasiac> Justin_o: do you want to have a quick look at my screen, to see what the new experience is? Make sure it's up to your standards?
[10:54:18 EDT(-0400)] <fj4000> if anyone could review 2761 and 2762, i would appreciate it
[11:08:56 EDT(-0400)] <anastasiac> Justin_o: FLUID-2650 has been reviewed to death now.
[11:18:25 EDT(-0400)] <anastasiac> Justin_o: I'll review FLUID-2597 next
[11:19:43 EDT(-0400)] * heidi_ (n=thesumme@bas5-oshawa95-1176469582.dsl.bell.ca) has joined #fluid-work
[11:24:20 EDT(-0400)] * Bosmon (n=Bosmon@78-105-207-102.zone3.bethere.co.uk) has joined #fluid-work
[11:24:44 EDT(-0400)] <anastasiac> Justin_o: FLUID-2597 reviewed and commented on: +1
[11:26:35 EDT(-0400)] <anastasiac> I'll review FLUID-2500 next
[11:35:05 EDT(-0400)] <anastasiac> Justin_o: I've reopened FLUID-2500, and I'm passing it back to fj4000
[11:35:32 EDT(-0400)] <fj4000> did you comment it?
[11:35:38 EDT(-0400)] <anastasiac> but of course!
[11:35:46 EDT(-0400)] <anastasiac> minor change
[11:35:49 EDT(-0400)] <anastasiac> just housecleaning
[11:35:50 EDT(-0400)] <fj4000> sorry, saw it late
[11:35:52 EDT(-0400)] <fj4000> ok
[11:36:05 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:36:24 EDT(-0400)] <anastasiac> Justin_o, I'll review FLUID-2478 next
[11:36:26 EDT(-0400)] <colinclark> Justin_o: Hey
[11:36:37 EDT(-0400)] <Justin_o> colinclark: hello
[11:36:47 EDT(-0400)] <colinclark> fj4000 pinged me off-channel about http://issues.fluidproject.org/browse/FLUID-2545
[11:36:49 EDT(-0400)] <Justin_o> anastasiac: sorry... been away from my computer for a bit, thanks for the reviews
[11:36:55 EDT(-0400)] <colinclark> This one isn't a bug.
[11:37:26 EDT(-0400)] <Justin_o> colinclark: thanks we were wondering about that. I'll pull it off of bug parade
[11:37:29 EDT(-0400)] <anastasiac> colinclark, yes - Justin_o caught that one, and I wondered
[11:37:42 EDT(-0400)] <Bosmon> I will have an attempt at FLUID-2374 and FLUID-2411 later
[11:38:00 EDT(-0400)] <colinclark> anastasiac: The keyboard-a11y plugin isn't a component, and needn't follow our flc- selector conventions.
[11:38:09 EDT(-0400)] <anastasiac> exactly
[11:38:19 EDT(-0400)] <Bosmon> I notice that FLUID-2664 has been unassigned from Bug Parade?
[11:38:21 EDT(-0400)] <colinclark> In fact, that selector is specifically generic--the most likely simple convention that other people might use for denoting selectables.
[11:38:22 EDT(-0400)] <anastasiac> I was obviously being over-zealous when I filed that one (smile)
[11:38:26 EDT(-0400)] <colinclark> lol
[11:38:37 EDT(-0400)] <fj4000> ok, anastasiac
[11:38:44 EDT(-0400)] <fj4000> pls have another look
[11:38:58 EDT(-0400)] <Bosmon> yura - do you think you will be able to deal with FLUID-2637 today?
[11:39:01 EDT(-0400)] <Bosmon> If not, I will deal with it
[11:39:55 EDT(-0400)] <yura> Bosmon: I am working on it right now, I just need to make sure those arrows disappear when sorting is off, so hopefully yes
[11:39:57 EDT(-0400)] <anastasiac> fj4000 - will do - why don't you "resolve" the JIRA while I'm looking?
[11:40:07 EDT(-0400)] <fj4000> (tongue)
[11:41:23 EDT(-0400)] <Justin_o> Bosmon: fluid-2664 and fluid-1945 were removed from the bug parade as Yura took them as far as they could go right now, one issue is that fckeditor doesn't support CDN's at this point, and the other is that the css for selectbox needs to be redone by fj4000 (he doesn't have time at the moment for this though)
[11:41:30 EDT(-0400)] <anastasiac> Justin_o: FLUID-2500 looks good to go - +1 to close it
[11:41:32 EDT(-0400)] <Bosmon> Hah!
[11:41:37 EDT(-0400)] <Bosmon> DOESN'T SUPPORT CDNS!!!!
[11:41:41 EDT(-0400)] <Bosmon> I think I can guess why
[11:41:57 EDT(-0400)] <Bosmon> yura - awesome
[11:52:46 EDT(-0400)] <fj4000> Bosmon: gotta q for you
[11:52:51 EDT(-0400)] <Bosmon> y
[11:52:57 EDT(-0400)] <fj4000> regarding 2448
[11:53:04 EDT(-0400)] <Bosmon> oh
[11:53:22 EDT(-0400)] <fj4000> i see your focus override, and i see where it went originally
[11:53:40 EDT(-0400)] <fj4000> and so inside base.css the code removes the :focus styling
[11:53:42 EDT(-0400)] <Bosmon> originally?
[11:53:45 EDT(-0400)] <Bosmon> Has it moved already?
[11:53:49 EDT(-0400)] <fj4000> yup
[11:53:52 EDT(-0400)] <Bosmon> ...
[11:53:52 EDT(-0400)] <fj4000> let me find the line
[11:54:20 EDT(-0400)] <fj4000> near the beginning
[11:54:23 EDT(-0400)] <fj4000> a {}
[11:54:27 EDT(-0400)] <fj4000> outline:none
[11:54:31 EDT(-0400)] <fj4000> inside base.css
[11:54:47 EDT(-0400)] <fj4000> and essentially your change puts it back in, which is good
[11:54:59 EDT(-0400)] <fj4000> but what should we say about this?
[11:55:10 EDT(-0400)] <Bosmon> Well
[11:55:11 EDT(-0400)] <fj4000> base.css employs a bad strategy?
[11:55:16 EDT(-0400)] <Bosmon> I would guess
[11:55:19 EDT(-0400)] <Bosmon> Is this a Sakai thing?
[11:55:25 EDT(-0400)] <fj4000> this is YUI code
[11:55:27 EDT(-0400)] <Bosmon> Glarg
[11:55:29 EDT(-0400)] <Bosmon> What the hell!!!
[11:55:35 EDT(-0400)] <fj4000> is it old?
[11:56:04 EDT(-0400)] <fj4000> maybe is some sort of merger of YUI CSS code and someone elses ideas
[11:56:10 EDT(-0400)] <fj4000> but the bulk of this is YUI
[11:56:44 EDT(-0400)] <Justin_o> anastasiac: do you mind closing FLUILD-2597, I feel awkward about doing that since I fixed it
[11:56:47 EDT(-0400)] <Bosmon> Well
[11:56:51 EDT(-0400)] <Bosmon> This is sort of semi-disastrous (tongue)
[11:56:53 EDT(-0400)] <fj4000> i take that back - without a licenese, i cant be certain
[11:56:59 EDT(-0400)] <anastasiac> Justin_o: np (smile)
[11:57:04 EDT(-0400)] <Justin_o> anastasiac: thanks
[11:57:07 EDT(-0400)] <Bosmon> It seems we have started to put some of our own stuff into this file
[11:57:10 EDT(-0400)] <fj4000> so who knows where this code originates from
[11:57:13 EDT(-0400)] <Bosmon> Such as "inlineEdit-invitation"
[11:57:14 EDT(-0400)] <fj4000> yes
[11:57:24 EDT(-0400)] <Bosmon> I think it would be best to try to destroy it completely
[11:57:39 EDT(-0400)] <fj4000> and these names dont look like yui, very much, just the file structure
[11:57:42 EDT(-0400)] <Bosmon> Unless we want to demonstrate our seamless integration with a substandard cesspit of CSS malevolence (tongue)
[11:57:44 EDT(-0400)] <fj4000> i think your right
[11:58:12 EDT(-0400)] <fj4000> ok, so you recommend changing base.css?
[11:58:24 EDT(-0400)] <Bosmon> I recommend destroying it, if you think you can manage that in time
[11:58:33 EDT(-0400)] <fj4000> the entire file?!
[11:58:39 EDT(-0400)] <Bosmon> Yes
[11:58:46 EDT(-0400)] <fj4000> ...
[11:58:56 EDT(-0400)] <fj4000> that would destroy the layout of the page
[11:59:00 EDT(-0400)] <Bosmon> Would it
[11:59:25 EDT(-0400)] <Bosmon> I will bother Nico about it
[11:59:27 EDT(-0400)] <fj4000> i would only guess....maybe not...
[11:59:29 EDT(-0400)] <fj4000> CSS: Base Project: Sakai Foundation Developer: Deyan Todorov E-mail: office@websitebg.info
[11:59:29 EDT(-0400)] <Bosmon> See if we can find where it came frome
[11:59:42 EDT(-0400)] <Bosmon> This might be one Nathan's Hungarians
[11:59:42 EDT(-0400)] <fj4000> i must have missed this obviousness ^^
[11:59:56 EDT(-0400)] <fj4000> Deyan Todorov
[12:00:05 EDT(-0400)] <fj4000> seems to be the person of interest
[12:01:35 EDT(-0400)] <fj4000> Bosmon: so if I eliminate base.css, the page has almost no styling
[12:01:42 EDT(-0400)] <fj4000> kind of expected thiss
[12:01:49 EDT(-0400)] <Bosmon> OK
[12:01:52 EDT(-0400)] <Bosmon> I am talking to Nico
[12:02:01 EDT(-0400)] <Bosmon> He says it is one of Nathan's Hungarians
[12:02:06 EDT(-0400)] <Bosmon> These files are no longer used within the Sakai effort
[12:02:08 EDT(-0400)] <fj4000> cool, can I resolve the jira?
[12:02:12 EDT(-0400)] <fj4000> since you solved it
[12:02:15 EDT(-0400)] <Bosmon> And in fact, neither is this entire screen
[12:02:19 EDT(-0400)] <fj4000> lol
[12:02:21 EDT(-0400)] <fj4000> great
[12:02:30 EDT(-0400)] <Bosmon> It is their typical conservation of effort
[12:02:42 EDT(-0400)] <Bosmon> Well, ok, we have established that we have no "upstream responsibility" any more
[12:03:04 EDT(-0400)] <Bosmon> I am not sure exactly how best we should "firewall off" the cesspit
[12:03:20 EDT(-0400)] <fj4000> then is there an incentive to take your change and push it into the core css file?
[12:03:21 EDT(-0400)] <Bosmon> We should at least record the results of this discussion....
[12:03:25 EDT(-0400)] <fj4000> ok
[12:03:29 EDT(-0400)] <fj4000> im commenting the ticket now
[12:03:42 EDT(-0400)] <Bosmon> Politely (tongue)
[12:04:09 EDT(-0400)] <fj4000> done
[12:09:02 EDT(-0400)] <yura> Bosmon: could you please review my patch for FLUID-2637 http://issues.fluidproject.org/browse/FLUID-2637?
[12:10:14 EDT(-0400)] <Bosmon> yura, will do - thanks
[12:11:28 EDT(-0400)] <yura> Bosmon: thanks
[12:11:33 EDT(-0400)] <Bosmon> It looks pretty good - I like the idea of the isSortable utility function
[12:11:55 EDT(-0400)] <Bosmon> I am concerned overall about cost a little since "findColumnDef" is actually an O(thumbs down) function....
[12:12:23 EDT(-0400)] <Bosmon> So it might actually be faster overall with the current implementation to let the basicSorter determine the lack of sortability
[12:12:34 EDT(-0400)] <Bosmon> Although this isn't a completely clear issue - since it depends on knowing implementation details
[12:12:54 EDT(-0400)] <Bosmon> That is, it is not unreasonable that we may in the future have a faster implementation of findColumnDef
[12:14:10 EDT(-0400)] <Bosmon> The overall poor organisation of dependencies in this area is now being highlighted further by the fact that we need to pass the "overall that" into isSortable, and then hence into setModelSortHeaderClass
[12:14:17 EDT(-0400)] <yura> Bosmon: well basic sorter still calls findColumnDef ? in the case when we check isSortable first it makes it O(2n) which is still O(thumbs down) ?
[12:14:43 EDT(-0400)] <Bosmon> Well, it is still O(thumbs down) yes... we aren't changing the order, but we are just noting the fact we should minimise calls to this expensive operation (tongue)
[12:14:55 EDT(-0400)] <yura> Bosmon: agreed
[12:15:00 EDT(-0400)] <Bosmon> My best feeling is that we should accept this patch as it is....
[12:15:15 EDT(-0400)] <Bosmon> Since to solve the problem any better will require wide-scale reengineering
[12:15:23 EDT(-0400)] <Bosmon> This is the sort of mess that a lack of an IoC framework gets us into
[12:15:32 EDT(-0400)] <Bosmon> And it is very interesting to see these problems propagate (tongue)
[12:16:39 EDT(-0400)] <Bosmon> Were you on the Connect call where we were talking about the large-scale fate of the Pager?
[12:16:50 EDT(-0400)] <yura> Bosmon: yes
[12:17:04 EDT(-0400)] <Bosmon> The "columnDefs" structure is at the wrong level anyway....
[12:17:35 EDT(-0400)] <Bosmon> But even if it was put in a more appropriate place, it would still be an error to propagate top-level "that" components into so many utility functions
[12:17:52 EDT(-0400)] <Bosmon> But without a mechanism for "full Ioc" we have no sensible alternative
[12:17:57 EDT(-0400)] <yura> Bosmon: yes, that 's exactly the problem I had
[12:18:33 EDT(-0400)] <Bosmon> The Pager is really by far our most "structurally complex" component.... more so than the Reorderer
[12:18:43 EDT(-0400)] <Bosmon> And it is starting to show the strain in our framework facilities
[12:19:15 EDT(-0400)] <Bosmon> OK... well, thanks for this patch.... I will apply it now, and summarise with some comments
[12:19:53 EDT(-0400)] <yura> Bosmon: thank you
[12:22:35 EDT(-0400)] <anastasiac> Justin_o: FLUID-2478 is reviewed and commented on: +1
[12:22:54 EDT(-0400)] <Justin_o> anastasiac: thanks again
[12:24:30 EDT(-0400)] <yura> Justin_o: hey Justin, is this one already taken care of http://issues.fluidproject.org/browse/FLUID-2510 ?
[12:24:45 EDT(-0400)] <Justin_o> yura: i'll take a look
[12:25:32 EDT(-0400)] <Bosmon> yura - I think we can save on the dependency impact by passing only "columnDefs" to isSortable
[12:25:44 EDT(-0400)] <Bosmon> And actually this member is already present in the "nonce options structure" expOpts
[12:26:09 EDT(-0400)] <Bosmon> So we can conserve the original signature of setModelSortHeaderClass
[12:34:29 EDT(-0400)] <anastasiac> Justin_o: I'll review FLUID-2451 next
[12:34:48 EDT(-0400)] <yura> Bosmon: but fireModelChange doesnt have access to opts.columnDefs, yet it calls isSortable, I will have to then move it and call within that.options.sorter ?
[12:35:33 EDT(-0400)] <Bosmon> yura - fireModelChange has paid all the costs for access to the "overall that" - so it is reasonable for it to fish out the columnDefs object by itself
[12:35:35 EDT(-0400)] <Justin_o> yura: it looks like FLUID-2510 is working now
[12:36:07 EDT(-0400)] <Bosmon> It "looks bad" but fireModelChange is already "as bad as a function as it could be" (tongue)
[12:36:21 EDT(-0400)] <Bosmon> Whereas with this scheme we at least prevent further dependency leaks elsewhere
[12:36:36 EDT(-0400)] <Bosmon> All these sorts of policies will make the component easier to refactor later....
[12:37:25 EDT(-0400)] * jamon (i=jamon@mantis.openject.com) has joined #fluid-work
[12:38:32 EDT(-0400)] <laurel> colinclark: you asked me to msg you about this issue of splitting the UI Options cancel api http://issues.fluidproject.org/browse/FLUID-2760
[12:38:53 EDT(-0400)] <colinclark> laurel: Thanks.
[12:39:55 EDT(-0400)] <colinclark> laurel: Did you get the larger UI Options/Dialog issue fixed?
[12:40:31 EDT(-0400)] <fj4000> would anyone like to review my commit for 2356?
[12:41:15 EDT(-0400)] <anastasiac> Justin_o: I've reviewed and commented on FLUID-2451: +1
[12:41:43 EDT(-0400)] <Justin_o> thanks
[12:42:49 EDT(-0400)] <colinclark> JIRA is the worst!
[12:43:11 EDT(-0400)] <colinclark> I was just creating a new issue, and accidentally hit the Cmd-Back arrow, and lost all my data.
[12:43:19 EDT(-0400)] <colinclark> Arg!
[12:43:20 EDT(-0400)] <Bosmon> yura - to be clear - the basic design of the "sorter" API is also incorrect, so we cannot save this situation by very much (tongue)
[12:44:18 EDT(-0400)] <Bosmon> Generally the set of data requested by a "sorter" could not really have been anticipated so "to be safe" it was passed everything.... this is the basic contrast between what in other languages would be "interface-driven" and the IoC approach
[12:44:54 EDT(-0400)] <Bosmon> Without IoC you cannot be "aggressive" in allowing things to demand only what they need.... you have to be "conservative" and pass them anything they could conceivably want
[12:44:56 EDT(-0400)] <laurel> colinclark: you were in conference room when I ran into a problem so then I moved on to something else and have been distracted since. If you have a moment to look at something with me again, that would be great
[12:45:06 EDT(-0400)] <anastasiac> Justin_o: I'll review FLUID-1811 next
[12:45:13 EDT(-0400)] <colinclark> laurel: Can you describe it here?
[12:45:22 EDT(-0400)] <Bosmon> But hopefully we can stop this design mistake from getting worse at this stage, and make our work easier for future redesign
[12:45:32 EDT(-0400)] <Justin_o> anastasiac: you may want to check in with colinclark about that one
[12:45:42 EDT(-0400)] <colinclark> anastasiac: Leave that one for me.
[12:45:52 EDT(-0400)] <anastasiac> ah, ok - thanks for the pointer. It's all yours, colinclark
[12:45:57 EDT(-0400)] <yura> Bosmon: I ve refactored the isSortable so it only takes columnDefs not overallThat http://issues.fluidproject.org/browse/FLUID-2637
[12:45:59 EDT(-0400)] <colinclark> There is still some work needed there, which I will pick up for Eli while he's on holiday.
[12:46:13 EDT(-0400)] <anastasiac> should it be reopened?
[12:46:26 EDT(-0400)] <colinclark> anastasiac: Was it marked as resolved?
[12:46:30 EDT(-0400)] <anastasiac> yep
[12:46:33 EDT(-0400)] <colinclark> yearg
[12:46:36 EDT(-0400)] <Bosmon> yura - ok, that looks great now
[12:46:43 EDT(-0400)] <colinclark> Yes, I'll reopen it.
[12:47:16 EDT(-0400)] <yura> Bosmon: great, thanks
[12:48:12 EDT(-0400)] <laurel> sure. I moved the createDialog method into initUIOptions, but then I can see the dialog appear on page load and then suddenly hide - see http://www.fluidproject.org/ui-options/
[12:48:42 EDT(-0400)] <Bosmon> yura - but did you test it? (tongue)
[12:48:45 EDT(-0400)] <Bosmon> It doesn't seem to work for me...
[12:49:06 EDT(-0400)] <laurel> it didn't do that when the createDialog method was in the original position
[12:49:41 EDT(-0400)] <Bosmon> "isSortable" needs to be guarded... for the case there is no sort key
[12:49:48 EDT(-0400)] <Bosmon> The pager-site-setting sample blows up on startup....
[12:50:09 EDT(-0400)] <colinclark> laurel: Looking now
[12:51:40 EDT(-0400)] <Bosmon> At the moment you are "getting away" with the fact that this is the very last part of the onModelChange workflow..... but in fact there is an exception (tongue)
[12:55:02 EDT(-0400)] <colinclark> laurel: It's interesting that the Sakai UI Options example loads things lazily.
[12:55:11 EDT(-0400)] <colinclark> Thus avoiding this issue.
[12:57:04 EDT(-0400)] <colinclark> laurel: Couple of ideas...
[12:57:27 EDT(-0400)] <colinclark> Perhaps your #dialogContent container should be hidden to start.
[12:57:43 EDT(-0400)] <colinclark> Otherwise, it's something you'll have to play around with. Get to know how UI Dialog works a bit better.
[12:59:29 EDT(-0400)] <laurel> do you mean get to know how jQuery dialog works a bit better?
[12:59:46 EDT(-0400)] <laurel> and i'm not sure what you mean by loading lazily
[13:00:00 EDT(-0400)] <laurel> can you point me at code reference there
[13:01:13 EDT(-0400)] <colinclark> Justin_o: Here's the class name JIRA I just filed for you: http://issues.fluidproject.org/browse/FLUID-2765
[13:01:45 EDT(-0400)] <Justin_o> colinclark: thanks... added it to bug parade
[13:02:01 EDT(-0400)] <colinclark> laurel: Yeah, the Dialog is part of jQuery UI (as opposed to jQuery proper), so we often refer to things as UI [Widget]. So yes, I meant get to know the jQuery UI Dialog a bit better.
[13:02:59 EDT(-0400)] <colinclark> As for the lazy loading... take a look at how the Edit Appearance button is bound in sakai.js.
[13:04:02 EDT(-0400)] <yura> Bosmon: yes, I ve missed it , i just resubmitted the fix
[13:05:29 EDT(-0400)] <laurel> colinclark: sorry - still a little lost - the only thing I see different is that there is the if (!uiOptions) around the load. is that what I should be looking at - I've been wondering what that particular line means, so now might be a good time to learn.
[13:06:43 EDT(-0400)] <laurel> I'm thinking it means if uiOptions is not initialized then do the load...but I'm not sure why that would be tested or what the benefit is.
[13:07:40 EDT(-0400)] <anastasiac> Justin_o: I've resolved FLUID-2728.
[13:07:56 EDT(-0400)] <anastasiac> Waiting for an update to the bug parade to know what to do next
[13:07:57 EDT(-0400)] <Justin_o> anastasiac: thank you...
[13:08:13 EDT(-0400)] <Justin_o> anastasiac: sent it out already, you should probably see it coming along shortly
[13:09:19 EDT(-0400)] <Bosmon> Still a bit of redundancy left.... what do you mean by this line:
[13:09:22 EDT(-0400)] <Bosmon> return columnDef ? columnDef.sortable : columnDef;
[13:09:41 EDT(-0400)] <Bosmon> I think it would be more "meaningful" to write
[13:09:48 EDT(-0400)] <Bosmon> return columnDef ? columnDef.sortable : false;
[13:09:51 EDT(-0400)] <laurel> colinclark: also I have read the jquery ui dialog docs over several times and other than the autoLoad init option (which is set to false) I can't find anything that implies that the dialog should show when the page is loaded...so I think I'm not familiar enough with the terminology to know what I'm looking for.
[13:10:15 EDT(-0400)] <Bosmon> In general throughout Fluid we try not to depend unnecessarily on "falsity"
[13:10:43 EDT(-0400)] <Bosmon> Although clearly we are at the mercy of the person who puts a value in "columnDef.sortable"
[13:10:44 EDT(-0400)] <Bosmon> (tongue)
[13:14:02 EDT(-0400)] <anastasiac> Justin_o: I'll have a look at FLUID-2761 and 2762
[13:16:01 EDT(-0400)] <Justin_o> anastasiac: thanks
[13:23:35 EDT(-0400)] <colinclark> laurel: Yeah, that's the lazy loading I'm talking about. If you take a close look at that, you can see that they're not actually loading UI Options for the first time until the user actually wants it.
[13:24:29 EDT(-0400)] <colinclark> Including the dialog.
[13:24:40 EDT(-0400)] <colinclark> Which is one strategy for avoiding ficker.
[13:24:42 EDT(-0400)] <colinclark> flicker
[13:25:13 EDT(-0400)] <colinclark> Alternatively, as I mentioned before, it may have to do with the initial visibility of the element you are attaching the dialog to.
[13:25:54 EDT(-0400)] <colinclark> In general, this kind of flicker is pretty annoying, so my point was to try out the dialog in a simpler context and see if you can pin down the flicker issue.
[13:27:12 EDT(-0400)] <laurel> colinclark: does !uiOptions actually call fluid.uiOptions("#uiOptionsContainer", options); or does it just check if uiOptions is loaded?
[13:28:54 EDT(-0400)] <colinclark> So we're looking at this chunk of code: http://www.pastie.org/489157
[13:29:05 EDT(-0400)] <colinclark> This is just an ordinary if statement...
[13:29:35 EDT(-0400)] <colinclark> if (!uiOptions) says "If the variable called uiOptions is falsey, then run the code below."
[13:29:38 EDT(-0400)] <laurel> colinclark: I think my problem is that I'm trying to keep the code as close to the tutorial as possible while also making it work the way I think an implementor would expect
[13:30:24 EDT(-0400)] <laurel> although the sakai example is similar, it is different in enough places so as to confuse the issue.
[13:30:27 EDT(-0400)] <laurel> and me
[13:30:36 EDT(-0400)] <colinclark> laurel: yeah, we talked about this the other day, though... First step, get it working and understand how. Then you will have lots to offer back to the tutorial. Until you can get it working and now how it works, don't sweat the tutorial.
[13:31:01 EDT(-0400)] <laurel> i have it working, but it doesn't look good...totally different issue
[13:38:32 EDT(-0400)] <laurel> I'm now looking at code that looks like this: http://fluid.pastebin.com/m4c92d4fd - I still have the problem with the dialog close and recursion if I uncomment the close code block in setupDialog
[13:39:04 EDT(-0400)] <laurel> so I'm not sure what was different about this solution and the one in the tutorial.
[13:52:43 EDT(-0400)] <colinclark> laurel: You'll find the DOM Binder's implementation at line 158 in Fluid.js
[13:52:47 EDT(-0400)] <colinclark> Here's the documentation: http://wiki.fluidproject.org/display/fluid/DOM+Binder
[13:58:21 EDT(-0400)] <laurel> Hey Justin_o: I reviewed 2380 this morning.
[13:58:51 EDT(-0400)] <Justin_o> laurel: thanks
[14:13:49 EDT(-0400)] <Justin_o> colinclark, anastasiac, fj4000, Bosmon, and others: fj4000 and I just realized that the single css that is created by the build process doesn't take into account for references to images. This means that if it is used in place of the individual css files, you will not get the linked images. This is something we can try to devise a strategy for, but won't have time until 1.2 at the earliest. Anythoughts on whether we should pull the css concatenation
[14:14:16 EDT(-0400)] <Bosmon> I didn't realise we concatenated CSS also
[14:14:20 EDT(-0400)] <Bosmon> That seems a bit terrifyin
[14:14:22 EDT(-0400)] <Bosmon> g
[14:14:25 EDT(-0400)] <anastasiac> Justin_o: FLUID-2761 & 2762 reviewed, comments on FLUID-2762: +1 for this release, with a related feature request for the FSS, filed as FLUID-2766 (fj4000: hint, hint)
[14:15:04 EDT(-0400)] <Justin_o> Bosmon: it works well if you don't like looking at pictures (tongue)
[14:15:12 EDT(-0400)] <Justin_o> anastasiac: thanks for the reviews
[14:20:18 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined #fluid-work
[14:21:07 EDT(-0400)] <laurel> anyone reviewing FLUID-2356
[14:21:11 EDT(-0400)] <laurel> ?
[14:22:06 EDT(-0400)] <anastasiac> laurel: not me... go for it
[14:23:56 EDT(-0400)] <anastasiac> Justin_o: I reviewed FLUID-2478 earlier: +1 from me...
[14:24:37 EDT(-0400)] <anastasiac> Justin_o: I'll review FLUID-2458 next
[14:25:57 EDT(-0400)] <Justin_o> laurel, anastasiac thanks
[14:26:19 EDT(-0400)] <laurel> ok - i've got 2356
[14:28:32 EDT(-0400)] <colinclark> Justin_o: So, in short, concatenating our CSS files produces a single CSS file that doesn't actually work, yes?
[14:29:48 EDT(-0400)] <laurel> Justin_o: I think FLUID-2356 looks good. Checked in ie, ff and opera on winxp. Very small change in the fss code.
[14:30:02 EDT(-0400)] <Justin_o> laurel: thanks
[14:30:27 EDT(-0400)] <Justin_o> colinclark: it works for everything except those things that reference an image, for example the themes
[14:30:34 EDT(-0400)] <fj4000> anastasiac: a feature request, eh?
[14:31:44 EDT(-0400)] <colinclark> Justin_o: That sounds fairly broken, then.
[14:32:19 EDT(-0400)] <Justin_o> colinclark: i think so, i'm for removing it from the release
[14:32:41 EDT(-0400)] <Justin_o> i don't think it is something we can fix before 1.1 is released
[14:38:16 EDT(-0400)] <anastasiac> Justin_o: For FLUID-2458, to reproduce the issue: do I have to save and apply the change to high contrast before selecting another theme?
[14:39:30 EDT(-0400)] <Justin_o> anastasiac: For this one i don't think so, but for the related one FLUID-2500 you would
[14:39:38 EDT(-0400)] <anastasiac> k, thanks
[14:48:53 EDT(-0400)] <heidi_> fj4000 et all: FSS newbie question. i have a container with two columns, one fixed and one flex. does making the container an fl-col-mixed only make sense if the container itself is a column? or does it do something else?
[14:49:47 EDT(-0400)] <anastasiac> Justin_o: I've reviewed and commented on FLUID-2458: +1
[14:50:52 EDT(-0400)] <fj4000> fl-col-mixed-XXXX is probably what your looking for
[14:51:03 EDT(-0400)] <fj4000> the container wont be affected
[14:51:26 EDT(-0400)] <fj4000> only elements within in with the fl-col-fixed and the fl-col-flex class names will be affected
[14:51:39 EDT(-0400)] <fj4000> ....*within the container...
[14:52:53 EDT(-0400)] <heidi_> hmm..
[14:53:29 EDT(-0400)] <heidi_> am i right in thinking of a container as a non-floating box and cols as floatable boxes?
[14:54:25 EDT(-0400)] <fj4000> yup, pretty much
[14:54:39 EDT(-0400)] <fj4000> unless of course you wanted your container to do more (tongue)
[14:56:08 EDT(-0400)] <heidi_> right, so if i have a div that holds two columns, why would it be fl-col-mixed vs a regular container... ?
[14:56:46 EDT(-0400)] <heidi_> only needed if it will be a column?
[14:57:21 EDT(-0400)] <heidi_> or both?
[14:58:23 EDT(-0400)] <heidi_> in one example it has <div class="fl-container-flex fl-col-flex5 fl-fix content"> ... is there a significance i'm missing in having it use container-flex as well as col-flex ?
[15:00:28 EDT(-0400)] <anastasiac> Justin_o: I've fixed and committed FLUID-2765. Needs review now.
[15:00:59 EDT(-0400)] <heidi_> that particular example is for a container with 5 columns within it. but i've been reading that fl-col-flex makes an actual column. is the difference that it says col-flex5... which is a holder vs col-flex which is a column?
[15:12:08 EDT(-0400)] <colinclark> michelled: New patch here: http://issues.fluidproject.org/browse/FLUID-2743
[15:12:11 EDT(-0400)] <colinclark> Can you review?
[15:12:21 EDT(-0400)] <michelled> sure
[15:13:00 EDT(-0400)] <fj4000> heidi_: i think that's a little mixed up
[15:13:29 EDT(-0400)] <fj4000> actually, my mistake, i read that wrong
[15:14:25 EDT(-0400)] <fj4000> in the above case, fl-container-flex forces the element to have a flexible width, but fl-col-flex5 wont affect the element directly
[15:14:27 EDT(-0400)] <heidi_> fj4000: in short, just trying to clarify column vs container. some of these examples are confusing me using both, with different variations...
[15:14:42 EDT(-0400)] <fj4000> there is a very subtle difference
[15:14:57 EDT(-0400)] <laurel> colinclark: I'm still struggling with that UIOptions code...new problem. Have time or shall I hold until tomorrow
[15:15:05 EDT(-0400)] <heidi_> what does fl-col-flex5 do?
[15:15:10 EDT(-0400)] <colinclark> anastasiac: I just took a quick look at your FLUID-2765 commit.
[15:15:24 EDT(-0400)] <fj4000> fl-col-flex5 means
[15:15:25 EDT(-0400)] <colinclark> We're missing backwards compatibility here, at least in ProgressiveEnhancement.js
[15:15:44 EDT(-0400)] <colinclark> laurel: Tomorrow might be best. Trying to push through on my last bug parade tasks.
[15:15:46 EDT(-0400)] <fj4000> any sub element with "fl-col" class name will be 1/5 the width of the container
[15:15:56 EDT(-0400)] <heidi_> ah ha
[15:16:00 EDT(-0400)] <laurel> thx colin. I'll chat tomorrow then
[15:16:07 EDT(-0400)] <colinclark> sounds good
[15:16:15 EDT(-0400)] <fj4000> fl-col-flex2 means all fl-col children will be 1/2
[15:16:33 EDT(-0400)] <anastasiac> colinclark, obviously I wasn't (and am still not) clear on what the bug is, based on the description on the JIRA
[15:16:33 EDT(-0400)] <fj4000> containers, on the other hand
[15:16:43 EDT(-0400)] <fj4000> are completely arbitrary
[15:16:45 EDT(-0400)] <colinclark> anastasiac: Yack, I'm confused?
[15:16:50 EDT(-0400)] <heidi_> i printed out the fss API on the wiki
[15:16:51 EDT(-0400)] <fj4000> and dont have a pattern
[15:16:53 EDT(-0400)] <colinclark> You weren't clear on the bug, but you committed against it?
[15:17:03 EDT(-0400)] <anastasiac> I thought I was clear on it
[15:17:06 EDT(-0400)] <colinclark> (tongue)
[15:17:06 EDT(-0400)] <colinclark> Aha
[15:17:10 EDT(-0400)] <anastasiac> based on your comment, I apparently was wrong
[15:17:10 EDT(-0400)] <fj4000> heidi_ is it out of date?
[15:17:28 EDT(-0400)] <anastasiac> can you clarify, colinclark?
[15:17:46 EDT(-0400)] <colinclark> anastasiac: So this one is an API change...
[15:18:01 EDT(-0400)] <heidi_> fj4000: don't think so. just taking me awhile to get it i guess.
[15:18:05 EDT(-0400)] <colinclark> wherever we can, we try to provide backwards compatibility in these cases.
[15:18:20 EDT(-0400)] <fj4000> if you find something out of sync with the docs, pls let me know
[15:18:25 EDT(-0400)] <fj4000> im re-doing some of them anyway
[15:18:29 EDT(-0400)] <colinclark> So the class is accidentally named fl-ProgEnhance-basic, but should be called fl-progEnhance-basic.
[15:18:50 EDT(-0400)] <colinclark> So in ProgressiveEnhancement.js, we'd want to ensure that the code works with both class names.
[15:19:05 EDT(-0400)] <colinclark> With a clear indication that the upper-cased version is deprecated and should not be used.
[15:19:29 EDT(-0400)] <anastasiac> ah, right! ok, sorry about that...
[15:19:33 EDT(-0400)] <anastasiac> I've reopened the JIRA
[15:19:58 EDT(-0400)] <heidi_> fj4000: i think i'm having trouble establishing the order of things... maybe there would be a better way of organising parenty vs. childy classes but i'm hesitant to suggest much at this point.
[15:19:59 EDT(-0400)] <anastasiac> good thing we've got code reviews...
[15:20:02 EDT(-0400)] <colinclark> anastasiac: Similarly, we'd have to duplicate the CSS declarations in the layout.css file.
[15:20:26 EDT(-0400)] <colinclark> anastasiac: fj4000 mentioned to me that he has a section in the FSS files specifically for deprecated declarations.
[15:20:27 EDT(-0400)] <anastasiac> yes, exactly
[15:20:34 EDT(-0400)] <anastasiac> ah, good to know
[15:20:34 EDT(-0400)] <fj4000> i think your right
[15:20:35 EDT(-0400)] <colinclark> anastasiac: Thanks, dude.
[15:20:44 EDT(-0400)] <anastasiac> thank you
[15:20:49 EDT(-0400)] <fj4000> its not too clear from the current state of things
[15:21:06 EDT(-0400)] <heidi_> what you just told me here really helped clarify. it'd be nice if that was somewhere in these docs... i.e. "any sub element with "fl-col" class name will be 1/5 the width of the container"
[15:21:18 EDT(-0400)] <fj4000> colinclark: not a specific place per se
[15:21:20 EDT(-0400)] <heidi_> with the flex5 thing in the parent
[15:21:26 EDT(-0400)] <fj4000> just a method to deal with them
[15:21:41 EDT(-0400)] <fj4000> heidi_ yes, your right
[15:21:58 EDT(-0400)] <fj4000> have you seen the tutorials?
[15:22:05 EDT(-0400)] <heidi_> yep
[15:22:06 EDT(-0400)] <fj4000> im wondering if their unclear too
[15:22:14 EDT(-0400)] <heidi_> they are helping me puzzle out the api
[15:23:09 EDT(-0400)] <fj4000> cool
[15:23:12 EDT(-0400)] <heidi_> i think when i see fl-col i think "ok this is a column" vs. a column-holder
[15:23:31 EDT(-0400)] <heidi_> and when i see container, i think "this is where all the holder stuff is"
[15:23:38 EDT(-0400)] <fj4000> yup fl-col IS the column
[15:23:51 EDT(-0400)] <heidi_> i mean the fl-col prefix
[15:23:52 EDT(-0400)] <fj4000> its parent defines how that column will behave
[15:24:02 EDT(-0400)] <fj4000> ok
[15:25:11 EDT(-0400)] <heidi_> part of the learning process... will think more about how that can be clarified... maybe a little pre-API blurb
[15:25:22 EDT(-0400)] <heidi_> "fl-container is for ..."
[15:25:26 EDT(-0400)] <fj4000> thank you
[15:25:27 EDT(-0400)] <heidi_> "fl-col is for"
[15:26:43 EDT(-0400)] <heidi_> to give a bit more context before diving into each class? i dunno.
[15:26:49 EDT(-0400)] <heidi_> thanks (smile)
[15:38:25 EDT(-0400)] <anastasiac> ok, Justin_o (and colinclark): I've resolved FLUID-2765 again, this time with backward compatibility. Really needs review (smile)
[15:38:58 EDT(-0400)] <Justin_o> anastasiac: thank you
[15:45:00 EDT(-0400)] <colinclark> anastasiac: I'll take a look shortly
[15:53:25 EDT(-0400)] <yura> hey Justin_o would you mind if I bug you for a minute in regards to one jira im working on?
[15:55:58 EDT(-0400)] <yura> Bosmon: you have mentioned earlier you were going take a look at 2374, I was looking at it right now and I have a minor question about it
[15:57:01 EDT(-0400)] <Justin_o> yura: sure
[15:57:21 EDT(-0400)] <yura> it's actually the question about jira I mentioned above to Bosmon
[15:57:41 EDT(-0400)] <Bosmon> Ah yes
[15:57:59 EDT(-0400)] <Bosmon> This is an issue which I think probably needs to be fixed in DataBinding.js
[15:58:07 EDT(-0400)] <Justin_o> yura: I'll leave it to Bosmon then (smile)
[15:58:10 EDT(-0400)] <Bosmon> At least, I think that is the place the listeners are registered
[15:58:16 EDT(-0400)] <yura> Justin_o: ok (smile)
[15:59:03 EDT(-0400)] <yura> Bosmon: i was wondering then if enter key was disabled intentionally in this piece of code:
[15:59:04 EDT(-0400)] <yura> textfield.keypress(function (evt) {
[15:59:04 EDT(-0400)] <yura> if (evt.keyCode !== $.ui.keyCode.ENTER) {
[15:59:04 EDT(-0400)] <yura> return true;
[15:59:04 EDT(-0400)] <yura> }
[15:59:04 EDT(-0400)] <yura> return false;
[15:59:06 EDT(-0400)] <yura> });
[15:59:25 EDT(-0400)] <Bosmon> Ah
[15:59:28 EDT(-0400)] <Bosmon> That is quite interesting
[15:59:31 EDT(-0400)] <Bosmon> WHich file is that code in?
[15:59:42 EDT(-0400)] <Bosmon> Looks like it must be in UIOptions itself
[15:59:53 EDT(-0400)] <yura> uiOptions.js
[15:59:57 EDT(-0400)] <Bosmon> Ah
[16:00:03 EDT(-0400)] <yura> lines 50-55
[16:00:10 EDT(-0400)] <Bosmon> In that case you might well ask michelled what it is doing (tongue)
[16:00:46 EDT(-0400)] <yura> Bosmon: ok, will do
[16:01:01 EDT(-0400)] <yura> hi michelled, do you have a minute?
[16:02:04 EDT(-0400)] <Bosmon> The effect may be simply to try to defeat the "default form submission effect"
[16:02:13 EDT(-0400)] <Bosmon> Which might cause a navigation away from the overall page if actioned...
[16:02:59 EDT(-0400)] <yura> Bosmon: yes, I was thinking that that could be the problem, I was looking for a similar jira that requested that, with no luck though
[16:03:40 EDT(-0400)] <Bosmon> http://docs.jquery.com/Events/bind#typedatafn
[16:03:54 EDT(-0400)] <Bosmon> From this documentation, it suggests that the behaviour there is "too fierce" and needs to be moderated
[16:04:03 EDT(-0400)] <Bosmon> "The event handler is passed an event object that you can use to prevent default behaviour. To stop both default action and event bubbling, your handler has to return false."
[16:04:16 EDT(-0400)] <Bosmon> All we truly want to prevent is default action = form submission
[16:04:29 EDT(-0400)] <Bosmon> So rather than return false, this code needs to be modified to call evt.preventDefault() merely
[16:04:44 EDT(-0400)] <Bosmon> That will not solve the problem by itself, but is essential to allow further processing of the event
[16:08:33 EDT(-0400)] <michelled> hi yura, I'm here now
[16:11:35 EDT(-0400)] <yura> oh hi michelled, Bosmon and I were just talking about UIoptions jira 2374
[16:12:59 EDT(-0400)] <michelled> ah yes. I think there was a quick hack put in at some point to stop the default form submission problem.
[16:14:14 EDT(-0400)] <yura> oh ok , then Bosmon suggested returning evt.preventDefault() instead of false
[16:14:40 EDT(-0400)] <yura> yet, this still doesn't make the enter key work
[16:15:05 EDT(-0400)] <Bosmon> That is correct
[16:15:14 EDT(-0400)] <Bosmon> We now need to write a further handler for the key elsewhere (tongue)
[16:15:37 EDT(-0400)] <michelled> or we could kick of the 'change' ourselves
[16:16:30 EDT(-0400)] <Bosmon> As I explained above, this change is just the starting point for a fix
[16:17:01 EDT(-0400)] <Bosmon> michelled: This corresponds to generally useful functionality, and so should be dealt with within the framework
[16:18:05 EDT(-0400)] <michelled> sounds like a good idea - what were you thinking?
[16:18:13 EDT(-0400)] <Bosmon> So, the fix needs to go in the same place I modified for the textarea handler
[16:18:33 EDT(-0400)] <michelled> is this in Fluid.js?
[16:18:39 EDT(-0400)] * michelled has been away
[16:19:36 EDT(-0400)] <Bosmon> For the last 3 months? (tongue)
[16:20:16 EDT(-0400)] <michelled> it certainly feels that way (tongue)
[16:20:40 EDT(-0400)] <Bosmon> Actually, "applyAutoBind" is at fluidRenderer, line 517
[16:20:52 EDT(-0400)] <Bosmon> Thinking about this more closely, this is probably something that ought to be in DataBinding.js
[16:21:21 EDT(-0400)] <Bosmon> But we would need to get our thinking caps on in order to put it there....
[16:21:45 EDT(-0400)] <Bosmon> SInce its natural "effect" is expressed in terms of renderer decorators, which would make no sense in DataBinding.js
[16:22:07 EDT(-0400)] <Bosmon> We can think about that issue later (tongue)
[16:22:13 EDT(-0400)] <Bosmon> In the meantime, we need to emit another listener there
[16:22:52 EDT(-0400)] <Bosmon> michelled: SHouldn't hitting "enter" have some other "natural effect" like committing the corrent set of changes?
[16:22:56 EDT(-0400)] <Bosmon> current
[16:23:29 EDT(-0400)] <michelled> yes, I think that's what the JIRA issue was about.
[16:24:40 EDT(-0400)] <Bosmon> ok
[16:25:03 EDT(-0400)] <Bosmon> Well, perhaps the "manual firing change" strategy is not so far off then
[16:25:20 EDT(-0400)] <Bosmon> After all, there is no other way to be sure of ordering, if the effect of a listener might be to destroy the entire block of markup
[16:28:35 EDT(-0400)] <heidi_> fj4000: can i bug you again?
[16:28:49 EDT(-0400)] <fj4000> fire away
[16:29:13 EDT(-0400)] <heidi_> k, i have a div with two columns. i want the first one to be 150px wide and the second one to be flexible
[16:29:20 EDT(-0400)] <heidi_> how might i do this?
[16:29:50 EDT(-0400)] <heidi_> i have the containing div using "fl-col-mixed2"
[16:30:14 EDT(-0400)] <michelled> yura, Bosmon: I have to leave soon for an appointment. Please send me an e-mail message if you need me to look at a patch tonight
[16:30:21 EDT(-0400)] <heidi_> i want the first one to be fl-col-fixed ? (how to specify width) and the second one as fl-col-flex.... that right?
[16:30:22 EDT(-0400)] <fj4000> heidi_ your right
[16:30:44 EDT(-0400)] <fj4000> so, lets just say the columns can float to the left
[16:30:58 EDT(-0400)] <fj4000> then: fl-col-mixed on the container
[16:31:03 EDT(-0400)] <fj4000> actually
[16:31:33 EDT(-0400)] <fj4000> fl-col-mixed-150
[16:31:49 EDT(-0400)] <fj4000> on the container, as well as fl-force-left
[16:31:49 EDT(-0400)] <heidi_> hmm..
[16:32:09 EDT(-0400)] <fj4000> and then the fixed width column would have fl-col-fixed
[16:32:19 EDT(-0400)] <fj4000> and the flexible one would have fl-col-flex
[16:32:32 EDT(-0400)] <fj4000> sound reasonable?
[16:32:42 EDT(-0400)] <fj4000> brb
[16:33:17 EDT(-0400)] <heidi_> okay. and if i wanted to specify the widths of both?
[16:36:18 EDT(-0400)] <heidi_> btw, doing what you said sets the widths right but doesn't float the second column to the right of the first... something extra needed?
[16:38:51 EDT(-0400)] <heidi_> figured it out: fl-force-left needs to be on the first column (so fl-force-left == float:left ?)
[16:39:44 EDT(-0400)] <heidi_> i would think columns naturally float?
[16:44:01 EDT(-0400)] <fj4000> heidi_: columns float naturally to the left, yes
[16:44:16 EDT(-0400)] <Justin_o> Bosmon: are you around?
[16:44:18 EDT(-0400)] <fj4000> and these should probably too as well
[16:44:27 EDT(-0400)] <heidi_> any guess as to why i need fl-force-left on the first column
[16:44:33 EDT(-0400)] <fj4000> yup
[16:44:36 EDT(-0400)] <fj4000> the thing is
[16:44:51 EDT(-0400)] <Bosmon> Yes
[16:44:55 EDT(-0400)] <fj4000> when ppl want to customize how the floating should happen
[16:45:12 EDT(-0400)] <Justin_o> Bosmon: just wondering which issues you have committed against for yura
[16:45:34 EDT(-0400)] <fj4000> its easier to tell them to change a class name and a css rule than two css rules, i think
[16:45:34 EDT(-0400)] <fj4000> maybe im wrong on that
[16:45:41 EDT(-0400)] <Bosmon> I just committed against FLUID-2637
[16:45:51 EDT(-0400)] <Justin_o> Bosmon: thanks
[16:46:27 EDT(-0400)] <heidi_> not sure i follow: i was expecting that with two columns, the first one set to fixed, they would still behave the same as before but with the first one the size i want it.
[16:47:09 EDT(-0400)] <heidi_> ie. floating stays as i didn't do anything to take it away and it's a natural property of columns
[16:48:01 EDT(-0400)] <heidi_> not sure what you mean by changing two css rules
[16:51:03 EDT(-0400)] <heidi_> on top of that, i was hoping to use the reorderer so i could drag the fixed box to the left or right... not sure if that force-left will interfere.
[16:53:23 EDT(-0400)] * davetrey (n=davetrey@106.pool85-50-201.dynamic.orange.es) has joined #fluid-work
[17:05:01 EDT(-0400)] <Justin_o> yura: are you still here?
[17:07:45 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has left #fluid-work
[17:15:45 EDT(-0400)] <fj4000> heidi_ : no, your right - it should have behaved like you said
[17:16:28 EDT(-0400)] <fj4000> also, for the reorderer, i think it should work - i experimented with multiple mixed column setups and it seemed to work
[17:39:06 EDT(-0400)] <heidi_> fj4000: ok cool
[19:33:25 EDT(-0400)] * alisonbenjamin (n=alisonbe@dsl-207-112-70-137.tor.primus.ca) has joined #fluid-work
[19:53:28 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176393934.dsl.bell.ca) has joined #fluid-work
[23:17:26 EDT(-0400)] * yura (n=yura@bas3-toronto06-1177890404.dsl.bell.ca) has joined #fluid-work