[17:34:56] goodMorningAll(); [17:40:48] good morning Mr. TrevorParscal [17:40:56] how's it going? [17:40:59] not sure that email you sent this morning made a ton of sense [17:41:03] it's going well [17:55:02] really? [17:55:34] what did you find confusion - or perhaps what did you understand it to mean? [18:01:21] i found the first paragraph unclear [18:02:02] ok - so you mean you are unclear about why there's no space for this tab in the advanced, characters and help sections? [18:03:14] no, maybe i'm unclear where the suggestion to put the tab in there came from [18:03:18] the fact that there's some space on the right of the advanced section is not a guarantee [18:03:29] oh [18:03:42] brb [18:03:44] meeting [18:03:46] i missed that, which is probably why i had no idea what you were talking about [18:03:51] ok i'm gonna grab lunch [18:10:29] right on [18:24:38] adam_miller_lunc: r58822 has an unused and misspelled var $collopseControl [18:25:12] RoanKattouw: how's it going! [18:25:33] adam_miller_lunc: Also, you've got inconsistent coding+indent style and debug code (console.log) in .toc.js [18:25:41] Morning TrevorParscal [18:25:53] I've had my first decent day at school since like May [18:26:10] RoanKattouw: oh yeah? [18:26:21] As in, longer than 2 hours :) [18:26:47] is all your work checked in right now? [18:28:10] No [18:28:12] I [18:28:16] 'm gonna check in something now [18:29:09] while I like the idea of the textSelection function unification thing (well, mostly) I'm not fond of the idea of automatically deferring to the iframe based on some information in the textarea's data - seems messy to me [18:31:02] and this idea of falling back to a textarea is a bit misguided as well - because if your browser can't support the iframe, you browser will not do well with all these text selection issues either - so the entire wikieditor should give up on you completely [18:31:37] That's not the reason for it [18:31:54] The reason is that Michael wants to use textSelection in AMW too, and he doesn't know whether wikiEditor will be enabled or not [18:33:30] Hm I have to do a little bit of tweaking here and there, I'll commit in 10-15 mins or so [18:35:53] hmm - and he's planning on using wikiEditor later on or something? [18:36:49] No, he wants AMW to work with and without wikiEditor [18:37:02] adam_miller_lunc: You need a return false; or e.preventDefault(); on that TOC show/hide link [18:37:09] seems like he should just take textSelection and do what he pleases with it, because wikiEditor is likely going to end up moving in different directions and will only be using the iframe version of text selection handling [18:38:05] Maybe [18:38:42] RoanKattouw: i think I need to talk to him about his use-case, because I think he needs to sort of make up his mind on one or the other, as wikiEditor is quickly diverging from being a textarea on sterroids [18:38:54] hehe [18:39:06] Sure, talk to him :) [18:39:34] Either way, this cleans up the calling convention a bit [18:39:43] And it's very easy to take the fallback-to-iframe behavior out [18:39:57] how is his text-selection stuff going to work when we have collapsed templates and tables? [18:40:10] But yeah, I've already been placing comments along the lines of // FIXME: We may not need character position-based if we insert markers in the right places [18:40:13] Ha, good point [18:40:23] I just don't think the fallback to iframe behavior is worth putting there [18:40:44] i will talk to him about it [18:40:45] It's like half a line [18:41:07] return ( hasIframe ? fn : context.fn )[command].call( this, options ); [18:41:17] Oh, heh, that's backwards [18:42:10] so, where are we in this refactor [18:42:29] I don't want things to get too far out of scope... hoping to recap [18:42:41] Right now, I've changed the calling convention from .foo( 'bar', 'baz'); to .textSelection( 'foo', { 'param1': 'bar', 'param2': 'baz' } ); [18:42:56] The object style is much cleaner because there's actually places where we use such objects (for encapsulateSelection) [18:43:10] Of course I just realized that means I need to update the callers :) [18:43:44] The .textSelection() function checks if there's a wikiEditor context set on the textarea, and pulls functions from context.fn if so, or from fn if not [18:43:57] context.fn contains functions operating on the magic iframe, while fn contains the old-style textSelection functions [18:44:02] RoanKatttouw: totally aware of each of those issues - I committed to hastily before switching from home machine to work machine today [18:44:11] thanks for the accountability though [18:44:19] The functions have the same prototypes (this is where it bites, because I'm pretty sure they'll deviate soon) [18:44:47] adam_miller: No worries :) [18:46:28] Also, the names of the functions are still what they used to be, so we currently have .textSelection( 'getSelection' ) , which looks kinda ugly [18:46:36] But we can change that later [18:47:05] yeah, I don't like the idea of being locked in based on his code at this point [18:47:18] we need to put more thought into the API if that's going to happen [18:47:30] Yeah well [18:47:55] Since we're departing from the API completely we might as well drop this cross-compat thing later [18:48:12] The temporary upside is it makes trunk work again [18:48:38] Once the context.fn.* methods have been implemented (some time tomorrow, hopefully), I'll drop the cross-compat thing and Michael can take the textSelection plugin into AMW and go apeshit [18:48:56] ha [18:49:09] if you are OK with that, i am too [18:57:52] Hey I'm the guy that proposed it, sure I'm OK with it :) [19:17:21] Gaah [19:17:29] Now I'm getting mysterious "$.fn is undefined" errors [19:28:54] TrevorParscal: Lol, for some reason Toolbar.min.js never made it into SVN [19:28:58] *RoanKattouw svn adds it [19:32:15] TrevorParscal: Committed my refactoring [19:32:38] k [19:32:43] Next I'm gonna implement the selection functions for the iframe if nobody's doing that yet [20:27:36] http://usability.wikimedia.org/wiki/Babaco_Designs#Editing_Interface_Improvements [20:43:38] ? [20:43:44] Has that changed? [20:53:33] a bit [20:53:37] look at the old versions [21:20:43] I don't see it [21:21:38] the difference? [21:22:03] well, the toc is allot different [21:22:10] that's the majority of the difference [21:22:22] also, publish and cancel swapped places [21:37:39] adam_miller: do you think you could merge the two toc style sheets? [21:37:55] i'd like to try and keep a 1:1 ratio of style sheets to plugins [21:38:13] you bet. no problem [21:39:03] actually, i'm not using the other one, so i'll just remove it from trunk [21:40:05] :) [21:43:13] There. You have your 1:1 ration back. [21:43:19] thank you! [21:43:26] also, did you see the changes to the TOC? [21:44:06] yeah i love it [21:44:29] i'm working on adding cookie support to it right now, then i think i'll get started on shifting it around to match your wireframe if that's cool [21:44:49] sure [21:44:54] just wanted to discuss that partb [21:45:04] because it's not going to be straightforward at all [21:45:35] bascially, the toolbar needs to render it's sections in a totally new place [21:45:42] it will be in the bottom div [21:46:01] I will sketch it out [21:58:23] adam_miller: the more I look at this the more I think I need to be the one that makes these changes to the layout [21:58:28] they are pretty far reaching [21:59:16] hmm [21:59:24] maybe I can make this simpler... [21:59:30] you are getting a bit wild with this design [22:00:04] put everything BUT the ntoc in one div, and the ntoc in another [22:00:31] so you can keep it to two elements you're changing onmousemove [22:01:02] yeah, I'm sort of going in that direction [22:01:15] there will be a wikieditor-right div [22:01:27] that will be on the right of the top and bottom divs [22:01:38] i think that'd be the cleanest way to go about implementing it [22:01:40] which are in the left div [22:33:00] TrevorMultiTaski: are you making those changes? i've got a bunch of changes to jquery.wikiEditor.toc.js that i'm about set to commit [22:33:40] i'm not doing anything yet [22:34:03] but I did email you (and roan and nimish) about the layout changes [22:35:01] I see that. I dig it. [22:36:03] we're making a lot of adjustments for this one feature, but it does seem like the nicest UI option of everything we've looked at thus far [22:40:43] agreed [22:41:05] it's important to get this sort of thing right - it will help make future work much easier [22:41:52] the lazy man works twice as hard.... refactor early and often [22:41:55] :) [22:42:55] yo how do i handle tree conflicts in svn? i've gotten two today and I can't figure out how to clean them up [22:43:45] hmm - Roan is the SVN ninja - but... the typical approach is to save a diff of your version, revert, update and apply your diff [22:44:34] that took care of it, thanks [22:56:28] no worries [22:57:12] what's the variable for enabling side by side preview? [23:00:34] it's enabled by default [23:00:39] but go into your user preferences [23:00:45] cause that's not on by default [23:01:33] so I'm thinking about doing the layout change in the next hour and a half [23:08:41] alright, i'll be leaving in the next hour [23:11:08] want me to help, or just stay out of those files? [23:43:58] TrevorParscal: i'm headed home for the evening. If you make the change today, can you send a follow up email so I know where I can get started tomorrow? [23:44:08] sure [23:44:14] thanks