[20:04:27] for example^^ [20:04:46] aha java.net.MalformedURLException … i'm parsing this xml wrong :) [20:04:54]

[20:04:58] changing to^^? [20:05:00] basically Steinsplitter move that div above the template [20:05:23] ah, okay. Thank you! [20:05:41] the template is introducing an element above it which has not been marked as being appropriate for mobiel [20:05:51] it's tacky but the main page special casing is hacky and i hate it [20:06:05] okay. Thank you for helping [20:08:12] jdlrobson: done but dos not work :-( [20:10:36] speaking of heading formatting... YuviPanda and brion, would the lack of edit link removal affect the app? [20:10:58] uhhhhh, lack of removal from what exactly? [20:11:01] MaxSem: App uses the API only now, so... [20:11:03] don't think so [20:11:13] YuviPanda, API output is also affected [20:11:26] oh? action=mobileview will get edit links? [20:11:28] yep [20:11:40] okay. whatever "revert" :D [20:11:41] MaxSem: where will these links be, exactly? [20:11:53] jdlrobson: thx for helping [20:12:03] whre they are usually on desktop site [20:12:10] so.... [20:12:17] sections are split up into separate chunks [20:12:28] which don't include the regular header markup, if i recall [20:12:31] do they? [20:12:53] what parameters does the app use for action=mobileview, exactly? [20:13:11] let's look it up [20:14:20] MaxSem: https://gist.github.com/brion/5887733 [20:15:00] hmm, noheadings.... [20:15:05] * MaxSem looks... [20:20:13] urrgggghhhh [20:20:19] arrrghhhhhh [20:20:55] * brion hopes MaxSem is well [20:25:18] brion, noheadings seem to hide this. however, initially I had problems when testing this on my dev wiki - noheadings had no effect at all. scared the hell out of me:) [20:25:29] eek [20:26:09] for the reference: http://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=mobileview&format=json&page=Dido%20Sotiriou§ions=all&noheadings= [20:29:02] * brion slaps self [20:29:04] if (node.getNodeName() == "template") { [20:29:08] no shit that doesn't work in java [20:29:31] brion: :D .equals, .equals everywhere! [20:29:36] brion: no strings in switch case either [20:29:57] Integer xx = new Integer(x); if (xx.equals(zero)) { ...} [20:30:16] hehe [20:30:42] int x = (int)(long)Math.floor(y); [20:30:47] you'd think these fancy IDEs could show a warning "you're trying to compare a string by object id. are you sure?' and refactor it to .equals() magically [20:31:02] well [20:31:10] Math.floor returns a long for a double or an int for a float [20:31:15] so either way that (long) isn't needed :) [20:31:37] brion: hmm, there was something equally retarded I had to write for the bucketing code... [20:31:51] let's switch to cobol [20:31:54] or perhaps the retarded portion of that code was behind the keyboard... [20:31:54] :) [20:55:21] Hi, why does {{fullurl:}} does not resolve to commons.m.wikimedia.org when being on commons.m.wikimedia.org [20:55:26] MaxSem: awjr ^ ? [20:55:38] * awjr shrugs [20:55:55] what does it resolve to rillke? [20:55:56] rillke: we always use the canonical url for that, as i understand [20:56:03] i assume it's commons.wikimedia.org [20:56:09] https://commons.m.wikimedia.org/wiki/Commons:OTRS/Noticeboard/header [20:56:18] "Start a new discussion" [20:56:39] How should I fix this? [20:56:58] probably by making MW core aware of when a user's in mobile mode [20:57:20] and using some functionality exposed by MobileFrontend to ensure you get a proper mobile URL [20:57:40] rillke: can do that? [20:58:22] Presumably, brion [20:58:27] rillke: do you know what handles {{fullurl:}} and where? [20:58:53] But you do not always want buttons... [20:59:01] awjr: do we have separate parser cache entries for desktop and mobile? if not, .... [20:59:13] good point brion [20:59:14] rillke: well proper fix is to use a non-shitty discussion system [20:59:18] that's…. still in progress :( [20:59:28] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71099 [20:59:29] rillke: is there something like {{fullurl:}} but will return a relative URL? [20:59:46] awjr: there is, but then you can't make a link with it [20:59:56] New patchset: Jdlrobson; "Restore edit section links after a successful save" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71120 [21:00:01] doh [21:00:56] brion: You also need this for custom delete links etc. [21:01:44] Is this issue tracked? [21:04:05] hmm, can we quickly hack up a way to make relative links in Parser?:P [21:05:42] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71094 [21:07:53] im looking at the template documentation for https://commons.wikimedia.org/wiki/Template:Clickable_button [21:08:38] can you not use a relative URL in the target? [21:08:47] nope:} [21:09:08] New review: Krinkle; "Note that this failure has been in this commit from the beginning. It wasn't visible throughout beca..." [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/69585 [21:09:10] or an interwiki/ [21:09:53] You can use //commons.wikimedia.org/w/.... but [21:10:01] this does not convert to a link [21:10:10] *does convert to a link* [21:10:18] MaxSem: Do you have an @wikimedia.org address? [21:10:21] i guess an interwiki link would also convert to commons.wikimedia.org [21:10:27] Krinkle, msemenik@ [21:10:40] but will not converted to https://commons.m.wikimedia.org [21:11:04] MaxSem: OK. That explains why your patch was not getting the tests run until awjr approved it. [21:11:28] Zuul doesn't recognize your patch as from a trusted source that allows execution of php on the server. [21:11:40] Read the thread of https://gerrit.wikimedia.org/r/#/c/69585/ carefully, it'll make sense now [21:11:51] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70952 [21:12:02] (expand all comments) [21:12:56] "Patch Set 2: Verified+1" only included linting tests, not phpunit. [21:13:18] You never noticed this before? [21:13:47] i thought hashar change how tests work in our repository to only execute on submit [21:13:51] Krinkle: ^ [21:13:57] No, that never happened. [21:14:00] And shouldn't [21:14:00] I don't care about tests being run only after +2, I care about them failing [21:14:38] What happened is that we restricted execution of "arbitrary" php code to either after +2 (since anyone can submit patches now), or if your account is whitelisted (e.g. you have +2 access yourself). [21:15:06] but MaxSem has +2, Krinkle [21:15:35] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71120 [21:15:48] Anyway, whenever you feel like it you can ask hashar or me to add your account to the whitelist. Zuul is unable to read the permissions from gerrit so it is currently duplicated. For this reason we encourage you use your @wikimedia.org address since those are autowhitelisted. Or if you prefer your own address (like me, so that they show up under my account on github) ask CI to add it to the whitelis [21:15:48] t. [21:17:48] Krinkle: to return to our earlier conversation about 'vrified' - the gerrit tutorial on mw.o says to use it precisely as i've been using it: http://www.mediawiki.org/wiki/Gerrit/Tutorial#Viewing_and_commenting_on_code [21:17:50] All of this crap is because we opened up access before we got to sandboxing Jenkins (which is still a WIP that'll take a lot of engineering effort). Once that is done we can just delete the 'check' pipeline and open up the 'test' pipeline for any patch set right away. [21:18:18] That was written by someone who doesn't know what they're talking about. [21:18:22] This has never been the case, never. [21:18:55] also, avoid Tutorial pages. They are one-off writings for a hackathon. [21:18:59] not maintained. [21:19:05] or reviewed for that matter [21:19:05] i have never heard anything to contrary until today and i've been using gerrit/git since day one at the wmf [21:19:23] That's rather concerning but unfortunate. Can't help that now. [21:20:17] and if the tutorial pages are things we should NOT be looking at, they shouldn't be on the overview pages for gerrit and git on mediawiki [21:20:26] in fact, they probably shouldn't be on mw.o at all [21:21:27] http://www.mediawiki.org/wiki/Gerrit/Code_review has similar language [21:21:37] Yes, I'm (personally) not a fan of having other people document the code, but all I can do is document stuff I maintain. I can't force other people to do that. And when peopel don't leave notes, people make up their own stuff based on the (bad) UI that is available. This is what happens. [21:22:03] Krinkle: my point is i haven't seen what you were saying earlier in any documentation on mw.o [21:22:56] like i mentioned earlier what you said earlier today was news to me [21:22:56] So far all publications from Chad, Antoine and myself (to my knowledge) have clearly stated from day 1 that the workflow is that people review code (CR+1/+2) jenkins-bot uses the "Verified" field to report the build report, and both have to pass to merge. [21:23:12] can you point me to one of those documents? [21:23:17] * YuviPanda hasn't either [21:23:45] if i can't find that information easily on mw.o, odds are most other people cannot either [21:24:09] And just for the record, I don't defend any of this (I agree our docs are bad) but I do observe that only like 5 o 6 people didn't get this (based on the notifications I get from non-bots using Verified in gerrit) [21:24:20] I don't know where it is documented, I didn't create the system nor documented it. [21:24:28] dude [21:24:34] if YOU can't find the documentation... [21:24:45] I know right [21:25:13] Just trying to get our ducks in the row, sorry if I put you on the spot, didn't mean to. [21:25:41] New patchset: JGonera; "Story 831: Improve left nav" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70932 [21:25:59] it's fine i really don't mind, but it's clear to me there is a communication break down somewhere - and clearly the official 'workflow' is not documented in a way that we can easily refer to - which is a big problem. [21:27:42] out of curiosity Krinkle does my marking something verified cause any problems? [21:27:57] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71110 [21:28:20] New review: JGonera; "It would be great to make this testeable somehow." [mediawiki/extensions/MobileFrontend] (master) C: -1; - https://gerrit.wikimedia.org/r/70953 [21:28:32] and what happens when jenkins dies and cannot auto-verify something? [21:28:34] awjr: It's hard to tell as it masks the problem. But yet, it makes it possible for there to be hard-to-solve problems that are easy to prevent and not neccecary to have. [21:30:01] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70932 [21:30:37] in that case it is probably good to just not let manually marking something verified be an option. if you expose an option to a user, some user will eventually do something with it [21:33:04] New patchset: JGonera; "Minor tweaks to PHP ResourceLoader modules" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70447 [21:33:20] Basically, if you override Jenkins because it "works locally" and jenkins would've "dissaproved" and the change (because it breaks on gallium) but couldn't as it was overwritten, if the change is then merged, the next person to interact with gerrit will be unable to do anything and needs to fix the tests first [21:33:25] awjr: ^ [21:33:37] yeah that makes sense Krinkle [21:34:15] I agree completely that this should've been hidden from the UI. I suppose it was just easier to add it and tell people not to use if for X and Y reasons. [21:34:23] I honestly dont even know why I know. [21:34:26] for sure [21:34:27] lol [21:34:56] but I do know what our CI relies on it, that's probably the reason I looked into it as I had to make jenkins-bot play by Gerit's rules. [21:34:59] hi, guys. is there any native mobile client for mediawiki? [21:35:20] New patchset: Jdlrobson; "Regression: Fix special pages on alpha" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71131 [21:36:48] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70447 [21:47:07] Vedmaka: you mean a native app? [21:47:15] Vedmaka: no there's not [21:47:27] technically the WikipediaMobile app could be forked to be one though [21:47:57] the WikipediaMobile app can work with any mediawiki instance, but I'd hardly call it 'native' :) [21:48:39] New patchset: Yurik; "Incomplete patch to refactor special page" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/71134 [21:53:01] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70955 [21:53:01] New patchset: Jdlrobson; "Remove #mw-mf-page-left id" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70942 [21:53:48] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70942 [21:54:10] New patchset: JGonera; "Introduce NearbyApi to make nearby code more generic and reusable" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70947 [21:57:11] New patchset: JGonera; "Introduce NearbyApi to make nearby code more generic and reusable" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70947 [21:57:41] New patchset: JGonera; "Alpha: Surface nearby articles" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70236 [21:57:45] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70947 [22:00:47] New patchset: Yurik; "Minor code cleanup - doc fixes, redundant var decl" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/71136 [22:00:50] WIN: https://bugzilla.wikimedia.org/show_bug.cgi?id=50400 [22:01:01] mobile wins the internet [22:01:01] :D [22:02:16] jgonera: 37.7793000; -122.4192000 [22:03:03] whoa i just discovered that a local bar, one of the oldest in tucson, has a magic: the gathering night every other wednesday! http://hotelcongress.com/music/magic-the-gathering-at-hotel-congress/ [22:03:23] too bad i sold all my m:tg cards for a CD burner back when CD burners were first hitting the consumer market [22:03:43] looks like you got... burnt! [22:03:46] (sorry) [22:03:51] ahahahhaa [22:04:22] this is a problem with having two displays, I think. IRC is constantly on one... [22:04:25] haha) [22:05:05] dfoy just a head's up that i think i finished the code changes necessary to get bugello working for you guys - im going to start setting things up [22:08:39] jgonera: className: 'mw-mf-overlay list-overlay', [22:09:21] YuviPanda: what do you think of this (provisionally, needs more work) for the detail page? https://github.com/brion/apps-android-commons/commit/d690e95025e9da2364d49c2a5bd5a70ff6d083a5 [22:09:32] * YuviPanda clicks [22:09:44] it looks pretty bitchin' on a device, i think :) [22:09:50] but the code's a bit ugly and has some stray bits [22:09:56] :D [22:09:58] screenie? [22:10:03] lemme take one [22:10:42] awjr: ok thx [22:11:59] YuviPanda: https://www.mediawiki.org/wiki/File:Detail-pane-closed.png https://www.mediawiki.org/wiki/File:Detail-pane-open.png [22:12:25] Maryana: can we enable red links.. :/ [22:12:47] brion: ooo, pretty :D [22:12:53] let's let editing mature a bit in stable before we do that, jdlrobson [22:12:59] brion: also, I think the categories - are you pulling them from the API? [22:13:00] thx :D [22:13:06] YuviPanda: yes [22:13:07] brion: I think we should only get the categories that are explicitly on the page [22:13:17] we'll i think want to split them between explicit and implicit categories [22:13:27] users can't really edit implicit categories [22:13:30] yeah, can still be useful to get at those others, but we should know which are editable [22:13:38] we shouldn't really display them [22:13:38] at all [22:13:45] eh, that'll be the simple way :D [22:13:48] okay, let me look at the code now [22:13:57] you'll hate parts of it ;) [22:14:00] brion: it's the 'correct way' too, IMO :) especially on mobile. ~20 cats... [22:14:34] brion: okay, so why is that a listview? [22:14:45] brion: it's always gonna have 3 parts, right? 'name', 'description', 'list of categories' [22:14:53] YuviPanda: so, it's a list view so the categories can be a list, with all the list behavior [22:15:03] everything except the categories themselves is in a single 'header' view [22:15:19] putting a list view into another scroll view is….. not good [22:15:24] brion: still feels wrong. Should be a ScrollView( LinearLayout( Header, ListView ) ) [22:15:26] oh [22:15:43] brion: are they fighting for scroll? we should be able to prevent that [22:15:48] this feels a tiny bit icky :) [22:16:07] apparently the way to "make it work" is to modify the list view to report its size as the sum of all item heights [22:16:14] which means it always shows all the views [22:16:24] and that…… should "work" but is kinda scary [22:16:32] this way is also not idea, but … eh [22:16:41] depends on by 'all items' it means 'all items ever' or 'all visible' items [22:16:45] but yeah, this works for now :) [22:16:52] all items ever, is my understanding [22:16:59] which is probably ok for category lists, they're not huge [22:17:22] brion: MediaDetailExtractor is scary. [22:17:22] we'll also end up stuff other stuff in here like file metadata, maps, usage lists, perhaps [22:17:28] yeah welcome to xml hell [22:17:29] we should have unit tests for that [22:17:34] agreed [22:17:57] fetch should be elsewhere, but you've already marked that :) [22:18:03] brion: we should not be fetching categories. [22:18:11] brion: we should fetch the wikitext, and parse the cats out of it [22:18:21] New patchset: JGonera; "Alpha: Surface nearby articles" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70236 [22:18:26] YuviPanda: *nod* once we're parsing the cats out we can drop the other categories [22:18:44] brion: yeah, if we're parsing cats out of wikitext the other categories will automagically drop :) [22:18:51] \o/ [22:19:00] brion: this is also the model of HotCat, so it's consistent across everywhere [22:19:06] nom nom excellent [22:19:07] so no api categories :) [22:19:07] New patchset: Jdlrobson; "Alpha Regression: Fix the main page" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71139 [22:19:09] * YuviPanda reads some more [22:19:42] brion: are you keeping count of how many times you said 'fuckin Checked Exceptions' while writing that? :P [22:19:50] lol [22:20:09] brion: MediaDetailInfo shouldn't exist. Should be part of Media.java [22:20:38] hmmm perhaps [22:21:30] brion: Media class already has fields for most of these, so you just need to hook these up [22:21:40] brion: plus you are already dealing with a Media class there... [22:21:48] plus we have MediawikiImageView, etc that take that... [22:21:49] yeah [22:21:54] well we'll have to extend them [22:21:58] multiple descriptions can exist [22:22:02] multiple licenses can exist [22:22:07] oh sure sure [22:22:08] we can [22:22:09] we will [22:22:10] :) [22:22:15] not set in stone [22:22:19] though we've to be a little careful [22:22:27] because we are persisting them via Contribution.java in sqlite [22:22:34] and then that kinda maps into Contribution which….. right :D [22:22:58] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/70236 [22:23:09] brion: so, this also should be done in the ContributionsContentProvider I think [22:23:16] brion: rather than a request when the user views it [22:23:19] but I'm not really sure [22:23:23] mmmm [22:23:26] because some images are never going to be viewed [22:23:27] well, all those things can change [22:23:31] that too [22:23:40] so we have to pull them fresh even if we have them cached [22:23:44] right [22:23:45] makes sense [22:23:46] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71139 [22:23:55] we could do some intelligent caching, probably [22:25:15] brion: but yeah, you're right. we'll keep it out of the SyncProvider [22:26:22] New patchset: JGonera; "Regression: Fix special pages on alpha" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71131 [22:26:52] Change merged: jenkins-bot; [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/71131 [22:26:58] also in future we'll be showing photos that aren't your own, so they won't be in your local stream [22:26:59] hmmmmmm [22:28:27] brion: well, that's okay. We just need to make sure that everything can work with Media.java files [22:28:33] than expecting Contribution.java files [22:28:40] yep [22:28:43] should be simple to do a 'make API query, and give me back Media files' thing [22:29:06] brion: okay, so the layout stuff is hacky, but the fundamental code looks good to me! [22:29:16] YuviPanda: don't the media fragments currently rely on the activity to perform some actions? we'll have to move that in on a parameter maybe…. anyway can do that later [22:29:17] leaving comments there, to have a record [22:29:19] \o/ yay [22:29:21] thanks [22:29:41] brion: yeah, fragments call backwards to access UploadService [22:29:42] primarily [22:29:53] brion: and we also have our canonical 'list of media we are displaying' in the activity [22:30:04] yeah [22:30:17] that can probably be tweaked to send a Media object as a parameter to the fragment or something…. [22:30:18] brion: and reference it from fragments. This syncs position and also prevents duplication [22:30:35] well, they're not all in memory, they're loaded on demand [22:30:49] and if you send just a media parameter, how will it know where to scroll left / right? [22:30:55] s/scroll/swipe/ [22:31:09] oh well that's up to the viewpager which is connected to the list isn't it? [22:31:11] of course, at the innermost fragment (MediaDetailFragment, I think?) we give it a Media object [22:31:13] eh i'll fiddle with that more later [22:31:16] :) [22:31:21] wheeeeee [22:34:44] brion: left comment with generla comments :) [22:35:09] YuviPanda: re: the anonymous inner AsyncTask class. Would you prefer a named static inner class, or moving the background portion into MediaDataExtractor so it just takes a callback that runs on the UI thread? [22:35:45] brion: so MediaDataExtractor shouldn't have networkcode, should just be a static-ish parser that returns a Media object. [22:35:58] ok [22:36:09] brion: and static inner class sounds okay. [22:36:15] spiff [22:36:19] move the network code in there? [22:36:25] yeah [22:36:26] essentially [22:36:27] it'll be simpler without the categories fetch :) [22:36:35] MediaDataExtractor should be MediaWikitextParser [22:36:41] nom nom nom [22:36:43] you give it some info + some wikitext [22:36:47] and it returns a Media object [22:36:49] wish i could get the links in the preprocessor xml [22:37:00] brion: well, you could just parse the wikitext :P [22:37:06] DOM is ugly but at least i don't have to replicate the entire parser [22:37:10] haha :P [22:37:10] edge cases wooooo [22:37:26] raw cat links are easy though, they're pretty stable in format [22:37:36] templates though… *shudder* [22:37:40] brion: heh. [22:37:59] brion: so yeah, we should make sure that the code that interacts with MediaDataExtractor is minimal. and very isolated. [22:38:08] brion: that also means we can easily throw it into another project and write tests [22:38:09] +1 easier to test that way [22:38:12] yesss [22:38:29] brion: we should actually move the entire PageModifications stuff off into a separate project too [22:38:50] whee [22:39:20] YuviPanda: anything in particular you recommend I poke in the layout? [22:39:43] brion: well, it works now. I think we should get everything else sorted out, and then touch layout :) [22:39:50] hehe ok [22:40:05] brion: also I really love the fact that we're using GitHub for this. Imagine doing this as one huge patch. [22:40:19] * YuviPanda shudders at the thought of CR that way. [22:40:23] \o/ [22:40:32] well i squashed like 21 commits into that [22:40:36] most of which were very exploratory :D [22:40:37] brion: aak, why [22:40:47] well, could've squashed them into 4-5 :) [22:40:53] dfoy: you will now see a bunch of bugs on the trello board; but please ignore them for now, im ironing out some kinks [22:40:58] brion: in the end they'll all be merged into gerrit squashed into one, so... [22:41:07] i figure we'll have more from here, so this is 'step one that mostly works' :D [22:41:23] you'd have killed me if you tried to review those 21 commits one by one [22:41:39] brion: I wouldn't have to, I'd just ask you to send a PR :P [22:41:56] https://github.com/brion/apps-android-commons/commits/detail-split <- here they are if you want em [22:41:58] brion: that's how the UW code review is happening. [22:41:59] :)) [22:42:08] with PR you get unified view [22:42:21] and also importantly, if new commit updates older code that had a comment, github clearly marks that [22:42:25] which is wonderful [22:42:31] nice [22:42:36] :) [22:42:43] that patch keeps growing though :( [22:42:50] i've almost gutted all of campaigns now. [22:43:51] YuviPanda: in future it'd be awesome if we can add pinch-to-zoom on the image portion while the details are scrolled down at the bottom [22:44:08] i'm not sure offhand how to make that work, there's a lot of touch going on between the list and the pager :D [22:44:10] brion: yes, we'll need to add that to MediawikiImage [22:44:18] nom nom [22:44:21] heh, yeah [22:44:38] New patchset: Yurik; "Minor code cleanups" [mediawiki/extensions/ZeroRatedMobileAccess] (master) - https://gerrit.wikimedia.org/r/71136 [22:44:48] brion: we'll also need to figure out if we'll let it download higher res images as you zoom in [22:44:50] but that sounds hard [22:45:01] hard but not impossible [22:45:06] true true [22:45:08] we'll need more intelligence about what images are cached, maybe [22:45:15] yeah, we can do that pretty nicely [22:45:48] I'm a bit sad that I never got to rewriting our API code in Volley. That would make allmost all our AsyncTasks go away [22:45:58] but we might be in Callback hell, so I'm also sortof happy about not rushing into it [22:45:59] yay [22:46:06] heh [22:46:14] imagine jQuery without promises / deferreds [22:46:17] but... in Java! [22:46:25] yeah i did everything with a jQuery-like promise pattern in the Obj-C version [22:46:29] callbacks everywhere :D [22:46:36] brion: yeah, so Java has that in the form of futures [22:46:40] eek [22:46:43] except... that Volley doesn't support it [22:46:49] I'll need to either wrap volley or contribute code to it [22:46:59] (they 'theoretically' accept contributions) [22:47:06] but it's part of Android, so... [22:47:39] i'm not convinced i like futures [22:47:54] brion: aren't they pretty much the same as promises? [22:48:02] except with a way to 'block' execution if needed? [22:48:03] they don't seem to have a 'call me when you're done', but rather 'lemme do some stuff while you're running, then block until you're done if you're not done yet' [22:48:13] brion: oh, the Java ones let you do both [22:48:15] sortof [22:48:18] you can set callbacks too [22:48:20] or block [22:48:48] blocking is baaaaad [22:48:55] in general, yeah [22:49:05] but in one particular case it's necessary [22:49:11] which is when you're *already* on a background thread [22:49:38] yo dawg, i heard you like threads in your threads [22:50:08] :D [22:50:31] you want to block only when you are in a method that has to return some value that is of significance, and you can't do that without completing an async operation [22:50:45] thankfully such situations are rare [22:50:52] anyway, at this point this is a theoretical discussion ;) [22:50:55] :D [22:51:23] i think you might be able to do sane promises in java, actually…. just expect to have lots of anonymous inner classes for those callbacks >_< [22:51:25] brion: I think the primary biggest thing there is to have the MediaWikitextParser thing done, and done cleanly. [22:51:31] *nod* [22:51:50] brion: can it be just a static class? [22:51:52] i still prefer to use the parse tree for the templates since nested templates and regexes don't mix well [22:51:56] a stateless static class? [22:52:04] probably could yeah [22:52:11] :D [22:52:14] regexes for the cats will be easy tho [22:52:30]