fluid-work IRC Logs-2008-12-08

Owned by Fluid IRC Log Bot
Last updated: Dec 08, 2008Version comment
16 min read

[01:02:05 EST(-0500)] * famicom (n=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
[03:46:05 EST(-0500)] * famicom_ (n=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
[05:27:59 EST(-0500)] * famicom (i=famicom@5ED2FF2D.cable.ziggo.nl) has joined #fluid-work
[08:20:16 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[09:03:13 EST(-0500)] * jessm (n=Jess@c-24-34-214-137.hsd1.ma.comcast.net) has joined #fluid-work
[09:09:41 EST(-0500)] <Justin_o> jessm, Bosmon: are you able to send e-mails to the fluid-work?
[09:10:06 EST(-0500)] <Justin_o> mine keep getting rejected
[09:10:17 EST(-0500)] <jessm> lemme try
[09:10:23 EST(-0500)] <Justin_o> thanks
[09:11:50 EST(-0500)] <jessm> bounced
[09:11:55 EST(-0500)] * athena7 (n=athena7@99.164.85.168) has joined #fluid-work
[09:11:58 EST(-0500)] <jessm> Justin_o: can you send your bounce to Nakul?
[09:12:11 EST(-0500)] <Justin_o> sure will do thanks for checking
[09:12:12 EST(-0500)] <jessm> and let him know it's bouncing for others as well
[09:12:20 EST(-0500)] <Justin_o> for sure
[09:35:49 EST(-0500)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:55:11 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:02:23 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:23:07 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:27:08 EST(-0500)] <colinclark> Justin_o: So it's bug parade week, eh?
[10:29:06 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[10:30:28 EST(-0500)] <colinclark> Justin_o: Remind me of the process for bug parade-related commits?
[10:32:18 EST(-0500)] <Justin_o> colinclark: Hello, the gist of the process is that commits are only allowed against jiras which are in the bug parade list
[10:32:45 EST(-0500)] <Justin_o> since there is an issue with the mailing list currently you can view the list of bug parade issues in this jira filter
[10:32:46 EST(-0500)] <Justin_o> http://issues.fluidproject.org/secure/IssueNavigator.jspa?mode=hide&amp;requestId=10129
[10:35:59 EST(-0500)] <anastasiac> Justin_o, the explanation of committing during Bug Parade at http://wiki.fluidproject.org/display/fluid/Coding+and+Commit+Standards says that commits must go through a review before the issue is closed. Who should do the reivew? Should we be emailing the list or asking in the channel for a tech review of the code changes? Or would you review them yourself for functinality?
[10:37:36 EST(-0500)] <Justin_o> good question anastasiac... and you are right on all account really. The code itself should be reviewed by another developer and marked as such on the jira. I will also test it where need be to ensure functionality before closing it.
[10:37:58 EST(-0500)] <colinclark> anastasiac: Review requests on list or in the channel seem reasonable.
[10:38:05 EST(-0500)] <colinclark> Either is fine.
[10:40:27 EST(-0500)] <Justin_o> anastasiac: i have updated the wiki about needing code review and testing
[11:04:28 EST(-0500)] <Justin_o> the fluid-work mailing list seems to be working again
[11:33:13 EST(-0500)] <anastasiac> Justin_o, the uPortal community has been asking us to upgrade jQuery UI. Can we put FLUID-1922 on the bug parade, to ensure that this issue is addressed for 0.6?
[11:35:55 EST(-0500)] <Justin_o> okay i'll add it to the bug parade is this something that should be done before the other bugs...
[11:36:12 EST(-0500)] <Justin_o> are looked at... meaning will it have affects on other possible fixes
[11:43:04 EST(-0500)] <athena7> anastasiac: i think it would make things a little easier because we could bundle 1.6 w/ 3.1.0 rather that adding it in a dot release, but it's by no means a requirement
[11:43:14 EST(-0500)] <athena7> if it makes life hard for you guys, it's really OK
[11:44:43 EST(-0500)] <anastasiac> Justin_o, that's a good point - the 'upgrade to 1.5.3' part of FLUID-1922 should probably be done before other things, just in case
[11:44:55 EST(-0500)] <anastasiac> but the 'test against 1.6' could be later
[11:45:07 EST(-0500)] <anastasiac> in fact, might be better later, after other bugs are fixed
[11:45:50 EST(-0500)] <Justin_o> okay
[11:46:10 EST(-0500)] <Justin_o> anastasiac: thanks... i'm going to bump 1922 up to a blocker then
[11:47:17 EST(-0500)] <anastasiac> athena7, we won't be actually upgrading to 1.6, since it's only at rc2, but we will be testing against their trunk
[11:47:24 EST(-0500)] <athena7> oh ok
[11:47:26 EST(-0500)] <athena7> that makes sense
[11:47:46 EST(-0500)] <Bosmon> (sad)
[11:47:52 EST(-0500)] <Bosmon> I have missed everything
[11:48:06 EST(-0500)] <colinclark> Bosmon: ?
[11:48:07 EST(-0500)] <anastasiac> Bosmon - what have you missed?
[11:48:25 EST(-0500)] <Bosmon> There are a zillion things I need to do this week that are not on the bug parade...
[11:48:29 EST(-0500)] <Bosmon> I thought it was next week (sad)
[11:48:49 EST(-0500)] <colinclark> athena7: So we'll do our best to qualify against 1.6 so all you'll have to do, once it's released, is drop the new version and run the build scripts.
[11:48:58 EST(-0500)] <colinclark> Bosmon: Yes, I've asked Justin_o to check in with you about that.
[11:49:22 EST(-0500)] <athena7> sounds pretty cool
[11:49:31 EST(-0500)] <colinclark> There are a couple of immediate things that should be added to the parade, particularly the issue of moving rich and dropdown -related code into InlineEdit.js.
[11:49:38 EST(-0500)] <Bosmon> ok, cool
[11:49:41 EST(-0500)] <Bosmon> THat was one thing
[11:49:45 EST(-0500)] <colinclark> We'll have to make a call about whether or not to back our your Pager changes.
[11:49:53 EST(-0500)] <colinclark> You'll have to talk to the King about where those fall.
[11:50:08 EST(-0500)] <colinclark> Bosmon: You've already got one bug parade blocker filed for the refresh() bug that athena7 discovered.
[11:50:12 EST(-0500)] <Bosmon> yes
[11:50:42 EST(-0500)] <colinclark> Not the end of the world if we have to back the Pager changes out, but you can also talk with Justin_o here about what would be involved in prepping it for release.
[11:50:45 EST(-0500)] <athena7> and i am watching it now!
[11:51:11 EST(-0500)] <colinclark> Justin_o: You were also going to file a blanket "improve test coverage" issue for the parade, too, right?
[11:51:36 EST(-0500)] <Justin_o> colinclark: yes, I have filed it already... let go find the jira number
[11:52:17 EST(-0500)] <Justin_o> http://issues.fluidproject.org/browse/FLUID-1939
[11:52:21 EST(-0500)] <colinclark> Wicked, thanks.
[11:52:29 EST(-0500)] <Justin_o> no problem
[11:54:28 EST(-0500)] <colinclark> King, I have an issue...
[11:54:34 EST(-0500)] <Justin_o> sure
[11:54:54 EST(-0500)] <colinclark> I was slightly hasty in resolving my "add progressive enhancement" JIRA on Friday.
[11:55:05 EST(-0500)] <colinclark> The bug is fixed, but there are a few last Ts to cross and Is to dot.
[11:55:38 EST(-0500)] <colinclark> I have a patch that cleans up the license files, includes a non-minified version of the swfobject.js library, and updates the build scripts to ensure any new files are included in the build.
[11:55:54 EST(-0500)] <colinclark> I will create a new JIRA issue for it momentarily and send it along to the channel.
[11:56:15 EST(-0500)] <colinclark> Then you can decide if you approve of me committing against it while trunk is so slushy.
[11:56:18 EST(-0500)] <colinclark> (smile)
[11:57:11 EST(-0500)] <Justin_o> sure... i'll check the jira... while you are doing that do you mind taking a look at FLUID-1940 i'm not sure if it is actually fixable or not
[11:57:19 EST(-0500)] <colinclark> Sure, no problem.
[11:57:30 EST(-0500)] <Justin_o> thanks
[12:01:00 EST(-0500)] <colinclark> Justin_o: FLUID-1940 should be fixable. Good catch!
[12:02:46 EST(-0500)] <Bosmon> I'm receiving an awful lot of "Facebook spam" this week
[12:02:55 EST(-0500)] <Bosmon> It looks like some critical number of people have uncovered me...
[12:02:55 EST(-0500)] <Justin_o> thanks...
[12:03:07 EST(-0500)] <colinclark> Bosmon: Jim Eng just recommended you as a Facebook friend to me. (tongue)
[12:03:09 EST(-0500)] <colinclark> Who knew you were really there lurking.
[12:03:18 EST(-0500)] <Bosmon> I am NOT really there (tongue)
[12:03:24 EST(-0500)] <colinclark> (smile)
[12:03:33 EST(-0500)] <colinclark> Justin_o: I can fix this as part of the bug parade if you want.
[12:03:41 EST(-0500)] <colinclark> Or someone can. It's really straightforward, I think.
[12:04:54 EST(-0500)] <Justin_o> colinclark: i'm in the process of some internal debate as to wether this should be in the bug parade or not
[12:04:55 EST(-0500)] <Bosmon> colinclark:
[12:05:00 EST(-0500)] <Bosmon> What ARE we going to do about FLUID-1616
[12:05:04 EST(-0500)] <Bosmon> (tongue)
[12:05:20 EST(-0500)] <colinclark> Lemme take a look.
[12:06:13 EST(-0500)] <anastasiac> the patch I created for FLUID-1616 simply renamed our 'selectable' to 'focusable'
[12:06:30 EST(-0500)] <Bosmon> Aha
[12:06:36 EST(-0500)] <Bosmon> It's a nasty name
[12:07:16 EST(-0500)] <colinclark> focusable?
[12:07:18 EST(-0500)] <colinclark> selectable?
[12:07:21 EST(-0500)] <anastasiac> yes, I remember we had some discussion, and at the time, couldn't come up with anything better
[12:07:29 EST(-0500)] <anastasiac> but we're certainly open to suggestions!
[12:07:42 EST(-0500)] <colinclark> Short-term, I think that's fine. I was sitting in the car the other day, brainstorming a real fix for this.
[12:07:44 EST(-0500)] <Bosmon> Perhaps we will simply have to give up on FLUID-539 and FLUID-861
[12:07:58 EST(-0500)] <Bosmon> They have come round for a few Bug Parades now
[12:08:11 EST(-0500)] <Bosmon> I mean, they are really serious
[12:08:21 EST(-0500)] <Bosmon> But I still can't think of any way of addressing them
[12:08:37 EST(-0500)] <colinclark> Ultimately jQuery needs namespaces for their plugins, and the UI strategy for doing this is insane. We can probably work something out so that our functions hang off a $().fluid.foo();
[12:08:48 EST(-0500)] <colinclark> Bosmon: Lemme remind myself of these issues.
[12:09:01 EST(-0500)] <Bosmon> You remember, the "tab black hole" issue
[12:09:02 EST(-0500)] <colinclark> They are clearly vintage based on their numbers.
[12:09:07 EST(-0500)] <Bosmon> Mainly on Firefoxes
[12:09:15 EST(-0500)] <Bosmon> We looked at it for a while when I was out there
[12:09:24 EST(-0500)] <colinclark> Ah yes
[12:09:34 EST(-0500)] <colinclark> Those are amazing issues.
[12:09:55 EST(-0500)] <Bosmon> We should probably try and find a way to escalate FLUID-861 to Mozilla
[12:10:04 EST(-0500)] <Bosmon> It looks like whatever they have done, 539 is gone "by itself"
[12:10:51 EST(-0500)] <colinclark> Bosmon: In FF3, you mean?
[12:11:06 EST(-0500)] <Bosmon> Yes
[12:11:18 EST(-0500)] <colinclark> Interesting.
[12:11:18 EST(-0500)] * hydee (n=hydee@bas10-ottawa23-1177650188.dsl.bell.ca) has joined #fluid-work
[12:11:25 EST(-0500)] <Bosmon> ok, yes, I like $().fluid.selectable
[12:11:54 EST(-0500)] <colinclark> Bosmon: Yes, exactly. Unless you find yourself with copious spare time, I think we're going to have to leave that particular approach for 0.8.
[12:12:14 EST(-0500)] <Bosmon> I can't think it would take long
[12:12:24 EST(-0500)] <Bosmon> And it is a Bug Parade issue
[12:12:38 EST(-0500)] <Justin_o> colinclark: i think for Fluid-1940 I'll leave it off for now until some of the other uploader bugs are cleared off the bug parade
[12:12:47 EST(-0500)] <colinclark> Bosmon: You don't have a lack of those, though. (wink)
[12:12:56 EST(-0500)] <Bosmon> I have some
[12:13:02 EST(-0500)] <Bosmon> I feel many of them are not actually resolvable (tongue)
[12:13:11 EST(-0500)] <colinclark> Talk through how you would implement this...
[12:13:29 EST(-0500)] <Bosmon> What would be hard about it?
[12:13:32 EST(-0500)] <colinclark> I'm just wondering whether anastasiac may have some time to implement it if you can guide her through the process a bit.
[12:13:47 EST(-0500)] <Bosmon> We would just write a slightly more bulky equivalent of the basic "fluid || {}" approach
[12:14:00 EST(-0500)] <colinclark> Bosmon: Ensuring correct scoping is key.
[12:14:05 EST(-0500)] * anastasiac is putting out a peptalk fire today
[12:14:13 EST(-0500)] <Bosmon> What do you mean?
[12:14:17 EST(-0500)] <Bosmon> JQuery has no sensible scoping
[12:14:22 EST(-0500)] <colinclark> Bosmon: (smile)
[12:14:25 EST(-0500)] <Bosmon> We could hardly make the situation worse over what it is now
[12:14:34 EST(-0500)] <Justin_o> colinclark: sorry don't remember if i mentioned this but I added FLUID-1942 to the bug parade
[12:14:50 EST(-0500)] <colinclark> At the moment, our code-like any plugin-expects that "this" points to the current jQuery instance.
[12:15:27 EST(-0500)] <colinclark> this will change if we hang our functions off a fluid object.
[12:15:31 EST(-0500)] <colinclark> no pun intended (wink)
[12:15:54 EST(-0500)] <colinclark> I suppose we could simply change that assumption. (smile)
[12:16:33 EST(-0500)] <colinclark> Bosmon: Go for it if you feel like you can tackle it.
[12:17:38 EST(-0500)] <Bosmon> Why will it change?
[12:17:44 EST(-0500)] <Bosmon> Well ok, it need not change
[12:17:51 EST(-0500)] <Bosmon> You're right that we have an option
[12:19:41 EST(-0500)] <colinclark> Bosmon: All bug parade issues need to go through a bit of code review before commit. I will be happy to review this one. (smile)
[12:20:59 EST(-0500)] <Bosmon> There are actually no references to "this" in our plugin
[12:21:01 EST(-0500)] <Bosmon> What a surprise (tongue)
[12:21:10 EST(-0500)] <Bosmon> Oh wait sorry
[12:21:13 EST(-0500)] <Bosmon> i hit the wrong key (tongue)
[12:21:26 EST(-0500)] <colinclark> Bosmon: There are!
[12:21:35 EST(-0500)] <colinclark> Fortunately, it is only at the top level.
[12:21:59 EST(-0500)] <colinclark> Any methods added to jQuery's prototype will reference this.
[12:22:03 EST(-0500)] <colinclark> "this"
[12:22:06 EST(-0500)] <colinclark> this
[12:27:47 EST(-0500)] <Bosmon> The word "prototype" just makes my head swim
[12:30:46 EST(-0500)] <colinclark> (smile)
[12:30:49 EST(-0500)] <Bosmon> Don't you think they will despise us, if we adopt a namespaced approach?
[12:31:56 EST(-0500)] <colinclark> Bosmon: I don't really know.
[12:32:01 EST(-0500)] <colinclark> I think it's something we really need.
[12:32:23 EST(-0500)] <colinclark> My sense is that our plugin will not be adopted wholesale and in its current form in ui.core.
[12:32:38 EST(-0500)] <Bosmon> Well, that is interesting
[12:32:41 EST(-0500)] <Bosmon> And somewhat exciting
[12:32:47 EST(-0500)] <colinclark> (smile)
[12:32:48 EST(-0500)] <Bosmon> What do you think is inhibiting its adoption?
[12:33:00 EST(-0500)] <Bosmon> Other than, of course, colliding head-on with the name of a now-existing plugin?
[12:33:00 EST(-0500)] <colinclark> Yeah, the tabindex code is now in ui.core.js
[12:33:08 EST(-0500)] <colinclark> As for inhibiting adoption, I'm not sure.
[12:33:10 EST(-0500)] <Bosmon> what?
[12:33:21 EST(-0500)] <colinclark> It's actually being picked up by a number of independent jQuery users.
[12:33:42 EST(-0500)] <colinclark> But, judging from comments on my blog post about it, the main barrier to adoption is lack of good documentation and sample code.
[12:33:46 EST(-0500)] <Bosmon> Does this mean we can abolish it?
[12:33:57 EST(-0500)] <colinclark> The tabindex code? Not yet, unfortunately.
[12:34:03 EST(-0500)] <colinclark> As far as I know, it won't be released until 1.7.
[12:34:07 EST(-0500)] <Bosmon> I see
[12:34:07 EST(-0500)] <colinclark> So we'll have to wait awhile.
[12:34:18 EST(-0500)] <Bosmon> Well, I guess this only enhances the pressure to namespace it
[12:34:20 EST(-0500)] <colinclark> Bosmon: As I think about this, our addition of a namespace has one major downside:
[12:34:24 EST(-0500)] <Bosmon> Since at that release, THAT will collide too
[12:34:28 EST(-0500)] <colinclark> how can we ensure backwards compatibility?
[12:34:46 EST(-0500)] <Bosmon> With what?
[12:34:46 EST(-0500)] <colinclark> We are essentially changing an API, and because UI has stolen our name, we have no recourse but to just do it.
[12:35:01 EST(-0500)] <Bosmon> With our own code?
[12:35:14 EST(-0500)] <Bosmon> How could we want to ensure backwards compatibility?
[12:35:27 EST(-0500)] <colinclark> Well, all code that used to call $("foo").selectable(...) will now have to change to call $("foo").fluid.selectable(...)
[12:35:36 EST(-0500)] <Bosmon> Yes
[12:35:39 EST(-0500)] <colinclark> Bosmon: Well, I guess that's my point.
[12:35:43 EST(-0500)] <Bosmon> How could we want backwards compatibility
[12:35:49 EST(-0500)] <Bosmon> Given that all code will break in any case
[12:35:49 EST(-0500)] <colinclark> We are forced to not want backwards compatibility.
[12:35:55 EST(-0500)] <Bosmon> Yes
[12:36:00 EST(-0500)] <colinclark> Ordinarily, we would never just change an API like this, on the fly.
[12:36:07 EST(-0500)] <Bosmon> Ordinarily not, no
[12:36:10 EST(-0500)] <colinclark> We'd at least deprecate the old method and keep it around for awhile.
[12:36:13 EST(-0500)] <colinclark> But in this case, we just can't.
[12:36:14 EST(-0500)] <colinclark> (sad)
[12:36:18 EST(-0500)] <Bosmon> But we have faced an Architectural Disaster (TM)
[12:36:23 EST(-0500)] <colinclark> Yes, exactly!
[12:37:37 EST(-0500)] <Bosmon> The Collapse of Civilization
[12:37:43 EST(-0500)] <colinclark> ha
[12:37:55 EST(-0500)] <colinclark> It's just proof of how jQuery plugins should have an option for using a namespace.
[12:38:01 EST(-0500)] <colinclark> Otherwise, people steal stuff.
[12:38:02 EST(-0500)] <colinclark> (wink)
[12:38:08 EST(-0500)] <Bosmon> OK
[12:38:14 EST(-0500)] <Bosmon> I will sit and think about this a little
[12:38:25 EST(-0500)] <colinclark> And $("foo").fluid("selectable") is just an intolerable solution. (tongue)
[12:38:36 EST(-0500)] <Bosmon> Yes, it is intolerable
[12:38:40 EST(-0500)] <Bosmon> We will refuse to tolerate it
[12:39:14 EST(-0500)] <Bosmon> Although I am becoming afraid again that a really good solution to this issue will rely on the Missing Javascript Feature....
[12:40:23 EST(-0500)] <Bosmon> I can think of a way of doing it with $("foo").fluid().selectable(stuff)
[12:40:27 EST(-0500)] <Bosmon> But that is not vastly better
[12:40:35 EST(-0500)] <colinclark> Bosmon: That's as far as I had gotten as well.
[12:40:37 EST(-0500)] <colinclark> (smile)
[12:40:39 EST(-0500)] <Bosmon> (smile)
[12:41:41 EST(-0500)] <Bosmon> Perhaps Javascript is not really Cool after all
[12:50:34 EST(-0500)] * ecochran (n=ecochran@adsl-70-137-176-52.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[12:58:42 EST(-0500)] <Bosmon> Well, do you have any other suggestions?
[13:16:32 EST(-0500)] <colinclark> Bosmon: I suppose we could resort to some sort of trickery, overriding the constructor and calling our own setup code at the end.
[13:19:56 EST(-0500)] <Bosmon> the constructor?
[13:20:08 EST(-0500)] <Bosmon> Which one?
[13:23:56 EST(-0500)] <colinclark> Bosmon: Sorry... jQuery's constructor.
[13:24:16 EST(-0500)] <colinclark> This is a terribly underhanded approach.
[13:26:13 EST(-0500)] <Bosmon> ouch
[13:26:33 EST(-0500)] <Bosmon> Do you really think we should do that?
[13:27:19 EST(-0500)] <colinclark> Bosmon: I'm not necessarily advocating for it, just exploring the space...
[13:27:33 EST(-0500)] <colinclark> Aside from a primeFluid() method or something, it may be our only option.
[13:32:06 EST(-0500)] * apetro (n=apetro@12.164.139.7) has joined #fluid-work
[13:33:15 EST(-0500)] <Bosmon> I suspect if we do anything that causes an extra construction for every jQuery construction, this would be unacceptable
[13:34:33 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[13:38:21 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[13:39:09 EST(-0500)] <Justin_o> I'll be adding two more jiras (numbers to come) to address the merging of dropdown and rich text inline edit into the component
[13:39:31 EST(-0500)] <Justin_o> we will need to set up appropriate demo pages to test on, as well
[13:40:09 EST(-0500)] <Bosmon> (18:34:34) Antranig: And there is a bit of an issue on making them testable
[13:40:09 EST(-0500)] <Bosmon> (18:34:45) Antranig: Which relates to where in our tree we put the underlying libraries
[13:40:09 EST(-0500)] <Bosmon> (18:34:51) Antranig: FCKEdit and TinyMCE etc.
[13:40:57 EST(-0500)] <Justin_o> Bosmon: thanks... I'll incorporate your comments into the jira
[13:45:57 EST(-0500)] <Justin_o> I have added FLUID-1944 and FLUID-1945 to the bug parade
[13:46:18 EST(-0500)] <Bosmon> Did anybody yet notice this function in jQuery.js?
[13:46:20 EST(-0500)] <Bosmon> // Evalulates a script in a global context
[13:46:20 EST(-0500)] <Bosmon> globalEval: function( data ) {
[13:46:27 EST(-0500)] <Bosmon> It appears to do exactly what we want...
[13:46:40 EST(-0500)] <Bosmon> Well, very nearly
[13:47:01 EST(-0500)] <Bosmon> I am just re-reading the Jquery source again to see if there is conceivably any solution to our problem...
[13:47:11 EST(-0500)] <Bosmon> But it seems there can't be
[13:47:17 EST(-0500)] <Bosmon> globalEval is still pretty interesting though
[13:54:38 EST(-0500)] <Justin_o> Bosmon: please let me know if you are still having trouble viewing the bug parade e-mail. If so, I'll attach a .txt version with the next update
[13:54:55 EST(-0500)] <Justin_o> i just sent out version 3 of the bug parade
[13:57:00 EST(-0500)] <Bosmon> Thanks, yes, it is completely unreadable (smile)
[13:58:03 EST(-0500)] <Justin_o> okay... i'll send add the .txt version...
[14:03:29 EST(-0500)] <Justin_o> Bosmon: I just sent out the .txt version of the bug parade... i hope that works.
[14:09:38 EST(-0500)] <Bosmon> Thanks
[14:23:41 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[14:24:22 EST(-0500)] <colinclark> Bosmon: I haven't seen globalEval before!
[14:24:30 EST(-0500)] <colinclark> I will have to look at its implementation.
[14:27:56 EST(-0500)] <Bosmon> Well, I guess we are going to have to bite the bullet somehow
[14:28:13 EST(-0500)] <Bosmon> $().fluid("selectable")?
[14:28:24 EST(-0500)] <Bosmon> $().fluid().selectable()?
[14:28:35 EST(-0500)] <Bosmon> $().fluid_selectable()?
[14:28:55 EST(-0500)] <Bosmon> We can go with $().focusable for now, but it doesn't help us with the general problem
[14:28:59 EST(-0500)] <Bosmon> That this is just going to happen again
[14:29:09 EST(-0500)] <colinclark> Bosmon: Yeah
[14:33:15 EST(-0500)] <colinclark> I'd rather change the API once and not several times...
[14:33:30 EST(-0500)] <colinclark> so .focusable() is probably short-sighted.
[14:33:47 EST(-0500)] <colinclark> .fluid-selectable() is one option.
[14:33:51 EST(-0500)] <colinclark> .fluid("selectable") is just dismal.
[14:34:05 EST(-0500)] <colinclark> .fluid().selectable() is a bit odd, but not tremendously bad.
[14:36:39 EST(-0500)] <ecochran> colinclark: working on 1936
[14:36:41 EST(-0500)] <Bosmon> fluid_selectable certainly involves little work
[14:36:48 EST(-0500)] <colinclark> So ecochran and I were just talking about an interesting potential browser bug related to Uploader.
[14:37:10 EST(-0500)] <colinclark> Bosmon: I prefer dashes to underscores. (tongue) But yes, I agree that it's the path of least resistance.
[14:37:33 EST(-0500)] <colinclark> ecochran: So you're saying that in order to get the click event on the Stop Upload Button once you've shown it, you need to mouse out first, and then click?
[14:37:43 EST(-0500)] <ecochran> yes, it's very odd
[14:38:01 EST(-0500)] <colinclark> So shouldn't we be able to see that behaviour even with the fact that currently clicking just causes an error?
[14:38:16 EST(-0500)] <ecochran> I'm still trying to figure out what's happening there, because in Uploader1 we were hiding and showing buttons all the time
[14:38:20 EST(-0500)] <ecochran> with out a problem
[14:38:53 EST(-0500)] <ecochran> yes, although there is another problem with the Stop Upload button in the current checking
[14:38:57 EST(-0500)] <ecochran> checkin
[14:39:02 EST(-0500)] <ecochran> it throws an error
[14:39:05 EST(-0500)] <Bosmon> colinclark: dashes are characters that would require quoting
[14:39:28 EST(-0500)] <colinclark> ecochran: Right, but that error is caused a result of the click event, doesn't it?
[14:39:35 EST(-0500)] <ecochran> yes
[14:39:39 EST(-0500)] <ecochran> which is interesting
[14:39:46 EST(-0500)] <colinclark> Bosmon: Ugh. Duh. Yes.
[14:40:08 EST(-0500)] <Justin_o> ecochran: i'm a little confused about what the behaviour your seeing is... is it different from the bug or the same
[14:40:17 EST(-0500)] <colinclark> ecochran: Let me play around here for a second and see if I can recreate it.
[14:40:17 EST(-0500)] <ecochran> let me look at build and see what's happening
[14:40:19 EST(-0500)] <Bosmon> colinclark: Our existing use of namespace is not all that great in our plugin anyway
[14:40:24 EST(-0500)] <Justin_o> by bug i meant the jira you mentioneed
[14:40:35 EST(-0500)] <Bosmon> For example, we have selectNext, selectPrevious, currentSelection
[14:40:43 EST(-0500)] <Bosmon> Which are all pretty implicitly tied to the fact this is a "selectable"
[14:40:57 EST(-0500)] <Bosmon> If we are going to have a 100% breaking change, we may as well do something rational about this too....
[14:42:19 EST(-0500)] <Justin_o> ecochran: by the way, which browser are you using
[14:42:31 EST(-0500)] <ecochran> I'm FF
[14:42:38 EST(-0500)] <colinclark> ecochran: I can't reproduce this, at least on FF2, even when I bind the click event to something that doesn't throw an error
[14:42:38 EST(-0500)] <Justin_o> 2 or 3
[14:42:39 EST(-0500)] <ecochran> the behavior seems inconsistent
[14:43:07 EST(-0500)] <ecochran> I don't seem to have to mouse off but at the same time the click doesn't seem to register
[14:43:09 EST(-0500)] <colinclark> Bosmon: I think that's reasonable, yes.
[14:43:12 EST(-0500)] <ecochran> all the time
[14:43:23 EST(-0500)] <colinclark> ecochran: 2 or 3?
[14:43:26 EST(-0500)] <ecochran> 3
[14:44:25 EST(-0500)] <colinclark> Interesting.
[14:44:35 EST(-0500)] <colinclark> I don't seem to be able to get my click event to work at all in FF3.
[14:44:39 EST(-0500)] <colinclark> Something odd is happening, for sure.
[14:44:56 EST(-0500)] <Justin_o> it worked the first time for me, but not after i looked at the error in firebug
[14:45:55 EST(-0500)] <ecochran> hmm, this could be another Firebug foo
[14:46:04 EST(-0500)] <ecochran> I get a lot of them
[14:46:14 EST(-0500)] <colinclark> Justin_o, ecochran: The button also doesn't seem to be in the tab order.
[14:46:19 EST(-0500)] <ecochran> I'm getting more events today than I was Friday
[14:46:24 EST(-0500)] <ecochran> it probably isn't
[14:46:25 EST(-0500)] <colinclark> Do you think it's possible that this is quirkiness related to buttons with no hrefs?
[14:46:38 EST(-0500)] <Justin_o> i too am not able to tab to it
[14:47:15 EST(-0500)] <ecochran> buttons don't have hrefs do they?
[14:47:57 EST(-0500)] <ecochran> the browse button isn't a real button, it's a <a> tag
[14:48:08 EST(-0500)] <ecochran> the Upload and Stop Upload are real buttons
[14:48:16 EST(-0500)] <ecochran> don't ask why... I don't remember
[14:48:22 EST(-0500)] <Justin_o> Okay i tried it in FF3 in vista, after it threw the first error i couldn't tab to it or get a click event
[14:48:29 EST(-0500)] <ecochran> I should have centered on one
[14:48:48 EST(-0500)] <colinclark> ecochran: Yes, of course. Sorry, I was thinking of links without hrefs.
[14:49:17 EST(-0500)] <colinclark> It seems to me that they should be in the tab order.
[14:49:21 EST(-0500)] <colinclark> Something very odd is happening.
[14:50:11 EST(-0500)] <ecochran> hold on, there may be some bad markup
[14:50:17 EST(-0500)] <ecochran> we're not validating
[14:50:25 EST(-0500)] <ecochran> let me poke at that for a minute
[14:51:12 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[14:53:42 EST(-0500)] <Justin_o> not sure if this helps at all but i suspended my firebug and i was able to tab to the stop upload button again, when i re-enabled it, i was no longer able to tab to the stop upload button
[14:55:59 EST(-0500)] <colinclark> Justin_o: !!!
[14:56:02 EST(-0500)] <colinclark> !!!!!!
[14:57:09 EST(-0500)] <ecochran> one moment, I need to feed Hannah
[15:00:56 EST(-0500)] <ecochran> back
[15:01:24 EST(-0500)] <ecochran> the lack of validation was because of stray thead and tfoot tags that have been removed
[15:01:31 EST(-0500)] <ecochran> but I don't think that they're going to change
[15:01:34 EST(-0500)] <ecochran> anything
[15:04:29 EST(-0500)] <ecochran> colinclark: one significant difference between the Uploader2 button implementation and the Upl1 implementation is that now we're hiding and showing the buttons by changing the class on the button itself and not on an element above
[15:05:03 EST(-0500)] <ecochran> again, probably a red herring
[15:05:24 EST(-0500)] <colinclark> ecochran: I guess it's hard to know without playing around a bit, but you're right that it seems unlikely.
[15:05:37 EST(-0500)] <ecochran> I do seem be getting better clicks now
[15:05:47 EST(-0500)] <colinclark> Now, as in when?
[15:05:49 EST(-0500)] <colinclark> (smile)
[15:06:03 EST(-0500)] <ecochran> well, hard to say with an intermittent bug...
[15:06:20 EST(-0500)] <ecochran> but since I cleaned up the stray theads and tfoots...
[15:07:03 EST(-0500)] <colinclark> aha
[15:07:03 EST(-0500)] <ecochran> I also put a console.log on the event on the button and I'm getting it every time
[15:07:06 EST(-0500)] <colinclark> that's interesting
[15:08:11 EST(-0500)] <ecochran> I have another problem which is that I think that I need to somehow send the stop message right away instead of just setting the "shouldPause" and waiting for the cycle to come around and stop
[15:08:29 EST(-0500)] <ecochran> since the wait makes it look like nothing has happened for a moment or two
[15:10:04 EST(-0500)] <ecochran> colinclark: yep, I can't reproduce the bug
[15:10:07 EST(-0500)] <colinclark> ecochran: I'd call that a low-priority issue for the release, since it is only applicable to the demo upload manager.
[15:10:10 EST(-0500)] <colinclark> But good point.
[15:11:34 EST(-0500)] <ecochran> yep, I'm going to check in what I have ... since it seems to be better (and doesn't throw the error) and fire up my server and see how I'm tracking against the server version
[15:12:48 EST(-0500)] <colinclark> ecochran: Have you written any pause code for the SWFUploadManager?
[15:13:36 EST(-0500)] <ecochran> no, not yet... I've been just working off the demo
[15:13:57 EST(-0500)] <colinclark> ecochran: So you'll find that the server version will just throw an error at this point.
[15:14:22 EST(-0500)] <ecochran> well, that's a good start
[15:14:27 EST(-0500)] <colinclark> (smile)
[15:14:58 EST(-0500)] <Bosmon> We believe in the theory of the ���Broken Windows��� by James Q. Wilson and George L. Kelling:
[15:14:58 EST(-0500)] <Bosmon> ���Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it���s unoccupied, perhaps become squatters or light fires inside.
[15:17:05 EST(-0500)] <colinclark> Are we averse to lighting fires or squatting?
[15:17:06 EST(-0500)] <colinclark> (tongue)