fluid-work IRC Logs-2009-05-26

Owned by Fluid IRC Log Bot
Last updated: May 26, 2009Version comment
27 min read

[03:29:02 EDT(-0400)] * davetrey (n=davetrey@106.pool85-50-201.dynamic.orange.es) has joined #fluid-work
[04:47:56 EDT(-0400)] * davetrey (n=davetrey@73-35-245.uoc.es) has joined #fluid-work
[06:17:57 EDT(-0400)] * davetrey (n=davetrey@213.73.35.245) has joined #fluid-work
[07:02:38 EDT(-0400)] * dtrelles (n=davetrey@73-35-245.uoc.es) has joined #fluid-work
[07:49:51 EDT(-0400)] * heidi (n=thesumme@bas5-oshawa95-1176469582.dsl.bell.ca) has joined #fluid-work
[08:30:16 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:32:59 EDT(-0400)] * jsilvaa (n=jsilva@142.150.82.73) has joined #fluid-work
[08:51:27 EDT(-0400)] * Topic is 'Bug Parade extended until end of day May 26 (http://issues.fluidproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=10129)' set by Justin_o on 2009-05-26 08:51:27 EDT(-0400)
[09:07:21 EDT(-0400)] * yura (n=yura@142.150.82.64) has joined #fluid-work
[09:08:35 EDT(-0400)] <Justin_o> yura: Hello, I had to re-open FLUID-2637. I left a comment on the jira.
[09:08:49 EDT(-0400)] <yura> hi Justin_o, i m reading it right now
[09:09:03 EDT(-0400)] <Justin_o> thanks... let me know if you have any questions
[09:16:08 EDT(-0400)] <yura> Justin_o: as far as I see every time you click on any header it jumps to a first page, is that a bug?
[09:17:37 EDT(-0400)] <Justin_o> yura: hi... no... it should be part of the sort function. basically if you change the sort, it should return you to the first page. If a header isn't sortable, clicking it shouldn't have an effect
[09:18:09 EDT(-0400)] * davetrey (n=davetrey@73-35-245.uoc.es) has joined #fluid-work
[09:18:11 EDT(-0400)] <heidi> what's the url to the 9.30 breeze meeting?
[09:18:32 EDT(-0400)] <yura> Justin_o: oh ok , so i think this is the problem , because I think it doesnt resort it afterwards
[09:18:50 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined #fluid-work
[09:19:20 EDT(-0400)] <Justin_o> heidi: I think it will be here http://connect.yorku.ca/fluidwork
[09:19:39 EDT(-0400)] <heidi> Justin_o: thanks!
[09:20:11 EDT(-0400)] <Justin_o> yura: yes... it seems to be doing two things, 1) returning it to the first page, 2) changing it to the default sort order. If you change the sort order by a sortable column and then click on the non-sortable header, the order will change.
[09:20:15 EDT(-0400)] <Justin_o> heidi: np
[09:20:56 EDT(-0400)] <yura> Justin_o: yes you're right
[09:22:53 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:23:03 EDT(-0400)] <Justin_o> yura: we've extended bug parade till the end of today, so if you have time today to work on this, you should be able to get it in before code freeze
[09:23:26 EDT(-0400)] <yura> Justin_o: yes, for sure
[09:24:08 EDT(-0400)] <Justin_o> yura: thanks
[09:32:33 EDT(-0400)] * laurelw (n=laurel@64.56.228.109) has joined #fluid-work
[09:34:09 EDT(-0400)] * laurel (n=laurel@64.56.228.109) has joined #fluid-work
[09:48:07 EDT(-0400)] * yura (n=yura@142.150.82.64) has joined #fluid-work
[09:55:40 EDT(-0400)] * dtrelles (n=davetrey@73-32-144.uoc.es) has joined #fluid-work
[09:57:06 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:00:21 EDT(-0400)] * jessm (n=Jess@c-71-232-1-65.hsd1.ma.comcast.net) has joined #fluid-work
[10:11:09 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176393934.dsl.bell.ca) has joined #fluid-work
[10:41:10 EDT(-0400)] <laurel> colinclark: I'm going to have to do this very asynchronously, but do you have time today for some consultation?
[10:41:13 EDT(-0400)] <laurel> http://www.fluidproject.org/ui-options/
[10:41:35 EDT(-0400)] <laurel> the cancel and save boxes work but only once and then not the second, third, etc times
[10:42:11 EDT(-0400)] <laurel> you can see the script in firebug - ui-options.js
[10:56:14 EDT(-0400)] * alisonbenjamin (n=alisonbe@142.150.154.101) has joined #fluid-work
[10:58:40 EDT(-0400)] <laurel> implies to me that the binding of the close to the cancel and save buttons is happening at the wrong time/place, but I'm not sure why the place I have chosen in the code is wrong.
[11:00:16 EDT(-0400)] <laurel> if anyone else with javascript knowledge wants to help me solve this problem, please feel free. I'm sure colinclark is stretched thinly as usual.
[11:00:18 EDT(-0400)] <colinclark> laurel: So how come you have lines 61-63 commented out?
[11:01:06 EDT(-0400)] <laurel> random attempt to see if that code was the issue - it was the same with it not commented out.
[11:02:13 EDT(-0400)] <colinclark> laurel: Where is this uiOptionsDialog variable in scope?
[11:02:27 EDT(-0400)] <colinclark> I'm having trouble reading your code because of the tabbing.
[11:02:49 EDT(-0400)] <colinclark> I guess it's visible within all of setupDialog()
[11:03:52 EDT(-0400)] <colinclark> laurel: Aha, yes.
[11:04:07 EDT(-0400)] <colinclark> Did you try using the debugger?
[11:04:17 EDT(-0400)] <colinclark> You can very clearly see that your handlers are only getting hit the first time around.
[11:04:54 EDT(-0400)] <colinclark> I wonder if perhaps the markup for UI Options gets destroyed at some point, then re-rendered, thus causing your handlers to disappear.
[11:05:42 EDT(-0400)] <laurel> i did try using the debugger and did see what you are describing. but didn't know what next steps to take.
[11:07:00 EDT(-0400)] <colinclark> Well, it sure looks to me like we're losing the elements you bound your events to.
[11:07:15 EDT(-0400)] <colinclark> We might argue that UI Options is being pretty heavy-handed with its markup...
[11:07:29 EDT(-0400)] <laurel> how would i determine if the "markup for UI Options gets destroyed" and re-rendered
[11:07:40 EDT(-0400)] <laurel> is it a theory or can I confirm it somehow?
[11:07:43 EDT(-0400)] <colinclark> laurel: You'd probably go look at the code for UI Options.
[11:07:54 EDT(-0400)] <colinclark> It's entirely a theory, but it's easily proven by reading some code.
[11:08:05 EDT(-0400)] <colinclark> Or you might just go ahead and try Michelle's alternative approach to the whole solution...
[11:08:14 EDT(-0400)] <colinclark> and that was to simply add an extra class to the close box.
[11:08:24 EDT(-0400)] <laurel> i will do that at some point, but agree with you about that happening
[11:08:29 EDT(-0400)] <colinclark> So her idea was actually to turn the close box into a cancel button.
[11:08:51 EDT(-0400)] <laurel> ah ha
[11:08:54 EDT(-0400)] <colinclark> By simply applying the correct flc- selector class name to the button.
[11:09:20 EDT(-0400)] <laurel> doesn't that imply some inside knowledge?
[11:09:34 EDT(-0400)] <colinclark> So in that case, you wouldn't need the code in lines 61-63, but you would bring back lines 35-40.
[11:09:52 EDT(-0400)] <colinclark> Selectors are entirely public knowledge, right. The point is that they are yours do what you will with, as the application developer.
[11:10:02 EDT(-0400)] <colinclark> Again, it's a workaround, but quite a decent one.
[11:11:55 EDT(-0400)] <laurel> i didn't think the fact that the selector existed was private. more that the fact that using that particular selector name would "make it a cancel button" doesn't seem obvious to me.
[11:12:24 EDT(-0400)] <laurel> perhaps I missed something in the description of the use of those selectors within the framework
[11:12:54 EDT(-0400)] <colinclark> The whole point of component selectors, as you probably read in the DOM Binder documentation, is that they identify "interesting things" within the DOM.
[11:13:02 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined #fluid-work
[11:13:11 EDT(-0400)] <colinclark> So you can mark things as being of interest to the component by assigning flc- class names to them.
[11:13:26 EDT(-0400)] <colinclark> Again, it's a bit of a workaround.
[11:13:30 EDT(-0400)] <laurel> yes, i understand that part of the concept
[11:13:37 EDT(-0400)] <laurel> i'm liking it.
[11:14:21 EDT(-0400)] <laurel> just want to make sure I understand as much as possible so that when I go to write about it, I can communicate the ideas well
[11:14:37 EDT(-0400)] <colinclark> sure
[11:14:40 EDT(-0400)] <laurel> thanks for taking the time.
[11:14:58 EDT(-0400)] <colinclark> michelled: Have you thought at all about the idea of breaking out a separate public method for blasting UI Options state? It feels slightly weird.
[11:16:18 EDT(-0400)] <colinclark> Otherwise, I guess backwash protection of some sort is in order.
[11:17:07 EDT(-0400)] <michelled> colinclark: what do you mean by 'blasting state'. resetting?
[11:17:12 EDT(-0400)] <colinclark> yeah
[11:17:29 EDT(-0400)] <colinclark> I mean, there must be a reason we call .cancel() when closing the dialog.
[11:18:18 EDT(-0400)] <colinclark> I guess you could probably successfully argue that the "make the close button a cancel button" approach is perfectly reasonable and not a workaround at all.
[11:18:36 EDT(-0400)] <colinclark> I just wonder.
[11:18:45 EDT(-0400)] <michelled> ya, that's what I was thinking. The action of closing without saving is cancelling
[11:19:39 EDT(-0400)] <michelled> but the language around 'reset' and 'cancel' in UIOptions is a bit confusing. I wonder if this is really a language problem.
[11:20:11 EDT(-0400)] <colinclark> I'd also argue that a close button probably isn't an appropriate affordance for a modal dialog.
[11:20:18 EDT(-0400)] <colinclark> Which makes this whole issue moot, in some sense.
[11:29:36 EDT(-0400)] <Bosmon> Yes
[11:29:44 EDT(-0400)] <Bosmon> I'm still not sure I understand what "cancelling" was meant to achieve
[11:29:49 EDT(-0400)] <Bosmon> Also, "reset"
[11:29:54 EDT(-0400)] <Bosmon> But, I made a JIRA to this effect (tongue)
[11:30:47 EDT(-0400)] <colinclark> So laurel, it seems pretty clear that michelled's solution is a pretty compelling option.
[11:31:12 EDT(-0400)] <colinclark> I'd also consider the possibility of just advising our users in the tutorial to not use a close box when creating a modal dialog.
[11:31:37 EDT(-0400)] <colinclark> I am curious, michelled, about what the lifecycle of the markup is in UI Options.
[11:31:56 EDT(-0400)] <laurel> michelled, colinclark: I like the idea but not sure how one implements this...how do you add a selector to a button. and can't find anything in the jquery dialog info about how to leave the "close" off the dialog
[11:32:16 EDT(-0400)] <colinclark> laurel: It's in the options there somewhere.
[11:32:33 EDT(-0400)] <colinclark> As for adding a class name to it... just go do the DOM and add the class name. (wink)
[11:34:43 EDT(-0400)] <michelled> colinclark: the component is rendered as part of the creation process. then both 'reset' and 'cancel' rerender it.
[11:34:54 EDT(-0400)] <colinclark> how come?
[11:35:40 EDT(-0400)] <michelled> because they change the model - reset reverts back to the integrator defaults and cancel reverts to the last saved settings
[11:36:41 EDT(-0400)] <colinclark> Is there any public API that "outsiders" can use to bind events more stably to things inside a rendered UI?
[11:37:15 EDT(-0400)] <colinclark> So this scenario will inevitably baffle our users, who may just want to decorate a few event handlers onto some of the markup, without knowing about how it's rendered, etc.
[11:37:17 EDT(-0400)] <Bosmon> ?
[11:37:32 EDT(-0400)] <Bosmon> Well, we can always create a kind of "evolute"
[11:37:36 EDT(-0400)] <michelled> yes, it is a problem
[11:37:41 EDT(-0400)] <Bosmon> A data structure which transports thinly disguised decorators
[11:37:54 EDT(-0400)] <colinclark> Yeah, but it's still a real drag to have to provide some proprietary API for doing this.
[11:38:25 EDT(-0400)] <colinclark> Users will expect just to be able to bind some handlers.
[11:38:30 EDT(-0400)] <colinclark> But then they find that they disappear.
[11:38:57 EDT(-0400)] <michelled> yes
[11:42:06 EDT(-0400)] <michelled> the 'afterRender' event was added to try to address this problem but it is less then perfect.
[11:42:09 EDT(-0400)] <Justin_o> fj4000: just to let you know, I've reopened FLUID-2762
[11:42:28 EDT(-0400)] <yura> Justin_o: do you have a minute?
[11:42:35 EDT(-0400)] <fj4000> ok
[11:42:38 EDT(-0400)] <fj4000> i can add those
[11:42:42 EDT(-0400)] * elicochran (n=elicochr@dhcp-169-229-212-59.LIPS.Berkeley.EDU) has joined #fluid-work
[11:42:56 EDT(-0400)] <Justin_o> fj4000: thanks
[11:43:38 EDT(-0400)] <Bosmon> A data structure within thinly disguised decorators is hardly a "drag of a proprietary API" (tongue)
[11:43:56 EDT(-0400)] <Bosmon> I was just thinking downstairs as I was getting my coffee about how incredibly cool this all was
[11:44:04 EDT(-0400)] <Bosmon> Your reaction isn't quite what I expected (tongue)
[11:44:05 EDT(-0400)] <laurel> colinclark: i think the only way to hide the close using jQuery UI .dialog is with css
[11:45:49 EDT(-0400)] <laurel> i see that there is a modaldialog plugin, but that wasn't what was used in the tutorial.
[11:47:14 EDT(-0400)] <colinclark> Bosmon: I'm sorry. I guess my point is just that some people won't need or want to be aware of how UI Option's markup is sourced.
[11:47:21 EDT(-0400)] <Bosmon> colinclark: Exactly
[11:47:28 EDT(-0400)] <colinclark> And they will probably assume that a call to jQuery.click() or whatever will just work
[11:47:34 EDT(-0400)] <colinclark> And in many of our components, it totally will.
[11:47:47 EDT(-0400)] <colinclark> But now we're saying, use this thing that you know.
[11:48:52 EDT(-0400)] <michelled> laurel: you can change the tutorial if it makes sense. I only wrote a draft based on the sakai example. it's certainly not meant to be in stone.
[11:49:07 EDT(-0400)] <Bosmon> Well.... this issue came up in DataBinding.js too
[11:49:24 EDT(-0400)] <Bosmon> I am thinking there is actually a greater role for "decorators" in our framework other than just in the renderer proper
[11:49:38 EDT(-0400)] <Bosmon> Since they uniquely, allow the specification of bindings in a "deferred" or replayable way
[11:50:42 EDT(-0400)] * colinclark is slightly distracted by a call... sorry for any terseness.
[11:50:44 EDT(-0400)] <Bosmon> To talk about bindings which "always should" be on an element, whether its markup is being regenerated or not
[11:50:56 EDT(-0400)] <Bosmon> Now.... jQuery.live() is the only thing so far that might promise to do that
[11:51:03 EDT(-0400)] <Bosmon> But that binds you to a model involving real selectors
[11:51:11 EDT(-0400)] <Bosmon> WHereas of course, the "true" selector is under the control of the component
[11:51:15 EDT(-0400)] <colinclark> yeah
[11:51:31 EDT(-0400)] <Bosmon> So I don't think there could conceivably be any "existing" API or model in jQuery for expressing what we mean here
[11:51:44 EDT(-0400)] <Bosmon> WHereas, a jQuery decorator "totally does", to coin a phrase (tongue)
[11:52:31 EDT(-0400)] <Bosmon> The required indirection can only be expressed, for a start, via a concept like the DOM binder, or else, an rsf:id + cutpoint
[11:52:52 EDT(-0400)] <Bosmon> Both of these are equivalent models of a "1 level indirected" selector
[11:53:01 EDT(-0400)] <Bosmon> I guess we could make a thing which looks like a "fake jQuery"
[11:53:08 EDT(-0400)] <Bosmon> That whenever you invoke it, it bottles itself
[11:53:15 EDT(-0400)] <fj4000> does jQuery support XPath?
[11:53:37 EDT(-0400)] <colinclark> fj4000: Less and less, but yes. Not sure how it relates.
[11:53:41 EDT(-0400)] <Bosmon> I'm not sure if people will necessarily think that is any more idiomatic than just letting them write a data structure
[11:53:58 EDT(-0400)] <colinclark> Bosmon: yeah
[11:54:19 EDT(-0400)] <Bosmon> We would have an even harder job on our hands trying to explain what kinds of things you could do with the "fake jQuery"
[11:54:28 EDT(-0400)] <Bosmon> I guess there is no reason it couldn't do "everything"
[11:54:35 EDT(-0400)] <Bosmon> But the return values would be all wrong
[11:54:57 EDT(-0400)] <Bosmon> You would have to say that "here is a thing which behaves like a jQuery for all purposes of INPUT, but will never give you any OUTPUT"
[11:55:05 EDT(-0400)] <Bosmon> Is that really the kind of abstraction we want to promote? (tongue)
[11:55:06 EDT(-0400)] <michelled> seems like the data structure would be more clear
[11:55:36 EDT(-0400)] <michelled> obviously not (tongue)
[11:57:56 EDT(-0400)] * heidi lit a fire. brr.
[11:58:11 EDT(-0400)] <michelled> ya, what's going on with the weather!
[11:58:19 EDT(-0400)] <heidi> serious!
[11:59:11 EDT(-0400)] <fj4000> colinclark, Bosomo: would you want to employ some sort of delegate to watch over all rendered markup?
[11:59:23 EDT(-0400)] <Bosmon> fj4000: No
[11:59:29 EDT(-0400)] <Bosmon> This is what we made decorators for
[12:00:02 EDT(-0400)] <Bosmon> I guess if you know that something is a pure jQuery event handler, you can defer to delegates efficiently
[12:00:10 EDT(-0400)] <Bosmon> But this again creates the "chasm of conceptuality"
[12:00:23 EDT(-0400)] <Bosmon> People suddenly need to be aware of what things can be delegated, and which things can't
[12:00:43 EDT(-0400)] <michelled> ya, it's not ideal
[12:00:47 EDT(-0400)] <Bosmon> For example, you could never delegate the attachment of a jQuery UI or fluid component
[12:00:51 EDT(-0400)] <Bosmon> Since those need to be done explicitly
[12:01:07 EDT(-0400)] <Bosmon> Colin makes a good point by saying "people expect to be able to just jQuery stuff onto things"
[12:01:19 EDT(-0400)] <Bosmon> But I am afraid this is a point where people's expectations will need to be adjusted (tongue)
[12:02:50 EDT(-0400)] <Bosmon> "This markup is being rendered" is just a special case of the general phenomenon "this markup doesn't exist right now, but it might soon"
[12:03:05 EDT(-0400)] <michelled> one of the current issues with UI Options is that it requires the renderer. if we gave people a choice like with Pager then expectations could be associated with a choice.
[12:03:08 EDT(-0400)] <Bosmon> Which people are already familiar with from the tortuous necessity of stuffing stuff in AJAX callbacks
[12:03:36 EDT(-0400)] <Bosmon> They will thank us in the end, for us sparing them the headache of having to wonder "is this markup here now, or is it here later, or is it going to be here later more than one time?"
[12:04:22 EDT(-0400)] <Bosmon> michelled: This is the issue I was referring to... that it seems we ought to (and should) be able to support the use of decorators, without the use of the renderer
[12:04:31 EDT(-0400)] <Bosmon> This is the issue that came up yesterday, with "autoBind"
[12:04:49 EDT(-0400)] <Bosmon> It should be possible for anyone to get "autoBind" - whether they are using our renderer, a different renderer, or no renderer
[12:05:04 EDT(-0400)] <Bosmon> And.... all that is required for autoBind, is support for decorators, since that is how it is implemented
[12:05:13 EDT(-0400)] <Bosmon> So.... liberating autoBind actually liberates everything
[12:05:34 EDT(-0400)] <michelled> interesting. so we basically take control of the markup when a component is created. anything else the user wants to do with it will need to be specified through decorators.
[12:05:44 EDT(-0400)] <Bosmon> Yes
[12:05:57 EDT(-0400)] <Bosmon> The current "implementation" of decorators in the renderer is actually just one of many possible implementations
[12:06:04 EDT(-0400)] <michelled> it's a different mindset
[12:06:20 EDT(-0400)] <Bosmon> For example, it has a particular workflow, based on whether it is an "addClass" decorator etc. that can be honoured by simply banging on the markup, it does it "early"
[12:06:58 EDT(-0400)] <Bosmon> Whereas if it is one of the other kind, it i) allocates a firm id for the coming markup node, ii) pushes the decorator onto a queue, iii) goes through them all again at the end once the markup is rendered
[12:07:12 EDT(-0400)] <Bosmon> But since decorators are purely declarative, they don't commit you to any one particular workflow of honouring them
[12:07:35 EDT(-0400)] <Bosmon> It would be perfectly possible to apply them to preexisting markup - assuming you could get access to a "cutpoints" list or equivalent map of selectors
[12:07:52 EDT(-0400)] <Bosmon> We speculated some time in the past about how similar the affordances of the "DOM Binder" is to the "cutpoints list" for the renderer
[12:08:04 EDT(-0400)] <Bosmon> And this would be a great opportunity to bring these two concepts a bit closer in line
[12:08:28 EDT(-0400)] <Bosmon> Ultimately, since both of these things are configured declaratively, it is perfectly straightforward to make them conform (tongue)
[12:11:49 EDT(-0400)] <Bosmon> Hi yura - you there?
[12:11:54 EDT(-0400)] <Bosmon> Justin reopened FLUID-2637 this morning....
[12:12:14 EDT(-0400)] <Bosmon> Do you want to take a look at it, I can deal with it if you want
[12:12:40 EDT(-0400)] <yura> Bosmon: yes, I he pointed a problem , i m almost done with it
[12:12:45 EDT(-0400)] <Bosmon> ok, cool
[12:13:00 EDT(-0400)] <yura> Bosmon: I guess I ll just ask you to review it in a bit (smile)
[12:13:03 EDT(-0400)] <Bosmon> (smile)
[12:13:35 EDT(-0400)] <Bosmon> 1723 Brown in Phil. Trans. XXXII. 354 The Liquor..will crystalize to the Sticks, something like Sugar-candy, but in much larger Shoots; and this they call *Cat-Salt, or Salt-Cats.
[12:42:58 EDT(-0400)] * elicochran (n=elicochr@dwin-wlan-436.AirBears.Berkeley.EDU) has joined #fluid-work
[12:56:26 EDT(-0400)] * elicochran_ (n=elicochr@dwin-wlan-436.AirBears.Berkeley.EDU) has joined #fluid-work
[13:14:36 EDT(-0400)] * elicochran (n=elicochr@dhcp-169-229-212-72.LIPS.Berkeley.EDU) has joined #fluid-work
[13:20:12 EDT(-0400)] <yura> Bosmon: I ve just submitted the fix
[13:20:17 EDT(-0400)] <yura> for 2637
[13:24:10 EDT(-0400)] <alisonbenjamin> michelled: I've posted a patch for http://issues.fluidproject.org/browse/FLUID-2383
[13:24:22 EDT(-0400)] <Bosmon> yura - thanks
[13:24:29 EDT(-0400)] <michelled> thanks, I'll take a look at it
[13:24:31 EDT(-0400)] <Bosmon> I will look at this shortly
[13:31:09 EDT(-0400)] <elicochran> Justin_o: I just ran the "Convert Line Endings" command in Aptana against the Infusion source tree. Ouch. I would say that almost half the files came were touched.
[13:31:21 EDT(-0400)] <elicochran> The question is, how big a problem is this?
[13:31:57 EDT(-0400)] <elicochran> fj4000: do you remember what problem was caused a while back by having the wrong lineendings in a file?
[13:32:12 EDT(-0400)] <elicochran> you and I worked on this but I can't remember why
[13:32:20 EDT(-0400)] <fj4000> in aptana?
[13:33:02 EDT(-0400)] <elicochran> there was a bug... and we ultimately determined that it was being caused by bad line endings... or maybe it wasn't a bug... maybe it was trouble with a patch
[13:33:28 EDT(-0400)] <Bosmon> Yes
[13:33:33 EDT(-0400)] <elicochran> but either way, we decided to normalize line endings to the Unix line ending not the DOS line ending
[13:33:34 EDT(-0400)] <Bosmon> Bad line endings are actually fairly pernicious
[13:34:02 EDT(-0400)] <Bosmon> For example, in accepting a patch from someone with the "wrong polarity", you can get Eclipse to consider that the entire file "is in difference"
[13:34:14 EDT(-0400)] <Bosmon> We dealt with this in Sakai a lot
[13:34:55 EDT(-0400)] <Bosmon> Now, there is a subtlety here.... since SVN is actually not only capable of, but actually does, reconvert line endings "on the fly"
[13:35:28 EDT(-0400)] <Bosmon> I should probably talk to someone in Sakai, but the bottom line was that each client needs to be set to "use platform encoding" - that is, the encoding for their local platform
[13:35:36 EDT(-0400)] <Bosmon> Irrespective of how the files are actually sitting in SVN....
[13:36:19 EDT(-0400)] <elicochran> hmm
[13:36:43 EDT(-0400)] <elicochran> so right now we've got about 100 files in the source tree that have DOS encoding
[13:36:51 EDT(-0400)] <elicochran> but is this really a problem?
[13:36:58 EDT(-0400)] <Bosmon> I think it is....
[13:37:21 EDT(-0400)] <Bosmon> I'm not sure I completely understand/remember what kind of problem it represents (tongue)
[13:37:25 EDT(-0400)] <Bosmon> But I am fairly sure it is one...
[13:37:27 EDT(-0400)] <Bosmon> I will ask Aaron
[13:45:36 EDT(-0400)] <elicochran> fj4000: does any of this ring a bell?
[13:45:40 EDT(-0400)] <fj4000> yes
[13:46:02 EDT(-0400)] <fj4000> im wondering, did the encoding have to change or just trimming the line endings?
[13:46:56 EDT(-0400)] <Bosmon> OK
[13:47:40 EDT(-0400)] <Bosmon> What I get from Aaron is that i) it seems generally better to normalise all files to unix encoding, ii) the problems may arise if a single SVN commit touches files that are in more than encoding
[13:47:41 EDT(-0400)] <fj4000> elicochran: i dont remember the solution we came up with though
[13:47:57 EDT(-0400)] <Bosmon> iii) there is an svn:enctype property which determines this
[13:50:45 EDT(-0400)] <elicochran> fj4000: OK, I just found the discussion on the list: http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2008-08-21
[13:50:53 EDT(-0400)] <elicochran> looks like the problem was in the patch
[13:50:56 EDT(-0400)] <elicochran> a patch
[13:51:10 EDT(-0400)] <fj4000> was there a solution?
[13:51:17 EDT(-0400)] <elicochran> so lines were getting flagged as changed that where not actually changed
[13:51:19 EDT(-0400)] <fj4000> other than to re-save the file?
[13:51:30 EDT(-0400)] <fj4000> right, Bosmon said that would happen
[13:51:44 EDT(-0400)] <elicochran> the solution was that I slapped you on the wrist, and asked you to check your editor settings (tongue)
[13:51:58 EDT(-0400)] <fj4000> well....
[13:52:43 EDT(-0400)] <elicochran> but you are not the only culprit
[13:53:04 EDT(-0400)] <elicochran> I haven't actually looked to see who's checking these puppies in
[13:53:15 EDT(-0400)] <elicochran> but we've got a bunch
[13:53:19 EDT(-0400)] <fj4000> hmmm
[13:53:33 EDT(-0400)] <fj4000> where can i check my encoding settins?
[13:54:03 EDT(-0400)] <elicochran> what editor are you using? still notepad++?
[13:54:04 EDT(-0400)] <fj4000> ok
[13:54:16 EDT(-0400)] <fj4000> so encoding = UTF-8 on my machine
[13:54:37 EDT(-0400)] <elicochran> it's not actually encoding
[13:54:42 EDT(-0400)] <elicochran> it's line endings
[13:55:06 EDT(-0400)] <elicochran> line endings = Unix (LF)
[13:55:27 EDT(-0400)] <elicochran> as opposed to DOS/Windows (CRLF)
[13:55:41 EDT(-0400)] <elicochran> fj4000: ^
[13:55:49 EDT(-0400)] * fj4000 is wondering
[13:55:55 EDT(-0400)] <fj4000> how can i check this?
[13:56:23 EDT(-0400)] <elicochran> most editors have a setting
[13:56:42 EDT(-0400)] <fj4000> in aptana?
[13:58:31 EDT(-0400)] <elicochran> fj4000: I'll find it
[13:58:58 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176393934.dsl.bell.ca) has joined #fluid-work
[13:59:01 EDT(-0400)] <fj4000> ok
[14:00:18 EDT(-0400)] <Justin_o> Bosmon: does querystring.js need a license file
[14:08:30 EDT(-0400)] * elicochran_ (n=elicochr@dwin-wlan-436.AirBears.Berkeley.EDU) has joined #fluid-work
[14:09:17 EDT(-0400)] <elicochran_> fj4000: my setting is under Preferences/Workspace/New text file line delimiter
[14:10:18 EDT(-0400)] <elicochran_> but that looks like it only applies to new files
[14:10:29 EDT(-0400)] <fj4000> i dont even see it
[14:10:54 EDT(-0400)] <fj4000> actually i do, sorry (tongue)
[14:11:21 EDT(-0400)] <fj4000> ok, so i changed that from Default to Unix
[14:13:17 EDT(-0400)] * lessthanzero (n=FatalRem@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[14:14:01 EDT(-0400)] <fj4000> elicochran: do you plan on running some sort of conversion script over all our existing files?
[14:18:29 EDT(-0400)] * alisonbenjamin (n=alisonbe@user133-105.wireless.utoronto.ca) has joined #fluid-work
[14:23:17 EDT(-0400)] <fj4000> Justin_o: im going to review 2765 - is that ok?
[14:24:27 EDT(-0400)] <Justin_o> fj4000: yes please... thanks
[14:31:57 EDT(-0400)] <fj4000> colinclark: i made a small syntax change in ProgressiveEnhancement.js
[14:32:10 EDT(-0400)] <colinclark> fj4000: ok
[14:32:14 EDT(-0400)] <colinclark> what did you change?
[14:32:18 EDT(-0400)] <fj4000> instead of declaring the same rule twice, i just put a comma
[14:32:49 EDT(-0400)] <fj4000> looks a little less confusing this way
[14:33:10 EDT(-0400)] <fj4000> would you like to review it?
[14:33:29 EDT(-0400)] <Bosmon> Justin_o: I think querystring.js probably just needs removing
[14:33:40 EDT(-0400)] <fj4000> colinclark ^
[14:33:42 EDT(-0400)] <Bosmon> I don't see that it is used
[14:34:15 EDT(-0400)] <Justin_o> Bosmon: oh okay... thanks
[14:34:28 EDT(-0400)] <Justin_o> I have a question about fastXMLPull as well
[14:34:31 EDT(-0400)] <colinclark> fj4000: I'm stretched pretty thin, but someone should review it. Perhaps Bosmon has a split second to take a look?
[14:34:36 EDT(-0400)] <fj4000> ok
[14:34:45 EDT(-0400)] <fj4000> i will commit it, and make a comment on the ticket
[14:34:49 EDT(-0400)] <Bosmon> ok
[14:34:50 EDT(-0400)] <colinclark> Anastasia had committed that code, and it needed review anyway.
[14:35:00 EDT(-0400)] <Justin_o> Bosmon: http://issues.fluidproject.org/browse/FLUID-1921
[14:35:06 EDT(-0400)] <Bosmon> cheers
[14:35:07 EDT(-0400)] <colinclark> I wasn't entirely satisfied that it was fully thought out, so can you also review it all, fj4000?
[14:35:21 EDT(-0400)] <fj4000> sure
[14:35:22 EDT(-0400)] <colinclark> Justin_o: What's your fastPull question?
[14:35:31 EDT(-0400)] <Justin_o> so for that issue we are supposed to put the info about 3rd party stuff in the README
[14:35:47 EDT(-0400)] <Justin_o> just looked at the file and there was a different name in the comment at the top
[14:36:07 EDT(-0400)] <colinclark> Justin_o: Name for the file? Name of the author?
[14:36:51 EDT(-0400)] <Justin_o> well it says tinysmlsax.js version 3.1
[14:37:37 EDT(-0400)] <Justin_o> so i'm confused as to what name to add to the readme
[14:38:20 EDT(-0400)] <Justin_o> colinclark, Bosmon ^
[14:38:28 EDT(-0400)] <colinclark> Justin_o: (smile)
[14:38:49 EDT(-0400)] <colinclark> Yeah, fastXmlPull.js is a heavy reworking of the tinysmlsax file.
[14:38:56 EDT(-0400)] <colinclark> So portions of it are ours, portions, theirs.
[14:39:50 EDT(-0400)] <colinclark> Here's a wiki page that describes the whole situation in depth: http://en.wikipedia.org/wiki/Shreddies
[14:39:52 EDT(-0400)] <colinclark> oops
[14:39:53 EDT(-0400)] <colinclark> ha!
[14:39:58 EDT(-0400)] <colinclark> I always do this.
[14:40:04 EDT(-0400)] <colinclark> I was teaching jessm about Shreddies.
[14:40:12 EDT(-0400)] <colinclark> Let's try this again.
[14:40:13 EDT(-0400)] <colinclark> http://wiki.fluidproject.org/display/fluid/Licensing+for+fastXmlPull.js
[14:40:24 EDT(-0400)] <Justin_o> (smile)
[14:40:30 EDT(-0400)] * colinclark is such a cut and paste dork.
[14:40:36 EDT(-0400)] <colinclark> Bosmon: Are you familiar with Shreddies?
[14:41:39 EDT(-0400)] <Justin_o> colinclark: so maybe I should say that fastXmlPull is based on tinysmlsax and point at the wiki page
[14:41:41 EDT(-0400)] <colinclark> Justin_o: In short, you can say something in the README about us using portions of XMLForScript's SAX parser in the renderer, and that these portions are covered under the following license, etc.
[14:41:46 EDT(-0400)] <colinclark> Justin_o: Yep, that sounds fine.
[14:41:59 EDT(-0400)] <Bosmon> Yes
[14:42:01 EDT(-0400)] <Justin_o> colinclark: thanks
[14:42:04 EDT(-0400)] <Bosmon> We have Shreddies
[14:42:07 EDT(-0400)] <colinclark> any time
[14:42:19 EDT(-0400)] * mtheoryx83 (n=mtheoryx@c-98-228-108-233.hsd1.in.comcast.net) has joined #fluid-work
[14:42:21 EDT(-0400)] <Justin_o> Bosmon: do you have the new Diamond shaped Shreddies?
[14:42:22 EDT(-0400)] <colinclark> Apparently they don't exist in the States.
[14:42:27 EDT(-0400)] <colinclark> lol
[14:42:42 EDT(-0400)] <Bosmon> Justin_o: I can't account for that (tongue)
[14:43:14 EDT(-0400)] <Justin_o> http://themarketingguy.files.wordpress.com/2008/03/diamon-shreddies-ooh-02.jpg
[14:43:44 EDT(-0400)] <colinclark> I was suggesting that fj4000's Infusion logo reminded me of a Shreddie...
[14:43:52 EDT(-0400)] <colinclark> but jessm is convinced it is a pretzel.
[14:43:59 EDT(-0400)] <colinclark> (smile)
[14:44:25 EDT(-0400)] <colinclark> Whatever it is, it looks tasty and awesome.
[14:49:34 EDT(-0400)] <Bosmon> Yes
[14:49:42 EDT(-0400)] <Bosmon> sgithens342f also declared it was awesome
[14:50:07 EDT(-0400)] <sgithens342f> what?
[14:50:40 EDT(-0400)] <sgithens342f> I'm not sure if I've ever had shreddies actually
[14:50:54 EDT(-0400)] <sgithens342f> though I do like that kind of cereal that's in little squares like that
[14:52:50 EDT(-0400)] <Justin_o> added FLUID-2771 to bug parade
[14:53:13 EDT(-0400)] <Bosmon> Justin_o: If I review FLUID-2765, do I mark it as "Closed" or do I just comment and assign it back to you
[14:54:15 EDT(-0400)] <Justin_o> Bosmon: you can just mark it as resolved... if you have time to do some qa testing on it and it passes then you can mark it as closed
[14:54:29 EDT(-0400)] <Bosmon> Well
[14:54:33 EDT(-0400)] <Bosmon> It is already marked as resolved
[14:54:57 EDT(-0400)] <Justin_o> oh yes... that's right...sorry... should have said comment on the jira and assigned it back to me instead of resolved
[14:55:23 EDT(-0400)] <Bosmon> Parade is KING CENTRAL!
[14:56:12 EDT(-0400)] <Bosmon> michelled: Did you already comment on your FLUID-2374 comment in the channel?
[14:56:39 EDT(-0400)] <Bosmon> Can you explain why you want a a behaviour completely different from that of a standard HTML form? (tongue)
[14:57:14 EDT(-0400)] <sgithens342f> OOOOH, the Logo!
[14:57:28 EDT(-0400)] <sgithens342f> yeah, it's completely awesome
[14:57:51 EDT(-0400)] <elicochran_> Shreddies are Triskets in the US
[14:58:00 EDT(-0400)] <Bosmon> ha
[14:58:04 EDT(-0400)] <Bosmon> Even though they have more than 3 sides
[14:58:14 EDT(-0400)] <sgithens342f> I was about ready to drop everything and go look for venture capital to start some sort of cool startup the second I saw it
[14:58:27 EDT(-0400)] <elicochran_> yeah, I don't know where the name comes from
[14:58:54 EDT(-0400)] <Bosmon> If only John Norman weren't retired
[14:58:57 EDT(-0400)] <Bosmon> I'm sure he'd give us some
[14:59:17 EDT(-0400)] <sgithens342f> with a logo that awesome he couldn't say no
[14:59:34 EDT(-0400)] <colinclark> Triscuits are crackers, not cereal!
[14:59:37 EDT(-0400)] <elicochran_> oh, I'm wrong
[14:59:44 EDT(-0400)] <Bosmon> ha
[14:59:49 EDT(-0400)] <elicochran_> a Trisket is a kind of cracker
[14:59:49 EDT(-0400)] <colinclark> Though Triscuits are fairly awesome, too.
[15:00:05 EDT(-0400)] <elicochran_> looks just like a Shreddies
[15:00:07 EDT(-0400)] <elicochran_> wow
[15:00:11 EDT(-0400)] <michelled> Bosmon: it's not that I want non-standard behaviour per se, I just expected enter to behave like tab does. Perhaps I'm just not a good user (tongue)
[15:00:16 EDT(-0400)] <colinclark> Shreddies are smaller--bite sized.
[15:00:27 EDT(-0400)] <elicochran_> got it
[15:00:30 EDT(-0400)] <Bosmon> michelled: Why on earth should enter to behave like tab does!
[15:00:31 EDT(-0400)] <sgithens342f> Cracked Black Pepper Triscuits rock completely
[15:00:41 EDT(-0400)] <Bosmon> It doesn't do that in any other context....
[15:01:05 EDT(-0400)] <Bosmon> yura: Looking at your patch now
[15:01:30 EDT(-0400)] <Justin_o> Bosmon: I suppose it is the fact that it is saving the value to the slider as opposed to the entire dialog
[15:02:15 EDT(-0400)] <Justin_o> If you close on enter, the user won't actually be able to see the effect in the preview window
[15:02:26 EDT(-0400)] <Bosmon> Well
[15:02:32 EDT(-0400)] <Bosmon> I can't really grasp this argument at all (tongue)
[15:03:03 EDT(-0400)] <Bosmon> Do you think the user will really care about this abstraction we invented of "saving a value to a slider"? (tongue)
[15:03:21 EDT(-0400)] <Bosmon> When every other form they have ever seen submits the overall form when someone hits enter in a text field that is part of it...
[15:05:24 EDT(-0400)] <Justin_o> is that true if fields which contain multiple forms
[15:05:35 EDT(-0400)] <Justin_o> i think i just said that backwards
[15:05:42 EDT(-0400)] <Justin_o> should be forms that contain multiple fields
[15:06:36 EDT(-0400)] <colinclark> Justin_o: You've probably got your hands full at the moment, but you were going to send an email to the infusion-users list with a brief summary of changes in 1.1, right?
[15:06:46 EDT(-0400)] <colinclark> I can take a look at it if you want.
[15:06:46 EDT(-0400)] <Bosmon> Justin_o: Yes
[15:06:50 EDT(-0400)] <Bosmon> It is a universal behaviour
[15:07:25 EDT(-0400)] <Bosmon> The exception is, obviously, <textarea> fields... of which hitting enter causes a newline
[15:08:02 EDT(-0400)] <Justin_o> colinclark: thanks if you have time
[15:08:28 EDT(-0400)] * elicochran (n=elicochr@dwin-wlan-436.AirBears.Berkeley.EDU) has joined #fluid-work
[15:08:48 EDT(-0400)] <Bosmon> colinclark: btw, I found tabs in your commit for rev 6939 (end of March).... best check for settings degradation
[15:08:52 EDT(-0400)] <Justin_o> Bosmon: my only concern is that the preview as it is now, won't preview anything for the user
[15:08:55 EDT(-0400)] * elicochran_ (n=elicochr@dhcp-169-229-212-34.LIPS.Berkeley.EDU) has joined #fluid-work
[15:09:01 EDT(-0400)] <colinclark> Bosmon: yack
[15:09:05 EDT(-0400)] <Bosmon> Annoyingly I have found my current Eclipse is also inserting tabs sometimes
[15:09:11 EDT(-0400)] <Bosmon> Even though universally every setting has put spaces in
[15:09:16 EDT(-0400)] <fj4000> Justin_o, michelled, Bosomon: just to add my 2 cents: why not just have the textfield update the slider on every keystroke?
[15:09:29 EDT(-0400)] <fj4000> hitting enter, in my mind, would trigger the submit process
[15:09:47 EDT(-0400)] <Bosmon> fj4000: That can have awkward effects when the user is typing a multi-digit number
[15:09:54 EDT(-0400)] <colinclark> For the record, I also agree that Enter should indeed "submit" the form, causing the settings to be saved.
[15:10:04 EDT(-0400)] <fj4000> why would it be awkward?
[15:10:16 EDT(-0400)] <Bosmon> YOu probably don't want a preview update when they type "1" beginning the number "10" for a point size for a font
[15:10:18 EDT(-0400)] <colinclark> And I think we should autoupdate the slider after a reasonable delay.
[15:10:22 EDT(-0400)] <Bosmon> That would be very irritating
[15:10:27 EDT(-0400)] <colinclark> So we don't have to deal with the mult-digit issue.
[15:11:15 EDT(-0400)] <Bosmon> For the record, I agree with colinclark (tongue)
[15:11:15 EDT(-0400)] <colinclark> This is how most autocomplete widgets work... they wait for you to stop typing a bit.
[15:11:15 EDT(-0400)] <Bosmon> Whether he is a false or a true colin
[15:11:15 EDT(-0400)] <colinclark> As far as I can tell, I'm the real thing this time.
[15:11:15 EDT(-0400)] <Bosmon> You would say that
[15:11:15 EDT(-0400)] <fj4000> this could be completely prevented with a reasonable delay
[15:11:17 EDT(-0400)] <fj4000> very common with ajax autosuggest features
[15:11:22 EDT(-0400)] <colinclark> fj4000: hey!
[15:11:26 EDT(-0400)] <colinclark> I just said that. (tongue)
[15:11:29 EDT(-0400)] <fj4000> oh
[15:11:31 EDT(-0400)] <fj4000> sorry
[15:11:36 EDT(-0400)] <fj4000> im only diving right in
[15:11:39 EDT(-0400)] <colinclark> lol
[15:11:43 EDT(-0400)] <colinclark> I'm just teasing you.
[15:11:53 EDT(-0400)] <fj4000> but i find this works fantasticly
[15:12:43 EDT(-0400)] <fj4000> in fact
[15:12:43 EDT(-0400)] <colinclark> So +1 for Enter = Save, and a further +1 for auto-updating the slider with a reasonable delay after typing into the text field.
[15:12:43 EDT(-0400)] <fj4000> i've repeatedly found a delay of 175-225 ms is perfect for most ppl
[15:12:43 EDT(-0400)] <colinclark> It seems to me that we've already got the first one now, and the second issue will wait until after 1.1.
[15:12:43 EDT(-0400)] <Bosmon> fj4000: That sounds like a delay of 200ms to me (tongue)
[15:12:43 EDT(-0400)] <colinclark> (smile)
[15:12:48 EDT(-0400)] <colinclark> This is actually a feature I'd love to see in UI Options one day...
[15:12:48 EDT(-0400)] <Bosmon> Or do you suggest randomly generating a delay in the interval 175-225ms? (tongue)
[15:13:00 EDT(-0400)] <fj4000> it depends - some ppl really notice the difference
[15:13:00 EDT(-0400)] <colinclark> The ability to control the timing of animations and other timed events.
[15:13:02 EDT(-0400)] <fj4000> no - its up to you audience
[15:13:08 EDT(-0400)] <Bosmon> colinclark: For sure
[15:13:10 EDT(-0400)] <fj4000> and there is a difference
[15:13:16 EDT(-0400)] <Bosmon> I would love the option to turn all damn animations off
[15:13:22 EDT(-0400)] <fj4000> even if its 50 ms
[15:13:22 EDT(-0400)] <Bosmon> I hate them
[15:13:22 EDT(-0400)] <colinclark> A critical feature for people who are slower to interact with the keyboard, and it's at the core of one of the WCAG guidelines.
[15:13:37 EDT(-0400)] <colinclark> In a sense, elicochran scratched the surface of this approach by making some of the animations in uploader declarative.
[15:13:39 EDT(-0400)] <Bosmon> When I do something, I want to see it happen...
[15:13:39 EDT(-0400)] <Bosmon> NOW
[15:13:51 EDT(-0400)] <fj4000> whoa
[15:15:23 EDT(-0400)] <fj4000> no need for caps (tongue)
[15:15:23 EDT(-0400)] <Bosmon> *NOW*!!!!
[15:15:23 EDT(-0400)] <Bosmon> fj4000: The Spot of Shame falls also upon you (tongue)
[15:15:23 EDT(-0400)] <fj4000> ?!
[15:16:56 EDT(-0400)] <fj4000> sounds like something for a Tide commercial
[15:16:56 EDT(-0400)] <Bosmon> At rev 6768 of March 17, you are also found heinously guilty of introducting tabs into sakai.js....
[15:16:56 EDT(-0400)] <fj4000> ooh, sorry
[15:16:56 EDT(-0400)] <Bosmon> I wonder if we can actually put an SVN hook in for this
[15:16:56 EDT(-0400)] <fj4000> i had a feeling this would happen - my Apatana at home was never switched
[15:16:56 EDT(-0400)] <colinclark> fj4000: Don't sweat it, apparently we are all wearing such a spot.
[15:16:56 EDT(-0400)] <michelled> for the record I'm easily convincable when it comes to UI behaviour. point, point, click, click (tongue)
[15:16:56 EDT(-0400)] <michelled> so I'm going to comment on that issue and close it at fixed and reviewed
[15:16:56 EDT(-0400)] <colinclark> For the record, I will stop using expressions like "For the record" now.
[15:16:56 EDT(-0400)] <fj4000> i changed my IDE to use Unix style line delimiters today, so hopefully there wont be any other windows contaminations
[15:16:57 EDT(-0400)] <michelled> Justin_o: are you good with that?
[15:17:08 EDT(-0400)] <fj4000> lol colinclark ^
[15:17:13 EDT(-0400)] <colinclark> michelled: If you do that, can you file a separate bug about the auto-update of the slider?
[15:17:22 EDT(-0400)] <michelled> sure
[15:17:26 EDT(-0400)] <colinclark> thanks, dude
[15:17:36 EDT(-0400)] <Justin_o> michelled: yep i agree
[15:17:43 EDT(-0400)] <michelled> np
[15:19:43 EDT(-0400)] <Bosmon> yura: Sorry to inform that patch is still not complete - hovering over "Email" still gives the click cursor and a tooltip "Click to sort" (tongue)
[15:19:56 EDT(-0400)] <Bosmon> But I will commit it anyway since what it does so far is correct
[15:24:46 EDT(-0400)] <yura> Bosmon: thanks I ll look into it now
[15:26:06 EDT(-0400)] <colinclark> yura: Hey, it's really awesome to have you working on these patches.
[15:26:23 EDT(-0400)] <colinclark> Sometimes these subtle bug fixes can be a bit of a slog, but it's much appreciated.
[15:27:41 EDT(-0400)] <yura> colinclark: thanks Colin, im trying to learn all the nuances , and the one above is , i think, on of them (smile)
[15:27:52 EDT(-0400)] <colinclark> (smile)
[15:28:00 EDT(-0400)] <colinclark> Bosmon was just asking me about FLUID-2247...
[15:28:37 EDT(-0400)] <colinclark> And he commented on the issue, noting that he'd unpeeled a larger issue around it.
[15:28:41 EDT(-0400)] <colinclark> http://issues.fluidproject.org/browse/FLUID-2247
[15:29:03 EDT(-0400)] <colinclark> In short, when a user manually invokes activate(someDomElement), a real event never fires
[15:29:11 EDT(-0400)] <colinclark> and so that second argument, the event, is essentially optional.
[15:29:14 EDT(-0400)] <colinclark> Kind of dorky, my bad.
[15:29:45 EDT(-0400)] <colinclark> Bosmon: I think we probably should fire activate as a real jQuery custom event.
[15:29:57 EDT(-0400)] <Bosmon> ok
[15:29:57 EDT(-0400)] <colinclark> Anyone have arguments against?
[15:30:02 EDT(-0400)] <Bosmon> I will set about doing that then
[15:30:10 EDT(-0400)] <Bosmon> My argument against is.... that someone else might already have one
[15:30:21 EDT(-0400)] <Bosmon> But... hopefully they would not register it on an "unknown element"
[15:30:41 EDT(-0400)] <colinclark> How might they already have one?
[15:30:47 EDT(-0400)] <Bosmon> Well
[15:30:54 EDT(-0400)] <Bosmon> As we all know.... these things are not properly namespaced
[15:31:06 EDT(-0400)] <colinclark> Ah, yes. That's what I figured. We can name them whatever we want.
[15:31:06 EDT(-0400)] <Bosmon> Anyone can, at the drop of a hat, invent a new "jQuery synthetic event"
[15:31:18 EDT(-0400)] <colinclark> So I guess we could call it a "fluid.activate" event
[15:31:23 EDT(-0400)] <colinclark> However awkward that might be.
[15:31:24 EDT(-0400)] <Bosmon> Well, we can't use periods
[15:31:31 EDT(-0400)] <Bosmon> Those are reserved for traditional namespacing
[15:31:41 EDT(-0400)] <Bosmon> Unless you really mean we should call the base event "fluid"
[15:31:43 EDT(-0400)] <colinclark> ah, right
[15:31:46 EDT(-0400)] <Bosmon> Assigned to the namespace "activate"
[15:31:52 EDT(-0400)] <colinclark> yeah
[15:31:54 EDT(-0400)] <colinclark> why wouldn't we?
[15:32:03 EDT(-0400)] <Bosmon> I'm not sure the semantics would be right
[15:32:18 EDT(-0400)] <Bosmon> It would then be impossible to register more than one such thing on a given element
[15:32:26 EDT(-0400)] <Bosmon> Since when you fire an event, you would fire them "all"
[15:32:38 EDT(-0400)] <colinclark> oh, yes
[15:32:39 EDT(-0400)] <colinclark> right
[15:32:45 EDT(-0400)] <colinclark> that would be a show stopper
[15:32:49 EDT(-0400)] <Bosmon> Yars
[15:32:54 EDT(-0400)] <Bosmon> So
[15:33:02 EDT(-0400)] <Bosmon> We could call it "activate".. and bank on decency
[15:33:10 EDT(-0400)] <Bosmon> Or else something less pleasant like "fluid-activate"
[15:33:28 EDT(-0400)] <colinclark> It seems reasonable... though we have been burned before.
[15:33:52 EDT(-0400)] <Bosmon> I guess the argument about "unknown" elements doesn't really wash
[15:34:07 EDT(-0400)] <colinclark> no
[15:34:08 EDT(-0400)] <Bosmon> If somebody really did want a new synthetic event called "activate", they would probably want it operable on anything
[15:34:20 EDT(-0400)] <Bosmon> Just in the way that w do
[15:34:24 EDT(-0400)] <colinclark> michelled: Do you have any particular opinion? It seems safest to call it fluid-activate, despite the awkwardness.
[15:34:59 EDT(-0400)] * michelled need to catch up
[15:35:26 EDT(-0400)] <colinclark> k
[15:39:41 EDT(-0400)] <colinclark> Bosmon: Quick unrelated question for you.
[15:39:48 EDT(-0400)] <Bosmon> Yars
[15:40:06 EDT(-0400)] <colinclark> What did you do for headers in the blog? Did you use real Hx's, or just strong tags?
[15:40:17 EDT(-0400)] <colinclark> I remember the stylesheet was somewhat lacking.
[15:40:22 EDT(-0400)] <Bosmon> I used hs
[15:40:56 EDT(-0400)] <michelled> I'm leaning towards fluid-activate even though it's ugly. Perhaps I'm remembering the pain of 'selectable'. But I'd go with what others prefer.
[15:41:13 EDT(-0400)] <colinclark> it did suck to have to change our api
[15:41:19 EDT(-0400)] <colinclark> for no reason of our own
[15:49:31 EDT(-0400)] <colinclark> Bosmon: I guess we'll go with "fluid-activate"
[15:49:33 EDT(-0400)] <colinclark> I really hate it.
[15:49:35 EDT(-0400)] <Bosmon> ok
[15:49:56 EDT(-0400)] <Bosmon> In many ways, it might just be an implementation detail anyway
[15:54:39 EDT(-0400)] <colinclark> Bosmon: For the most part, they'll never know, yes.
[15:54:56 EDT(-0400)] <Bosmon> They'll never know that we are a CATT
[15:55:00 EDT(-0400)] <colinclark> Actually, i guess in nearly every case, they'll just pass us a function when they make something activatable.
[15:55:02 EDT(-0400)] <colinclark> (smile)
[15:56:50 EDT(-0400)] <colinclark> Bosmon: I'll comment on the JIRA, just so it's on record.
[15:56:55 EDT(-0400)] <Bosmon> cool
[15:57:54 EDT(-0400)] <Bosmon> Wow..... really very little rain in Boulder
[15:57:59 EDT(-0400)] <Bosmon> I wonder if this graph can be correct....
[16:09:07 EDT(-0400)] <Bosmon> Githens is using the Pager on a site with 8000 members....
[16:09:11 EDT(-0400)] <Bosmon> And doing it all on the client!
[16:09:14 EDT(-0400)] <colinclark> wow!
[16:09:18 EDT(-0400)] <Bosmon> (21:07:06) Hens Respectable: it's pretty fast though. It loads it up and renders in less than 5 seconds and after that all the sorting/paging is super fast
[16:09:23 EDT(-0400)] <colinclark> Good to know!
[16:09:31 EDT(-0400)] <Bosmon> Well.... it is a bit... surprising
[16:09:46 EDT(-0400)] <Bosmon> We always put "10,000" as our kind of ballpark figure for a data size that would certainly preclude client work
[16:09:47 EDT(-0400)] <michelled> yes, I wonder how it will be on IE
[16:10:18 EDT(-0400)] <michelled> colinclark: when you created the patches for 2743, are they incremental? Do I need to apply a then b then c or just c?
[16:10:27 EDT(-0400)] <colinclark> michelled: Just c.
[16:10:51 EDT(-0400)] <michelled> hmmmm.... this isn't going to be easy.
[16:13:27 EDT(-0400)] <Bosmon> Apparently Boulder has OROGRAPHY.....
[16:13:30 EDT(-0400)] <Bosmon> "Due to orography, there are significant variations in temperature across the city of Boulder."
[16:18:28 EDT(-0400)] <colinclark> michelled: Do you need me to do it?
[16:18:58 EDT(-0400)] <michelled> no, I can manage. but you're going to need to double check it once I'm done
[16:19:05 EDT(-0400)] <colinclark> ok
[16:19:16 EDT(-0400)] <colinclark> hmm
[16:19:29 EDT(-0400)] <colinclark> i wonder if i should just do a "replacement patch"
[16:19:40 EDT(-0400)] <colinclark> see how it goes
[16:20:00 EDT(-0400)] <colinclark> i still have a copy of trunk with my changes in it, along with the now-defunct 1811 feature
[16:20:18 EDT(-0400)] <colinclark> michelled: Would that help at all?
[16:21:27 EDT(-0400)] <michelled> do you think you could update that trunk and generate a new patch? or would that be just as much work with conflicts?
[16:22:36 EDT(-0400)] <Bosmon> Actually... using a synthetic event makes this code make a fair amount more sense
[16:22:42 EDT(-0400)] <colinclark> Bosmon: excellent
[16:23:07 EDT(-0400)] <Bosmon> We currently have this wacky strategy of using jQuery.data with the key "defaultActivate" to store a function handle...
[16:23:15 EDT(-0400)] <colinclark> michelled: I think I can do something. Hang on and I'll try.
[16:38:44 EDT(-0400)] <Bosmon> I am actually finding the reasoning behind the way this plugin is written very hard to understand....
[16:38:48 EDT(-0400)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has joined #fluid-work
[16:45:47 EDT(-0400)] <colinclark> Bosmon: What is hard to understand?
[16:46:12 EDT(-0400)] <Bosmon> Well
[16:46:20 EDT(-0400)] <Bosmon> There are all these things called "activationHandler" (tongue)
[16:46:24 EDT(-0400)] <Bosmon> And they all do very different things...
[16:49:34 EDT(-0400)] * laurel (n=laurel@64.56.228.109) has left #fluid-work
[16:55:13 EDT(-0400)] * laurel (n=laurel@64.56.228.109) has joined #fluid-work
[16:58:22 EDT(-0400)] <laurel> I would like to know what it is about standup that seems to induce vomitting in my child. I'm sure glad it doesn't happen to me.
[16:59:00 EDT(-0400)] <colinclark> ick
[16:59:05 EDT(-0400)] <laurel> 2 days in a row too
[16:59:06 EDT(-0400)] <colinclark> Bosmon: Yeah, there's some cloudiness in that code, for sure.
[16:59:11 EDT(-0400)] <laurel> sheesh
[17:08:22 EDT(-0400)] <fj4000> justin_o: FLUID-2520 + FLUID-2519 need reviewing too
[17:09:19 EDT(-0400)] <justin_o> fj4000: thaqnks
[17:09:28 EDT(-0400)] <fj4000> np, just a heads up
[17:21:49 EDT(-0400)] <Bosmon> Glarg
[17:22:08 EDT(-0400)] <Bosmon> I hope yura will be back (tongue)
[17:24:38 EDT(-0400)] * mackrauss (n=armin@142.150.154.129) has joined #fluid-work
[17:25:18 EDT(-0400)] <michelled> welcome armin! nice to have you here (smile)
[17:26:07 EDT(-0400)] <mackrauss> Thank you michelled
[17:26:22 EDT(-0400)] * mackrauss (n=armin@142.150.154.129) has left #fluid-work
[17:26:45 EDT(-0400)] * mackrauss (n=armin@142.150.154.129) has joined #fluid-work
[17:29:26 EDT(-0400)] <Bosmon> justin_o: I think I have a fix for FLUID-2247 now
[17:29:35 EDT(-0400)] <Bosmon> It actually looks fairly good, since the plugin is now 12 lines shorter (tongue)
[17:30:38 EDT(-0400)] <justin_o> Bosmon: nice work
[17:30:45 EDT(-0400)] <Bosmon> I guess I will just commit it
[17:30:51 EDT(-0400)] <Bosmon> I have adjusted the test cases to test the new API
[17:31:08 EDT(-0400)] <Bosmon> But as far as I can see, we have no uses of this part of the API anywhere in the framework or samples
[17:31:56 EDT(-0400)] <justin_o> oh.... oh well...
[17:32:05 EDT(-0400)] <justin_o> hopefully someone will get a chance to do a code review
[17:32:10 EDT(-0400)] <Bosmon> Yes
[17:32:15 EDT(-0400)] <justin_o> I have to run now unfortunately
[17:32:38 EDT(-0400)] <justin_o> Bosmon: see you tomorrow
[17:32:53 EDT(-0400)] * justin_o (n=jmo@CPE001b63f2cc0e-CM0011aec4b062.cpe.net.cable.rogers.com) has left #fluid-work
[18:16:40 EDT(-0400)] * elicochran (n=elicochr@dwin-wlan-436.AirBears.Berkeley.EDU) has joined #fluid-work
[20:59:07 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176393934.dsl.bell.ca) has joined #fluid-work