[09:01:15] <DaveMethvin> .
[09:02:33] <jzaefferer> hey Dave
[09:02:55] <jzaefferer> ping scott_gonzalez Krinkle johnbender
[09:03:12] <scott_gonzalez> .
[09:04:07] <johnbender> jzaefferer: hey
[09:04:34] <jzaefferer> Krinkle: initial notes?
[09:04:47] <Krinkle> http://bit.ly/qunitci
[09:04:50] <Krinkle> right ?
[09:05:03] <Krinkle> July 2 was empty
[09:05:07] <Krinkle> I added my notes there
[09:05:22] <Krinkle> that was the top section at the time
[09:05:26] <Krinkle> I didn't see the date
[09:05:51] <jzaefferer> oh, okay
[09:06:03] <jzaefferer> let's update that to today
[09:06:47] <jzaefferer> johnbender: any news from mobile and testing? did you update QUnit? any problems there?
[09:06:47] <Krinkle> ok
[09:08:20] <jzaefferer> Krinkle: any thoughts on reload the window, maybe even after each test? Was wondering if that could address of few of those unreproducibles
[09:08:35] <jzaefferer> Like the Illegal Arguments exception
[09:08:50] <jzaefferer> https://github.com/jquery/testswarm/issues/218
[09:08:50] <socialhapy> ★ Issue #218 on testswarm (jzaefferer; 4d, 8h ago): Reload run page after each run?
[09:08:59] <Krinkle> I doubt it, the iframe is being deleted and re-created after each test run
[09:09:23] <scott_gonzalez> Unless we can prove that's related, I don't think it's worth changing.
[09:09:27] <jzaefferer> and the error happens within the iframe, right?
[09:09:40] <scott_gonzalez> First step would be just running the failing test via the API and seeing what happens.
[09:09:47] <Krinkle> and I'd rather focus on the new run system rather than improving the current. i.e. the system where we go and work from inside the test suite page instead of hosting it from inside a long-live page
[09:09:53] <Krinkle> as that will fix the offset issues as well
[09:10:21] <Krinkle> and yes, we'd have to prove first that that's actually the cause
[09:10:33] <Krinkle> i.e. boot a new client that only does that one test, does it still happen?>
[09:10:40] <jzaefferer> you had a ticket for that new run system?
[09:10:59] <Krinkle> I don't have a ticket for the feature, I do have a ticket for the bug
[09:11:05] <Krinkle> https://github.com/jquery/testswarm/issues/195
[09:11:06] <socialhapy> ★ Issue #195 on testswarm (Krinkle; 1m, 3d ago): RunPage should not use iframes for testing
[09:11:09] <jzaefferer> I couldn't reproduce that IE9/effects issue with a regular browserstack client, not sure how to do that with the API
[09:11:34] <Krinkle> jzaefferer: regular browser stack client... using testswarm? or qunit directly
[09:11:41] <jzaefferer> using testswarm
[09:11:43] <Krinkle> ok
[09:11:51] <jzaefferer> as close as I could get, worked just fine
[09:12:15] <Krinkle> so when you reset the failed run table cell, and join in browserstack, it turns green?
[09:12:33] <jzaefferer> well, not, tested locally with my own testswarm instance
[09:12:37] <jzaefferer> *no
[09:12:40] <Krinkle> ah, ok
[09:13:17] <scott_gonzalez> Would creating a page with an iframe that loads http://swarm.jquery.org/build/jquery-ui/763a111552e5c02befd72a03b08cfc9ed06b7855/tests/unit/effects/effects.html?nojshint=true&jquery=git be pretty close?
[09:13:57] <Krinkle> scott_gonzalez: Could be, but what jzaefferer did is definitely closer. by actually using testswamr.
[09:14:05] <Krinkle> and that passed too
[09:14:16] <Krinkle> I'd say try reproducing with the live swarm
[09:14:21] <jzaefferer> Krinkle: mikesherov suggested making the runpage more barebones; browserstack API clients obviously don't care what the page looks like
[09:14:36] <Krinkle> log in as jquery and reset the failed job then refresh the browser window of the already running IE9 client and see what happens
[09:14:49] <jzaefferer> he found that the offset test failures were somehow related with bootstrap.css setting font-size on body
[09:15:02] <Krinkle> jzaefferer: with the new run system there won't be any run page, -> https://github.com/jquery/testswarm/issues/195
[09:15:03] <socialhapy> ★ Issue #195 on testswarm (Krinkle; 1m, 3d ago): RunPage should not use iframes for testing
[09:15:08] <jzaefferer> log in as jquery?
[09:15:15] <Krinkle> jzaefferer: on testswarm
[09:15:20] <scott_gonzalez> http://jsbin.com/izepec works in normal BrowserStack client.
[09:15:43] <scott_gonzalez> So iframe alone is not the problem.
[09:15:46] <jzaefferer> using authToken as password or something?
[09:16:38] <Krinkle> scott_gonzalez: well, if it works for jzaefferer on IE9 with his local testswarm install with all the variables we know from frames and testswarm and still passes, then it will likely also pass on a plain iframe or jzbin without all of testswarm around it
[09:16:39] <Krinkle> weird bug, IE!
[09:16:41] <Krinkle> jzaefferer: password
[09:16:58] <Krinkle> https://github.com/jquery/infrastructure/wiki/TestSwarm:-Install-&-Upgrade
[09:17:02] <Krinkle> password is there
[09:17:41] <jzaefferer> k, thx
[09:20:05] <johnbender> jzaefferer: I was working on my oscon preso this week
[09:20:16] <johnbender> though we did deal with a bug in firefox that was causing issues with testswarm
[09:20:18] <jzaefferer> now I just need that runtoken
[09:20:19] <johnbender> getting there
[09:20:31] <johnbender> haven't had time to do anything else
[09:20:37] <jzaefferer> johnbender: okay
[09:23:23] <Krinkle> jzaefferer: run token is not gettable, but its in testswarm-browserstack.run.sh
[09:23:49] <jzaefferer> scott_gonzalez: do you have anything else? otherwise we can probably just wrap this up, I'll keep in touch with Krinkle on those TestSwarm updates and setting up the new instance
[09:24:10] <Krinkle> there is 1 global run token
[09:24:31] <scott_gonzalez> jzaefferer: I don't think so.
[09:25:15] <jzaefferer> Krinkle: where is testswarm-browserstack.run.sh?
[09:25:23] <jzaefferer> don't see that in the tools folder anymore
[09:25:25] <Krinkle> srv-swarm/tools
[09:25:28] <Krinkle> oh ?
[09:25:31] <Krinkle> hm..
[09:26:00] <Krinkle> jzaefferer: ./tools/testswarm-browserstack/run.sh
[09:26:46] <jzaefferer> okay, got it
[09:27:58] <jzaefferer> okay, just ran that effects test in IE9 in browserstack, regular manual testing, passed
[09:28:00] <jzaefferer> same as local
[09:28:08] <jzaefferer> that just leaves to test with API
[09:29:04] <Krinkle> jzaefferer: easiest way to reproduce that is to do nothing :P
[09:29:21] <Krinkle> as long as there are no other pending runs, cron will run it and no other tests will run first or after
[09:29:37] <Krinkle> do reset it first tho
[09:29:56] <jzaefferer> right...
[09:35:48] <jzaefferer> mosted as status update: http://jquery.org/updates/2012/07/19/status-update-66/
[09:35:50] <jzaefferer> thanks everyone
[11:02:48] <toddparker> Hi everyone
[11:02:58] <uGoMobi> hi
[11:03:00] <gseguin> hiya!
[11:03:01] <MauriceG> Hi
[11:03:05] <toddparker> The jQuery Mobile meeting is starting
[11:03:27] <_|Nix|_> !gniP
[11:03:51] <MauriceG> !gnoP
[11:03:57] <toddparker> hey all
[11:04:10] <toddparker> wonder if johnbender and agcolom will be here
[11:04:29] <toddparker> So it's been pretty quiet on issues after 1.1.1 final which is great
[11:04:31] <agcolom> I'm here
[11:05:37] <toddparker> 1.2 is a bit delayed as we hash out a few final things
[11:06:03] <toddparker> I want to get the API stuff right before alpha because it's so much harder to change after
[11:06:16] <toddparker> i have a feeling popup will be very popular
[11:06:19] <toddparker> hey agcolom
[11:06:26] <agcolom> Hi everyone :-)
[11:06:40] <toddparker> so at this point, we're working on the position-to option
[11:06:59] <_|Nix|_> toddparker: OK, so it's final - it needs to be made into an option?
[11:07:41] <toddparker> just catching up on the dev channel
[11:07:54] <toddparker> seems like it _|Nix|_
[11:08:29] <_|Nix|_> toddparker: Okie-dokie! Can do.
[11:08:47] <toddparker> did johnbender seem to agree
[11:09:37] <toddparker> for background - we realized that, just like transition, the position-to option needs to be something you can set programmatically when you open a popup
[11:09:48] <_|Nix|_> toddparker: johnbender said that, when calling .open(), an object with properties "transition" and "positionTo" shall be passed in.
[11:09:50] <toddparker> the question now is exactly how to set this up
[11:09:58] <toddparker> ok, then we have a plan
[11:10:01] <toddparker> cool
[11:10:26] <_|Nix|_> toddparker: Adding an option to the .open() call is not the same as adding an option to the widget.
[11:10:27] <toddparker> other than this tweak and testing, any other popup items?
[11:10:46] <toddparker> right
[11:10:51] <uGoMobi> repositioning after resize/orientation change
[11:11:01] <uGoMobi> _|Nix|_: opened ticket for it
[11:11:09] <_|Nix|_> toddparker: If I add an option to the widget, you can do both <div data-role="popup" data-position-to="window">... and <a href="#popup data-position-to="#myTarget">
[11:11:10] <toddparker> right. that one is important
[11:11:32] <toddparker> gotcha
[11:11:39] <_|Nix|_> toddparker: In fact, positionTo was initially implemented as a widget option, but then I moved it to the link.
[11:11:54] <_|Nix|_> toddparker: So, I guess we want it to be just like transition - both in the widget and in the link.
[11:12:06] <toddparker> i do think we need to have a consistent pattern for this kind of thing
[11:12:14] <toddparker> i have a feeling it won't be the last situation
[11:12:19] <toddparker> ideally, yes
[11:12:36] <toddparker> the fact that they aren't consistent will cause us grief
[11:12:52] <_|Nix|_> toddparker: This makes sense for things that affect the behaviour of the popup, but not for things like overlayTheme and corners and shadow.
[11:13:03] <toddparker> yes, exactly
[11:13:10] <uGoMobi> i agree... there are a few other widgets that have options you can't set programmatically
[11:13:23] <_|Nix|_> I mean, theme, corners, and shadow cannot be taken from the link, because they refer to the buttons options, not the popup's :)
[11:13:26] <toddparker> things that are intrinsic to the widget stay there
[11:13:46] <toddparker> but behavior type stuff may also need to be on a link
[11:13:46] <_|Nix|_> toddparker: Setting options programmatically is another story altogether.
[11:14:04] <toddparker> yes
[11:14:09] <_|Nix|_> toddparker: Popup is in the special position that it has the open() method where you can pass temporary options.
[11:14:19] <toddparker> i'd like to beef up examples of calling things programmatically
[11:14:24] <toddparker> right
[11:14:30] <_|Nix|_> toddparker: But setting options programmatically also means implementing _setOption() on widgets.
[11:14:49] <_|Nix|_> toddparker: That's a whole other story, set aside for post-1.2 ...
[11:14:59] <toddparker> temporary options for that instance is the main concern here I think
[11:15:18] <toddparker> right, which you've suggested as an item for a future release
[11:15:41] <toddparker> roadmap item :)
[11:16:08] <toddparker> ok so let's get the option in, update the docs then move onto the orientation change stuff
[11:16:15] <toddparker> we can do a batch of testing once both are in
[11:16:16] <_|Nix|_> toddparker: Temporary values for options like "transition" and "positionTo" are fine by me, but I think we should be careful so we don't re-implement all options to be temporarily overrideable.
[11:16:25] <toddparker> sure. agreed _|Nix|_
[11:16:28] <toddparker> just those 2
[11:16:45] <_|Nix|_> toddparker: OK, and that batch of testing will be necessary too, because I did a lot of refactoring behind the scenes.
[11:17:21] <toddparker> yep, we'll do that once we're feature complete
[11:17:28] <toddparker> maybe monday?
[11:17:40] <_|Nix|_> toddparker: Which leads me to ask: What shall be the new name for the "popupbeforeopen" event?
[11:17:50] <_|Nix|_> toddparker: I will emit that event before repositioning the popup.
[11:17:59] <_|Nix|_> toddparker: So, "popupbeforeopen" is not really correct.
[11:18:12] <toddparker> because it might already be open
[11:18:14] <_|Nix|_> toddparker: ... and "popupbeforedecidingwheretoshowup" is kind of awkward.
[11:18:19] <toddparker> and we're re-displaying it
[11:18:34] <_|Nix|_> toddparker: or "popupbeforedecidingwheretogonext"
[11:18:39] <toddparker> popupbeforeposition was what i suggested
[11:18:58] <_|Nix|_> toddparker: OK. A bit longish, but not bad.
[11:19:00] <toddparker> popupbeforedisplay
[11:19:10] <_|Nix|_> toddparker: I prefer the former.
[11:19:11] <toddparker> odd one
[11:19:14] <toddparker> me too
[11:19:15] <_|Nix|_> toddparker: It's already displayed.
[11:19:19] <toddparker> right
[11:19:25] <toddparker> anyone else have ideas?
[11:19:27] <_|Nix|_> toddparker: ... in the case of orientationchange.
[11:19:30] <toddparker> right
[11:19:32] <uGoMobi> nah seems ok
[11:19:39] <toddparker> decided then
[11:19:42] <_|Nix|_> OK. popupbeforeposition it is.
[11:20:29] <toddparker> sold!
[11:20:46] <toddparker> so popups are square
[11:21:00] <_|Nix|_> toddparker: ... unless they have rounded corners ;)
[11:21:00] <toddparker> will you have time to work today/tomorrow on these?
[11:21:10] <_|Nix|_> toddparker: Sure!
[11:21:11] <toddparker> yikes
[11:21:19] <toddparker> awesome, thanks _|Nix|_
[11:21:24] <_|Nix|_> NP
[11:21:52] <toddparker> so i'd like to land the non-inset collapsible for 1.2 because it's a small code impact but a bigger feature
[11:22:08] <toddparker> because it will let you make what looks like a collapsible, nested list
[11:22:19] <toddparker> uGoMobi is giving that a look
[11:22:25] <uGoMobi> yes
[11:22:31] <toddparker> do you have the issue handy?
[11:22:31] <uGoMobi> not just a look
[11:22:42] <uGoMobi> will make it work :)
[11:22:48] <uGoMobi> hang on
[11:23:04] <uGoMobi> https://github.com/jquery/jquery-mobile/issues/3976
[11:23:05] <socialhapy> ★ Issue #3976 on jquery-mobile (sjdecaires; 3m, 1w ago): data-inset option for Collapsible / Collapsible sets
[11:23:38] <toddparker> exactly. you do.
[11:23:43] <toddparker> thanks for the link
[11:23:43] <uGoMobi> so it just means inset is going to be an option
[11:24:06] <uGoMobi> and we drop the -8px negative margin of the inset collapsibles
[11:24:15] <toddparker> right
[11:24:21] <uGoMobi> so it's consistent with other components
[11:24:28] <toddparker> inset will continue to be the default
[11:24:36] <uGoMobi> yes
[11:24:39] <toddparker> since that's how it works now
[11:25:02] <uGoMobi> might be a bit confusing... because for listviews its the other way around
[11:25:06] <toddparker> as part of this, i'd like you to build demos
[11:25:11] <toddparker> it is
[11:25:18] <toddparker> we're sort of backing into this
[11:25:26] <uGoMobi> yes can use demos from my test page
[11:25:34] <toddparker> nice
[11:25:39] <uGoMobi> that use will developing
[11:25:40] <toddparker> haven't seen that test page
[11:25:52] <uGoMobi> because it is still on localhost
[11:25:53] <toddparker> figure it'll be thorough :)
[11:25:55] <toddparker> ah
[11:26:03] <toddparker> cool
[11:26:05] <uGoMobi> I am not finished with code yet
[11:26:12] <toddparker> ok
[11:26:44] <toddparker> i'd like to test this along with the popup stuff early next week so we'll just coordinate on when both will be done
[11:27:01] <uGoMobi> will be no problem to have this done by monday
[11:27:06] <toddparker> awesoe
[11:27:10] <toddparker> awesome
[11:27:24] <toddparker> i have a few issues i wanted to run by you all
[11:27:45] <toddparker> this list view filter tweak - http://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjquery%2Fjquery-mobile%2Fissues%2F4721&sa=D&sntz=1&usg=AFQjCNGIdXQ2H5LrTUh1YKzvBappLJQt5g
[11:27:48] <toddparker> bah
[11:28:02] <toddparker> https://github.com/jquery/jquery-mobile/issues/4721
[11:28:03] <socialhapy> ★ Issue #4721 on jquery-mobile (nbigot; 21h, 59m ago): imporvement request : listview search field callback on keyup
[11:28:11] <uGoMobi> yeah I looked into that
[11:28:15] <toddparker> i hate that google has to dirty up every link for tracking
[11:28:18] <toddparker> yeah?
[11:28:21] <toddparker> and...
[11:28:36] <uGoMobi> actually I  gathered all feature request for list filter yesterday
[11:28:56] <uGoMobi> I think it's a nice feature
[11:28:59] <toddparker> really? we should look at them
[11:29:03] <toddparker> seems like it
[11:29:04] <uGoMobi> because you can keep your list short
[11:29:26] <uGoMobi> isFunction can be a variable I think so you dont check on every keyup
[11:29:50] <uGoMobi> in addition I think you should have an option to hide all list items on init
[11:30:07] <uGoMobi> because it's more like a live/instant search feature
[11:30:19] <uGoMobi> am I right?
[11:30:54] <toddparker> _|Nix|_ or gseguin - did you give this a look?
[11:31:08] <gseguin> I have not
[11:31:10] <_|Nix|_> toddparker: No, sorry - all popups here.
[11:31:31] <toddparker> so it sort of makes it possible to do an autocomplete
[11:31:40] <uGoMobi> yeah
[11:31:42] <toddparker> with remote data
[11:32:06] <uGoMobi> it is meant for if you have a lot of data
[11:32:11] <toddparker> gseguin: do you have time to give this a look and see if it's worth adding
[11:32:12] <toddparker> yeah
[11:32:25] <gseguin> put it on my plate
[11:32:31] <toddparker> but if we can get a lightweight hook to make an autocomplete, that's cool
[11:32:31] <gseguin> I'll get to it next
[11:32:33] <uGoMobi> so that's why it makes sense to hide all when the listview is enhanced
[11:32:39] <toddparker> esp. if we can build a simple demo
[11:32:41] <toddparker> yep
[11:32:50] <gseguin> I'll see with Bender what he thinks too
[11:33:12] <toddparker> ok tagged to 1.2 and gseguin as a possible feature
[11:33:14] <toddparker> cool
[11:33:29] <toddparker> seems like that guy might be willing to help with this if needed
[11:33:38] <uGoMobi> yes
[11:34:05] <toddparker> cool
[11:34:08] <uGoMobi> this is one of the other requests https://github.com/jquery/jquery-mobile/issues/3303
[11:34:09] <socialhapy> ★ Issue #3303 on jquery-mobile (lijumathews; 7m, 1h ago): Iphone : Go button does not close the keyboard with Data filter
[11:35:02] <toddparker> right. i like that idea too
[11:35:08] <toddparker> it should do something
[11:35:16] <toddparker> so on submit, blur the input
[11:35:51] <toddparker> gseguin: i moved this one to you since they are both filter tweaks
[11:35:52] <uGoMobi> yes and focus on first item
[11:35:56] <toddparker> right
[11:36:09] <toddparker> seems easy to add and a nice usability improvement
[11:36:14] <gseguin> ok
[11:36:46] <uGoMobi> want the links to the two other related tickets here for reference?
[11:37:14] <toddparker> sure
[11:37:18] <uGoMobi> https://github.com/jquery/jquery-mobile/issues/4539
[11:37:19] <socialhapy> ★ Issue #4539 on jquery-mobile (row1; 1m, 2d ago): Listview with initially hidden items no longer works
[11:37:24] <uGoMobi> https://github.com/jquery/jquery-mobile/issues/4133
[11:37:25] <socialhapy> ★ Issue #4133 on jquery-mobile (cjindustries; 2m, 4w ago): Listview - only use 'lastval' functionality with default filter behaviour
[11:38:31] <toddparker> ok, all assigned to gseguin
[11:38:44] <toddparker> last time you ever volunteer
[11:38:51] <gseguin> :)
[11:38:56] <uGoMobi> haha
[11:38:59] <gseguin> I WILL FIX THEM ALL!
[11:39:11] <toddparker> DO IT
[11:39:12] <uGoMobi> just so you don't get bored in Bolder gseguin ;)
[11:39:20] <toddparker> ok, next item
[11:39:21] <toddparker> ScrollSuppression - change from 10 to 30? 50?
[11:39:28] <toddparker> https://github.com/jquery/jquery-mobile/issues/2107#issuecomment-7085452
[11:39:29] <socialhapy> ★ Issue #2107 on jquery-mobile (adriancd; 1y, 1d ago): scrollSupressionThreshold - scrolling smoothness impact
[11:39:36] <toddparker> i spent a bunch of time testing this yesterday
[11:39:50] <toddparker> in a nut, this doesn't effect normal listviews
[11:40:02] <uGoMobi> to celebrate the tickets one year birtday?
[11:40:08] <toddparker> but if you bind to the swipe events, this 10px tolerance is very tight
[11:40:15] <toddparker> we need a cake!
[11:40:21] <uGoMobi> :D
[11:40:52] <toddparker> i was testing a nexus 7 and was frequently moving 30, 50, even 100 pixels when scrolling with my thumb
[11:41:07] <gseguin> 10px seems too small
[11:41:12] <toddparker> yeah
[11:41:27] <gseguin> what's the size of a regular finger?
[11:41:39] <toddparker> nexus 7 has 800px of resolution so if you move 1/4 of the screen width, it's 200px
[11:41:44] <toddparker> 44px
[11:41:46] <toddparker> :)
[11:41:53] <toddparker> tap target
[11:42:15] <_|Nix|_> We had a rule-of-thumb ( ;) ) at Nokia: 70px x 70px to make something finger-friendly.
[11:42:18] <toddparker> on android, you can turn on dev tools that show you the touch and drag path as well as the X and Y distance
[11:42:36] <toddparker> that's huge, especially on a lower res screen
[11:42:59] <toddparker> so there is no science here exactly, but it seems that we should bump up this tolerance
[11:43:20] <toddparker> 30-50 seems more reasonable
[11:43:46] <toddparker> we really need to build a demo/test page for events
[11:43:54] <toddparker> anyone want to take a crack at that?
[11:43:57] <toddparker> for the docs?
[11:44:21] <uGoMobi> I was planning on tests for docs
[11:44:43] <uGoMobi> so I can give that priority
[11:44:46] <toddparker> we need an interactive logger that lets you see events
[11:44:48] <uGoMobi> after collapsibles
[11:44:54] <toddparker> sure, sounds great
[11:45:06] <toddparker> in the meantime, should we just bump this up?
[11:45:15] <toddparker> maybe to 30?
[11:45:21] <gseguin> +1
[11:45:31] <toddparker> +1
[11:45:46] <uGoMobi> sounds good +1
[11:45:51] <agcolom> +1
[11:46:05] <toddparker> ok, cool
[11:46:22] <toddparker> i might make this change for 1.2 only
[11:46:27] <toddparker> since it changes behavior
[11:46:53] <toddparker> i'll do it
[11:46:56] <toddparker> ok, next
[11:47:00] <toddparker> Symbian^3
[11:47:13] <uGoMobi> yeah I reopened
[11:47:13] <toddparker> i think need to clarify version, this covers a wide range of devices
[11:47:21] <gseguin> toddparker: anything else for me, I need to drop off
[11:47:25] <toddparker> S^3 has been around for years
[11:47:31] <toddparker> nope gseguin
[11:47:41] <toddparker> i just tested on one S^3 and it's fine
[11:47:45] <gseguin> alright see y'all on -dev
[11:47:48] <toddparker> an older one, not so much
[11:48:02] <uGoMobi> I think I still have an Nokia N95 here that runs symbian v3
[11:48:04] <toddparker> so I'll dial in the version a bit in the support matrix
[11:48:17] <toddparker> can you see if /test/ renders?
[11:48:24] <toddparker> or errors out
[11:48:37] <uGoMobi> yes, will test
[11:48:54] <uGoMobi> but this is not very high priority, right?
[11:48:54] <toddparker> thanks!
[11:48:58] <toddparker> nah
[11:49:01] <toddparker> just curious
[11:49:02] <uGoMobi> market share?
[11:49:09] <toddparker> prolly decent
[11:49:21] <uGoMobi> but testing doesn't take much time, if the device still works
[11:49:24] <toddparker> right
[11:49:33] <toddparker> if it looks enhanced, done
[11:49:43] <toddparker> either way, send me detailed device info
[11:49:45] <uGoMobi> ok
[11:50:07] <toddparker> that's all i had
[11:50:17] <toddparker> agcolom: are you still plugging away on docs?
[11:50:22] <agcolom> yes
[11:50:26] <agcolom> on the api docs, the 9th widget (select) is up but not 100% complete (just need a bit more text on custom select).
[11:50:38] <uGoMobi> is all popup docs stuff clear now?
[11:50:39] <toddparker> are you involved in the site cleanup at al right now?
[11:50:48] <toddparker> i think so uGoMobi
[11:50:50] <agcolom> but the jquery guys have made lots of changes!
[11:50:57] <toddparker> we'll update the docs a bit after _|Nix|_ is done
[11:51:03] <uGoMobi> ok
[11:51:09] <toddparker> a lot of changes to your docs?
[11:51:09] <agcolom> so I've lost all syntax highlighting.
[11:51:14] <toddparker> right. saw that
[11:51:26] <toddparker> they are switching out to a different highlighter
[11:51:41] <agcolom> so i guess I need to install SyntaxHighlighter ?? instead of Pygmentize??
[11:52:17] <agcolom> We had a chat about the demos, so we agreed on a specific structure....
[11:52:24] <toddparker> great
[11:52:29] <toddparker> ask richard about that?
[11:53:07] <agcolom> I tried to have an iframe with as we agreed, but I get a 404, so I think I need to check with Richard and Karl...
[11:53:13] <toddparker> ok
[11:53:13] <agcolom> maybe others too...
[11:53:25] <agcolom> the fonts also seem to have been changed...
[11:53:41] <uGoMobi> iframe :(
[11:53:48] <toddparker> not pretty
[11:53:57] <toddparker> but i can see why
[11:54:26] <toddparker> ok, any other questions from the team or community?
[11:54:28] <agcolom> so I think that's what I'll be doing... getting the syntax highlighting back in and getting the iframe source to be picked up properly....
[11:55:07] <uGoMobi> MauriceG you were working on new PR for the listview options, right?
[11:55:30] <_|Nix|_> toddparker: One more thing - a small matter of semantics wrt. positionTo ...
[11:55:40] <_|Nix|_> toddparker: ... but it can wait until after ...
[11:55:41] <toddparker> yessss...
[11:55:46] <toddparker> ok
[11:56:15] <toddparker> MauriceG: do you have time to update the change log for 1.2 for early next week?
[11:56:25] <toddparker> what you have now is awesome
[11:56:50] <MauriceG> Yes, I think.
[11:56:52] <uGoMobi> toddparker: some listview options don't seem to work as they should and it would be nice if you can set the icon for whole listview instead of having to add data-attr on every list item
[11:56:59] <toddparker> that would be great
[11:57:09] <toddparker> uGoMobi: i agree on that
[11:57:40] <toddparker> let's discuss in -dev
[11:57:52] <toddparker> alright everyone, think we're going to wrap up
[11:57:52] <uGoMobi> k
[11:57:58] <toddparker> thanks all!
[11:58:05] <toddparker> i'll post notes in a bit
[11:58:12] <_|Nix|_> Cool ...
[11:58:17] <uGoMobi> thanks
[11:58:26] <MauriceG> thanks
[11:58:36] <toddparker> go team