[14:29:55] brion? are u there? [18:03:11] nkomura_idle: To check: the weekly meeting is on Wednesday instead of right now, right? [19:13:51] jquery.wikiEditor.toolbar.js line 474 [19:14:07] adam_miller: When I tweak your code to fix coding style, and you rewrite that code, please keep the coding style (consistency with surrounding code and all) [19:16:21] yes [19:16:21] consistent spacing [19:16:29] RoanKattouw: context? I attempt to adhere to the conventions but i rewrote a lot of wikiEditor.toc.js, sorry if i missed some things [19:16:34] I'm tweaking that code right now [19:16:43] TrevorParscal: Noooooo [19:16:47] i'm already working on fixes [19:16:50] I've got a commit ready for that stuff too [19:16:55] haha [19:17:00] I got in there because there was a reference to context.modules.$toc without checking if that even exists [19:17:05] Ah yes that part [19:17:06] all three of us are working on the same thing [19:17:07] Good [19:17:10] I think I went somewhere else [19:17:11] ha ha [19:17:18] ok [19:17:20] fine [19:17:24] I will revert [19:17:25] *RoanKattouw grabs his laptop and tries to beat the rest to committing [19:17:27] please use consistent spacing [19:17:27] No worries [19:17:48] As long as you don't go making spacing revisions all over the place, that's guaranteed to screw us [19:17:49] I was going to replace those with triggering a resize event on context.$ui [19:17:54] But the $toc fix is good [19:18:01] please use full names of variables - only abbreviate when it's obvious what the abbreviation means like XML or HTML or DOM... [19:18:18] ok ok. [19:18:44] ( this + that ) ! (this+that) [19:18:48] sorry I'm so picky [19:18:50] :( [19:18:51] just use stylize.php [19:19:08] it will fix most of your code style [19:19:12] well, spacing anyway [19:19:34] werdna: Doesn't work for JS [19:19:35] for JavaScript? [19:19:40] yeah! [19:20:10] well hack something together :P [19:20:44] or just clean up the code when you write it / touch it [19:20:46] plz [19:21:02] RoanKattouw: permission to modify wikiEditor.js ? [19:21:13] jquery.wikiEditor.js I meant [19:21:14] Sec, gotta check what my local mds are [19:21:27] *mods [19:21:36] TrevorParscal: DENIIIIIED [19:21:37] i reoged it a bit so the calling order isn't backwards... [19:21:40] :) [19:21:41] *werdna flashes red lights at TrevorParscal [19:21:42] grr [19:21:45] ok [19:31:58] i bet I won't like what it does to the code... [19:32:55] TrevorParscal: it focuses mostly on spaces [19:32:57] not {} [19:33:45] yeah, there's allot of line break cases and such that are poorly handled by most code formatters [19:33:48] with js .chaining & { bracket stuff would be difficult to consistently format for readability. [19:33:51] i tend to dislike them [19:34:00] yes [19:34:04] chaining esp. [19:34:06] yea this one does not try to do that much [19:34:16] automated code formatting -1 [19:34:33] disciplined manual code formatting +1 [19:35:09] well it just helps when you want to go from disciplined manual code version A to disciplined manual code version B ;) [19:39:18] TrevorParscal & RoanKattouw - would either of you like help me think of a good solution for handling height changes to the wikiEditor? [19:39:39] we need an event called wikiEditor-reflow [19:39:41] I'm not really available right now [19:40:04] should that be something IN jquery.wikiEditor.js? [19:40:23] or just something an event we trigger and bind to from other files? [19:40:26] let me take a look at that [19:40:45] I think modules should have an evt object, just as they have api and fn objects [19:40:56] the evt object has all the event handlers [19:41:03] the first of which would be reflow [19:41:19] when wikiEditor-reflow is triggered [19:41:39] the wikiEditor core reflow event handler is called [19:41:54] and it calls all the modules reflow handlers [19:42:03] the only issue with this design [19:42:07] is dependencies [19:42:36] like, "i don't know how tall this should be until I know how tall the toolbar is" or some such.. I don't know that we have very many of those right now... [19:42:52] but they could increase in number over time... [19:43:09] hmmm [19:43:13] thinking of design for this.. [19:43:20] yeah i think they will, which is why this seems like a good time to come up with something that works for future cases as well [19:43:57] yes.. [19:43:58] hmm [19:44:08] *TrevorParscal heads to whiteboard [19:44:45] adam_miller: in the mean time, can you just wrap those context.modules.$toc calls in if ( context.modules.$toc ) { .. } statements? [19:44:51] the ones in the toolbar code that is [19:44:56] sure [20:23:09] Some remarks before I head to bed: [20:23:58] 1) Why not use jQuery's event system instead of the context.evt stuff? You can listen for mouseup, keyup, etc. on context.$content.parent() , and you could trigger() custom events on context.$content and listen for those [20:25:05] 2) We should consider the fact that the TOC may be enabled while the toolbar isn't, or viceverse. In the former case, where do we put the collapse/resize stuff? This cross-module thing with the TOC control being in the toolbar kinda scares me [20:25:33] 3) I fixed a bunch of RTL issues with the TOC over the weekend (made it float left instead of right in RTL), but we still have the issue where the icons themselves are LTR, guess that'll be fixed with lang-specific icons [20:31:59] TrevorParscal: Also, when you get back, please send me an e-mail green- or redlighting my committing the section edit link rearrangement patch to trunk [20:33:40] RoanKattouw: re #2, the markup itself isn't in the toolbar, but the UI is reliant on it and you're right, we need to figure out how to handle that case [20:34:16] Well either way it's scary, whether the TOC code contains toolbar stuff or the toolbar code contains TOC stuff [20:34:46] Right now we're in the second scenario and all we can really do at this point without changing too much is moving to the first scenario, which is equally evil