[16:40:26] Krinkle: I am here now [16:40:28] I am so sorry for forgetting, I had forgotten I had scheduled work for myself today [16:40:36] ok [16:41:33] So, what're we at [16:41:48] Alright so [16:42:08] I now have the shared gadgets preferences tab mostly working [16:42:30] All it's missing is fetching data over AJAX but that should just be a question of connecting the backend and the frontend and take like 5 minutes [16:42:53] (It's currently using hard-coded example data and it behaves strangely if that doesn't match what's actually on your wikis.... ugly ugly ugly) [16:42:54] I'm going through your commits now [16:43:09] One of the things that's bugging me is the way the preferences for gadgets work in general. [16:43:14] ha! roan here... good, so i can ask about api... [16:43:29] we never rewrote that, it's still using the ugly 'multiple' HTMLForm indirectly [16:43:43] making it very inflexibly [16:43:52] unable to match my design idea [16:44:00] What was your design idea? [16:44:02] all other tabs have

etc. and [16:44:07] We can realize it regardless [16:44:18] The categorization is built out with JS right now [16:44:28] Basically what happens is this [16:44:33] Not

with + , but
??? +
[16:44:42] Right [16:44:43] like the other tabs [16:44:47] both for shared as for local [16:45:01] that should also make the saving easier I think [16:45:06] Hm, for local that would require a bit more work but it wouldn't be impossibles [16:45:07] right now it's all using the same input name [16:45:12] name="gadgets[]" [16:45:13] It doesn't make saving any harder or eaiser [16:45:18] Yes, but HTMLForm handles that transparently [16:45:26] instead of name='gadget-???' [16:46:02] ok [16:46:22] so the backend doesn't care, the fronted still does. It's the only tab that looks ugly imho, always been that way [16:46:41] Right, yeah [16:46:45] We can reformat it [16:46:53] This touches closely upon my design question for you [16:47:25] Which is, we (or at least I) never considered the fact that shared gadgets have a two-deep hierarchy. It's { reponame: { category: { gadget, gadget } } [16:47:32] RoanKattouw: ping me when you're done with this conversation, pls, i don't want to interrupt your circles. thx [16:47:42] Danny_B|backup: Sure [16:47:43] RoanKattouw: hm.. true [16:47:47] Danny_B|backup: Will have to be post-dinner probably [16:48:12] So I did it with h1 and h2 now [16:48:12] whatever you'll feel comfortable with [16:48:16] RoanKattouw takes quick screenshot [16:48:38] That makes me think even more that we should not let the backend hierarchy reflect in the front-end. Neither the local/remote part, nor the reponame:category part [16:49:15] The categorization exists for* the frontend [16:49:15] all in one list and indicate statuses and sources for each item [16:49:21] I'll have to rethink my design [16:49:31] The backend wouldn't need categorization if it weren't for the fact that we want to display things in a categorized way [16:49:33] RoanKattouw: Sure, categorization will still be visible in the frontend [16:49:43] what I don't want in the frontend is like an extra heading level for repo [16:49:49] Right [16:50:05] But that presents another problem: possible category name collisions between repos [16:50:07] I'll show you want I had in mind up until now [16:50:12] Do you merge those or disambiguate them [16:50:35] well, in the long term I was hoping to replace categories with a more tag-like system [16:50:41] but that doesn't' answer your question :) [16:52:52] Not really no [16:54:28] https://www.mediawiki.org/wiki/File:Rl2-sharedgadgetprefs.png is what things look like now [16:54:35] The
vs
thing is ugly [16:55:13] Also, I don't have any i18ned description of a repo name handy, so I just used the raw repo name (or RL source name, technically) [16:56:32] OK, I have to go grab dinner now while it's still warm, let's talk more when I get back [16:56:37] http://i.imgur.com/MqzcB.png [16:56:53] This and ForeignAPIGadgetRepo are all standing between us and demonstrability [16:57:15] [ ] Enable this Gadget ? [16:57:24] Would there be any other options there? [16:57:39] If not it seems very repetitive and inefficient (in terms of screen space) to me [16:58:00] the label could be hidden, but in general HTMLform expects a label value there [16:58:10] it would also be extendible for the gadget-prefs thing [16:58:26] Yeah, it's currently done by setting the label to and using the Gadget name to the right of the checkbox [16:58:27] True [16:58:30] in that, yes, there are other values. [16:58:51] mw-prefs style is: Main label in front, not behind [16:59:03] we'd either place "Enable" as label behind it, or the description behind it [16:59:18] Not for boolean prefs [16:59:19] if it weren't for salvatore's branch merge, I'd have put the gadget description behind the checkboix [16:59:30] I can't find any checkbox/boolean pref in core that has your style [16:59:43] See e.g. https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-rc [17:00:04] Oh, there is one [17:00:10] "Advanced options" [17:00:10] namespacestobesearcheddefault [17:00:11] https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-searchoptions [17:00:23] "Advanced options" is a field set, and the description is put behind the checkbox. [17:00:27] Yes [17:00:29] "Use enhanced recent changes (requires JavaScript)" [17:00:32] That's what I mean [17:00:34] That's the dominant style [17:00:35] it's just that "Use enhanced recent changes (requires JavaScript)" doesn't have a name, only a description [17:00:45] so that's what I have too. Except that ours have a title as well [17:01:08] The only counterexample I can find is in "Search options", for the namespaces [17:01:46] Anyway, swapping this around is trivial [17:02:01] I'll work on getting the
thing to happen after I connect the dots on AJAX as I mentioned before [17:02:06] And now, dinner for real [17:02:45] ok, RoanKattouw_away for remote prefs the html layout is flexible. The harder part (at least, I couldn't get it to work) is to get that layout for local gadgets. [17:03:05] eet smakelijk [17:35:59] I'm back [17:36:15] So yeah the layout for local gadgets -- I think I know how to change that to fieldsets [17:36:17] I'll work on that on Monday [17:36:30] From there on out doing it for remote gadgets will be trivial [17:37:09] ( Krinkle ) [17:37:40] http://www.mediawiki.org/wiki/File:Rl2-prefs-idea1.png [17:37:41] ok [17:37:51] http://www.mediawiki.org/wiki/File:Rl2-prefs-idea2.png [17:38:15] I'm thinking of going with 1 and adding to that a way to get into the per-gadget prefs (depending on how salvatore did that, if at all) [17:38:35] as well as a sudle note of the source if not local [17:39:36] better would be [ ] Awesome gadget (_more..._) [17:39:45] Now I have dinner [17:39:51] when you'd click on more you'd get expanded description [17:39:59] RoanKattouw: so may i? [17:40:25] Danny_B|backup: Sure [17:40:40] i've been told it is not possible now, so my question is: could there be added the possibility to get page title(s) when i supply category name and sortkey? [17:40:48] Krinkle-away, Danny_B|backup: Yes, the prefs stuff would have to be collapsible. In Salvatore's implementation it's a popup I think [17:41:00] Hmm [17:41:11] popup is not accessible friendly usually [17:41:35] cmstartsortkey? [17:41:45] besides, in collapsible style you can have expand/collapse all descriptions [17:42:02] while you can't display all popups or very hardly [17:42:17] RoanKattouw: the original, not capitalized sortkey [17:42:29] Oh [17:42:30] Bah [17:42:34] Hmm, well, ... [17:42:56] Hmph yeah it wants to be given in binary foramt [17:43:08] what? [17:43:10] huh [17:43:21] I mean [17:43:30] cmstartsortkey needs to be in the uppercase format [17:43:36] And for UCA it'll be binary gibberish [17:44:38] i thought the original sortkey is stored as text [17:44:50] No [17:44:55] It's stored after being mangled [17:44:59] Well wait [17:45:01] You're right [17:45:03] The original is stored [17:45:12] But it's not indexed [17:45:14] huh, you freaked me out completely [17:45:19] hehe [17:46:01] Well the api could convert the original text as supplied by user into binary version, and then use that field [17:46:20] Danny_B|backup: The reason I didn't go with a simple " Category: \n [] gadget \n [] gadget name" is because that kind of layout doesn't leave much room for all the other stuff we need in there. Every gadget has a title, an optional description, enable checkbox, optionally a button to open a modal dialog with per-gadget prefs (which can be many), and a note somewhere indicating it's source (local, repo1, repo2 etc.) [17:46:45] now getting dinner for real [17:47:22] bawolff: My thoughts exactly [17:47:32] But that would have to be a new param, for b/c reasons [17:48:24] let me show the pseudocode (i don't remember the exact syntax) example: api.php?action=categorymembers&cmname=testcategory&cmsortkey=foo will return any page which is categorized in testcategory with foo sortkey [17:48:36] Yeah [17:48:59] Danny_B|backup: Not hard to do, you'd need cmstartsortkeyplain and cmendsortkeyplain params or something [17:49:09] i.e. unencoded versions of cmstartsortkey and cmendsortkey [17:49:54] how hard would it be to implement it? [17:50:14] Easy [17:50:35] Well, you'd have to look up how sortkey encoding is done I guess [17:50:58] That's the part that would be hardest to get right, but that should just be a matter of doing a little bit of researhc [17:55:05] It's generally just Collation::singleton()->getSortKey( "plain version of sortkey" ); but complicated by the fact that the plain sortkey is suffixed by the current page name (by default, and can be changed by a hook) [17:56:08] bawolff: So how do I properly get a full sortkey given a plain sortkey and a Title object? [17:57:08] If you have the relavent title object its Collation::singleton()->getSortKey( $titleObject->getCategorySortkey( "plain sortkey" ) ); [17:57:56] Ah, OK [17:58:00] That's easy enough [18:34:52] bawolff: Hmm looks like I won't even need the title stuff if I'm just doing a >= operation [18:35:48] probably not [21:16:25] RoanKattouw: do you know where in the WMF architecture is the best place to see if i've got a special page caching correctly with squid? testwiki? [21:16:59] awjr: Look at the caching headers in Firebug [21:17:21] If it sets the correct caching headers, you can count on Squid and what not to behave correctly [21:17:58] yeah i figured as much but i'd still like to be able test for cache hits /before/ putting it in production [21:18:07] if that's possible [21:18:40] Not in a convenient way, not really [21:19:11] :( [21:20:25] You can still test client-side caching, of course [22:23:24] *jorm yawns.