#jquerymobile-dev_20110531.txt

[04:09:56] <jzaefferer> anyone around who can tell me how the animated spinning loading icon works in jQuery Mobile? all I find is the non-animated png (themes/default/images/ajax-loader.png)
[07:58:19] <StevenBlack> meeting today at 2PM?
[08:41:33] <kinblas> mornin'
[08:41:34] <bot-t> (44 hours 10 mins ago) <StevenBlack> tell kinblas: Here's a compendium of issues we would need to resolve in order to breakout success and error callbacks from the mainline $.ajax() call. https://github.com/jquery/jquery-mobile/wiki/Refactor:-Ajax-callback-breakout
[10:47:56] <scottjehl> hi guys - putting together a quick meeting agenda
[10:48:05] <scottjehl> anything to add?
[10:48:13] <scottjehl> what're people working on?
[10:48:27] <kinblas> I'm working on path stuff
[10:48:48] <kinblas> covers base tag, links, forms, relative urls, etc
[10:52:57] <eddiemonge> im working on design stuff (css fixes)
[10:53:03] <scottjehl> working on it here https://docs.google.com/document/d/1xCuuO3Z7V5HExiBjveG5CKUO94IMsdJVixffogSMrVU/edit?authkey=CL3GnvYK
[10:53:13] <scottjehl> please chip in if you can :)
[10:56:02] <kinblas> scottjehl: data cache was Steven
[10:56:12] <scottjehl> got it
[10:56:13] <kinblas> nevermind, you changed it
[10:56:33] <scottjehl> are you anon?
[10:56:37] <scottjehl> heh
[10:57:32] <kinblas> yeah I guess, I haven't logged in
[10:59:36] <kinblas> scottjehl: apparently you have to give specific folks permission to edit, otherwise they appear as anonymous
[11:00:00] <scottjehl> k
[11:00:03] <scottjehl> google names?
[11:00:08] <kinblas> yeah
[11:00:16] <scottjehl> "kinblas"?
[11:00:48] <kinblas> oh I guess you see me then :-)
[11:01:09] <scottjehl> no I was looking for your google name
[11:02:06] <StevenBlack> It would be great if the agenda was up a day prior, as opposed to 7-minutes prior.
[11:06:25] * kinblas nominates StevenBlack as the day-before-agenda-gatherer-and-poster
[11:06:32] <kinblas> :-)
[11:06:40] <StevenBlack> Accepted.
[11:06:43] <scottjehl> Hey Steven. Just trying to fill in best i can. Todd's out this week
[11:07:12] <StevenBlack> Maybe we should do what core does: always use the same document, prepending new meetings.
[11:19:22] <scottjehl> nice idea
[11:19:23] <scottjehl> sure
[12:14:42] <scottjehl> hey everyone
[12:14:58] <scottjehl> feel free to continue here.
[12:22:30] <StevenBlack> So as I was saying ( er, insinuating? ) we need to up the mo a bit here.
[12:23:22] <StevenBlack> Pull requests are going stale, for one thing.
[12:23:29] <StevenBlack> Very stale.
[12:24:49] <eddiemonge> i think the problem with that is its hard to test the changes on all the platforms. that and i think we need more unit tests
[12:27:01] <StevenBlack> For example, I have a week-old whitespace standards upgrade in-waiting with (say) a hundred adjustments and there is a comment from you quibbling over the single one I missed.  Meanwhile non-standards compliant code is being checked-in left and right.
[12:27:26] <StevenBlack> This is exactly the file I need to touch, along with two others, to resolve ?docs#m1544.
[12:27:27] <bot-t> StevenBlack, JavaScript??????????????_????? - http://www.codefans.net/jscss/code/302.shtml
[12:28:09] <StevenBlack> What chance does my work stand if a friggin whitespace pull rots for a week on the vine.  I can't even use a standards-compliant file to code-in.  I mean, c'mon!
[12:28:33] <eddiemonge> ?m1544
[12:28:34] <bot-t> [#1544] Transitions to standard (closed) - https://github.com/jquery/jquery-mobile/issues/1544
[12:28:47] <StevenBlack> Sorry ?m1554
[12:28:57] <StevenBlack> fffffuuuu
[12:29:02] <StevenBlack> ?m1554
[12:29:03] <bot-t> [#1554] Implement data-cache=false attribute on pages. (open, 6 - Blocker, stevenblack) - https://github.com/jquery/jquery-mobile/issues/1554
[12:29:09] <eddiemonge> its " see ? m1554
[12:29:10] <bot-t> [#1554] Implement data-cache=false attribute on pages. (open, 6 - Blocker, stevenblack) - https://github.com/jquery/jquery-mobile/issues/1554
[12:29:51] <StevenBlack> mo-less.
[12:43:16] * kinblas wonders what "mo" is?
[13:06:46] <gseguin> StevenBlack: what is "mo"? motion, momentum, motivation?
[13:08:04] <kinblas> StevenBlack: regarding your whitespace changes, is there some way you can work with folks to time them better? LIke maybe just before we push out a release when folks aren't in a crunch trying to get features/fixes for the release done?
[13:09:42] <kinblas> I know they you consider them "simple" changes, but someone still has to eyeball them, etc, to make sure nothing was accidentally deleted. And when you touch hundreds of lines in a file, it throws off the git "BLAME" feature which helps some of us trying to track down why a particular block or line is the way it is ... by throw off, I mean it forces folks to navigate the commits which
[13:09:42] <kinblas> is kind of clumsy in git
[13:11:55] <kinblas> gseguin: is now a good time to talk about that patch?
[13:12:15] <gseguin> don't we want StevenBlack to be here too?
[13:12:34] <kinblas> < shrug > it's up to you, I just wanted to talk about your patch
[13:12:38] <gseguin> sure
[13:12:41] <kinblas> but if you guys are going to re-work it to make it more generic
[13:12:46] <kinblas> I can wait
[13:13:11] <gseguin> let me refresh my memory as to why I used $.expando
[13:13:46] <kinblas> I think that was left-over from the previous pull request?
[13:13:58] <kinblas> it's not updated anywhere in your current patch
[13:17:22] <gseguin> oh yeah it was an attempt to generate a uid for the parent
[13:17:32] <gseguin> but that expand is a random number
[13:17:51] <gseguin> so it'll work within the current link
[13:17:59] <gseguin> but not for deep linking
[13:19:07] <kinblas> gseguin: I'm not sure I follow. $.expando is a random number that's generated when jQuery is loaded
[13:19:20] <kinblas> so if you look for that property on parentPage[0]
[13:19:33] <gseguin> yep, so it's unique to the current execution of jQuery
[13:19:35] <kinblas> it might not have any value there right?
[13:19:49] <kinblas> that is, it returns undefined
[13:20:08] <kinblas> parentPage[0][$.expando]
[13:20:12] <kinblas> is what I'm referring to
[13:20:18] <gseguin> it returns 2
[13:20:28] <gseguin> sorry it returns something
[13:21:12] * gseguin is pulling up the code
[13:22:17] <kinblas> gseguin: it looks like that only gets set on items that have .data() on them
[13:22:36] <kinblas> so I guess my question is this, if all pages have data-url set on them, why do we need that?
[13:24:57] <gseguin> if we're garanteed to have  a data-url on the parentPage then I guess we don't need that
[13:26:27] <kinblas> the data-url is currently required for the system to find it
[13:26:35] <kinblas> to find a page that is
[13:32:29] <gseguin> kinblas: I'm putting together a jsfiddle
[13:32:55] <kinblas> gseguin: also the whole bug is because we can't tell the difference between sub-lists in top-level lists of a page
[13:33:20] <kinblas> gseguin: the patch is incrementing the listCountPerPage based on the sub-lists, not the top-level lists
[13:33:51] <kinblas> That is,  list inside of that function tha creates the id, is the sub list, not the outer one
[13:34:28] <gseguin> the key is parentId
[13:34:35] <gseguin> which is the top-level list
[13:34:59] * gseguin notices that jsfiddle.net has gone missing
[13:35:12] <kinblas> gseguin: but parentPage is the actual jQM page, not a list
[13:35:42] <gseguin> correct
[13:35:52] <gseguin> so you're saying the logic is wrong
[13:36:23] <kinblas> gseguin: not so much wrong, but taking a step back and thinking about what it is that needs to be fixed for the bug
[13:36:37] <StevenBlack> kinblas: Um, WTF?  No non-conformant code should be checked-in in the first place. Secondly, I always check the file history and I NEVER work on a file that's in flux.  If that's a problem, then folks need to get with git because it's a cardinal sin to not refresh from HEAD before making changes.  TL;DR: I'm always careful.
[13:36:37] <kinblas> each sub list already has a unique identifier ... the 'i' being passed in
[13:37:07] <kinblas> StevenBlack: what's with the tone?
[13:37:30] <StevenBlack> kinblas: Also, FYI< I always run a full suite of tests on what I change before issuing the pull request.
[13:37:44] <StevenBlack> There's just no excuse.
[13:38:21] <StevenBlack> I'm not the one who ever checks-in non-standard code.
[13:39:02] <kinblas> non-standard-formatted code?
[13:39:17] <gseguin> kinblas: you wanna resume later?
[13:39:26] <StevenBlack> http://docs.jquery.com/JQuery_Core_Style_Guidelines
[13:39:28] <kinblas> gseguin: no, go on, I'll focus
[13:39:37] <gseguin> ok
[13:39:50] <kinblas> if someone would've pointed that out when I started, I would've followed it to the tee, and mind you I didn't write all of the code in question
[13:40:47] <gseguin> yeah so the i is the index of the top-level list
[13:41:03] <StevenBlack> Understood.
[13:41:05] <kinblas> gseguin: So what I was wondering was if the id/count thing should be based on the outer list since that is the only thing we need
[13:41:43] <kinblas> StevenBlack: And I never said that you didn't run tests or check your work
[13:41:56] <kinblas> all I said was that anyone who lands *ANY* patch is responsible for looking over every line
[13:42:09] <kinblas> I don't want to talk about this anymore, the tone is really irking me
[13:42:36] <StevenBlack> kinblas: excuse me?  https://github.com/jquery/jquery-mobile/commits/master/js/jquery.mobile.dialog.js
[13:42:49] * gseguin is thinking about it, looking at the code
[13:43:07] <StevenBlack> The file was static for a month before I looked at it and reformatted it.  All of a sudden, this is a problem?
[13:43:51] <StevenBlack> Look, all I'm asking is for everyone to up their game a little.
[13:43:59] <StevenBlack> It's not a big ask.
[13:57:27] <gseguin> kinblas: so are you saying that I should use i as a key as opposed to using parentId?
[13:57:54] <kinblas> no I just meant that i is already unique to each list inside the top-level list
[13:58:23] <kinblas> so all I think we need is to make sure that we get an id for the outer list and use that in final data-url/id you create
[13:58:41] <kinblas> I think right now you are getting the id of the sub-list and adding that to the unique number for the sub-list (i)
[13:59:29] <kinblas> or is the point of that to leverage any ids on the sublists if existing?
[13:59:36] <kinblas> for deep linking?
[14:00:05] <gseguin> yup that was the point
[14:00:32] <kinblas> ok
[14:00:56] <kinblas> so the last question
[14:01:19] <kinblas> ... "refresh" can be called on a listview anytime someone augments the list manually
[14:01:42] <kinblas> refresh triggers the code you touched ... just make sure it works correctly in that case too.
[14:03:04] <gseguin> ok will do
[14:04:16] <gseguin> kinblas: so are you dropping the " id/count thing should be based on the outer list"?
[14:04:36] <kinblas> sure if the point is deep linking
[14:04:48] <kinblas> it was more of an interactive question ;-)
[14:04:59] <kinblas> not pointing out something wrong
[14:05:41] <gseguin> ok
[14:05:54] <kinblas> gseguin: so we're going to lose the expando reference?
[14:06:13] <kinblas> gseguin: and if so, do we need the extra pageId versus pageUrl that scott had there before?
[14:06:20] <gseguin> I don't think so
[14:06:24] <kinblas> ok
[14:06:27] <gseguin> this is a fallback
[14:07:04] <kinblas> does it need the fallback? That is, have you run across a case where data-url wasn't set?
[14:07:17] <gseguin> unless I use parentUrl as the key
[14:07:19] <kinblas> the original code wasn't using expando, that's why I'm asking
[14:08:07] <gseguin> yeah it was relying on parentUrl which can be undefined
[14:08:49] <kinblas> aha, that's what I was getting at ... so when is it undefined? All pages should have a data-url on them as far as I know
[14:09:31] <gseguin> hmm... that I don't remember let me check my test file
[14:11:11] * gseguin says yay! jsfiddle.net is back
[14:20:11] <kinblas> StevenBlack: your whitespace changes landed. I had to fix conflicts so you may want to check that I didn't screw it up
[14:30:31] <StevenBlack> Thanks, kinblas.
[14:32:00] <StevenBlack> This is exactly the sort of thing that interferes with everyone if it's allowed to rot on the vine because it affects almost every line.   Then there's me, who can't work on the file I myself remediated because it remained unpulled.  That's frustrating, and it shows.
[14:32:29] <StevenBlack> ==============
[14:33:53] <StevenBlack> An interesting issue that didn't make the agenda: do we want to stay abreast of jquery.ui.widget.js which is now at the 1.8.13 tag?
[14:34:32] <StevenBlack> I have this in branch here and the apps all work but the tests all fail because the widget API changed from under us.
[14:35:05] <StevenBlack> Unit tests mostly fail, I should say, and for the most part it's old API calls.
[14:37:15] * StevenBlack is thinking this past holiday weekend would have been a golden opportunity to transition tests to the new API and bring the jQuery Mobile back in-sync.
[14:39:03] <gseguin> kinblas: take a look at http://jsfiddle.net/ghislain/ZMBtE/show/light/
[14:39:15] <StevenBlack> TAKE NOTE: if we don't bring jquery.ui.widget.js back in-sync then we should rename it to jquery.mobile.widget.js otherwise the implied linkage is a red-herring.
[14:40:42] <gseguin> kinblas: I just broke it
[14:42:25] <gseguin> kinblas: fixed now
[14:43:19] <eddiemonge> can someone land this: https://github.com/jquery/jquery-mobile/pull/1724/files
[14:49:51] <kinblas> gseguin: just took a look
[14:50:07] <gseguin> did you see the undefined ?
[14:50:23] <kinblas> that's different from the patch you submitted ... this one has the problem where the list id/number depends on the order you visit pages right?
[14:50:28] <kinblas> eddiemonge:done
[14:50:38] <gseguin> correct, but the undefined is there
[14:50:53] <kinblas> hmmm I didn't notice
[14:50:57] <kinblas> hang on let me try again
[14:51:29] <gseguin> put a breakpoint on the file light:36
[14:51:29] <kinblas> gseguin: I"m not seeing undefined
[14:51:31] <kinblas> here's what I get
[14:51:33] <kinblas> http://jsfiddle.net/ghislain/ZMBtE/show/light/#subpage=0-0
[14:51:42] <kinblas> and
[14:51:42] <kinblas> http://jsfiddle.net/ghislain/ZMBtE/show/light/#subpage=1-0
[14:52:00] <gseguin> that's because when I generate the id I filter out undefined
[14:52:26] <gseguin> but there is no data-url on the first page
[14:52:34] <gseguin> because it's got no id
[14:52:52] * gseguin is remembering now
[14:53:27] <gseguin> so if you have 2 pages without id and you use parentId as a key
[14:53:40] <gseguin> you end up incrementing the wrong counter
[14:53:56] <gseguin> that's why I was using the $.expando as a fallback
[14:54:14] <gseguin> let me upgrade the fiddle to that patch
[14:55:17] <gseguin> kinblas: done
[14:56:58] <kinblas> ah ok, the first page, embedded in the document, has not data-url to prevent us from always placing the #
[14:57:08] <kinblas> man I can't type today
[14:57:18] <kinblas> excuse my grammar
[14:57:20] <kinblas> :-)
[14:57:36] <kinblas> I think that is the only case
[14:57:48] <kinblas> you may want to just assign it a fixed key for that case
[14:57:51] <kinblas> "first-page"
[14:57:53] <kinblas> or something like that
[14:58:02] <kinblas> just for the lookup that is
[14:59:20] <gseguin> but what if the second page doesn't have an id either?
[14:59:42] <kinblas> it has to, otherwise we can't navigate to it
[14:59:51] <kinblas> first page is the exception
[15:00:08] <kinblas> because we don't want to have urls that have #first-page right when you load the document
[15:00:30] <gseguin> ok
[15:00:42] * kinblas confirms with scott
[15:02:10] <gseguin> so that "adding a fixed key" thing needs to happen as part of another changeset, right?
[15:02:24] <gseguin> I mean it has very few to do with my bug
[15:08:53] <kinblas> gseguin: hold on, I'm talking to someon out of band (sorry)
[15:09:01] <gseguin> ok