[00:09:24] so when's the team going to re-skin popups? [00:09:51] <^demon> Isn't popups a gadget? [00:10:10] yes, but just about everyone has it enabled [00:10:43] and it also a heavily request feature from people who don't know about it [00:11:28] but surely the usability team can spend some time making mock ups of what a better implementation should look like [00:12:27] Just about everyone! [00:12:40] *bastique wants numbers. [00:13:02] I'd give you number if could read people's gadget's settings [00:13:25] <^demon> Well it's at least everyone - 1. I don't use it. [00:15:56] so it's a hyperbole, but the usage is high [00:16:31] maybe higher if we'd advertised as an advantage of creating an account [14:11:42] Hi, at pt-wikipedia, the featured article in other language star is not appearing in the interwiki links when using vector. Did you had the same problem at wiki-en? And how did you solve that? [14:12:21] GoEThe_wiki, do you have the javascript in monobook.js? [14:13:11] I don't have a personalized javascript [14:13:38] But there is something at http://pt.wikipedia.org/wiki/MediaWiki:Common.js [14:14:01] In the section ** Link destaque *************************************************************************** [14:14:02] * Descrição: Adiciona estrela ao lado da ligação dos artigos destacados das outras Wikipédias [14:14:04] ********************************************************************************************/ [14:17:47] Platonides: I was using Firefox 3.5 on Windows XP. I now checked in Internet explorer, and the stars work fine [14:18:37] on which page are you checking? [14:18:48] http://pt.wikipedia.org/wiki/Mina-S [14:29:37] the class is added correctly [14:29:45] for some reson the css isn't working :s [14:39:32] strange that it works on other languages, just not on pt [16:29:13] pdhanda, toc to me [16:29:22] heh [16:29:39] does that error have to do with visibility? [16:29:47] I heard someone complain about a show/hide javascript error. [16:31:05] bastique: it happens only when navigable table of contents are enabled and it is a very recent change, i don;t think it is visible in deployment [16:31:14] oh [16:41:05] pdhanda: Yeah yeah, I know, I need to fix that. But it's low priority for me ATM since TOC is not deployed code. Will fix this week [16:43:10] RoanKattouw: k thanks [16:43:35] RoanKattouw: good morning [16:43:50] Morning [16:43:54] I have to go in a few minutes [16:44:04] You'll need that time to read my e-mail anyway :P [16:47:38] reading [16:47:42] how's it going though? [16:47:45] when will you return? [16:47:59] 20-30 mins [16:48:02] I'm good [16:48:43] Aurora OK? [16:48:52] *RoanKattouw has to go now, feel free to continue talking to me [16:49:18] well, now that you are gone, I can finally get a word in edge-wise [16:49:19] ... [16:49:24] yet, I have nothing to say... [16:56:08] RoanKattouw_away: Just replied to your post in: http://www.mediawiki.org/wiki/ScriptLoader/Requirements#The_registration_interface [17:04:23] Hi, again. For your reference the following edit fixed the problem with the interwiki stars: http://pt.wikipedia.org/w/index.php?title=MediaWiki%3AVector.css&action=historysubmit&diff=20686774&oldid=20598689 [17:36:16] TrevorParscal: Back [17:36:27] hi [17:36:43] Main discussion script loader-wise seems to be the definition of resources at this point [17:37:02] Tim proposed a PHP array structure and Michael is making good points for why we need something that's at least partially JS-based [17:37:13] yeah [17:38:57] so, where are you at on that? [17:39:09] I think JS things should be done in JS when possible [17:39:27] spanning between languages and execution environments is never efficient or enjoyable [17:39:42] Well [17:39:54] There are good reasons for and against both [17:40:11] Of course an interface like loader.php?modules=j.ui|j.foo|j.bar is awesome [17:40:28] But there's an exponentially increasing number of possible module combos there [17:40:43] Potentially at least [17:40:52] well, what is building that list? [17:40:55] And you need to enforce consistent param order there or it gets worse [17:40:57] JS [17:41:00] Or PHP [17:41:03] then it can be consistent [17:41:08] either way really [17:41:17] if it's by hand, it's more diffucult [17:41:24] But for Squid, more variation in URLs = more stuff to cache = bad [17:41:27] and the cases where PHP is building the list are few [17:41:33] only the initial package really [17:41:41] Yes [17:41:49] You would need to make sure the variation in URLs is kept low [17:42:08] so, there's an interesting concept here, which is, the order only matters if the execution is involuntary [17:42:10] That's my main concern with a JS-based dep-resolver [17:42:23] ? [17:43:27] typically when a script loads, it starts writing to global variables (changing global state), looking around to see what else is loaded, binding to things in the dom, etc. [17:44:18] if we can make it so scripts are loaded as the contents of a function, we can execute that function when it's the right time, rather than when the script finishes loading [17:44:39] then the client sofware can satisfy dependencies in the proper order [17:44:55] no matter what order the scripts were concatenated in [17:45:11] meaning we can use simple rules for ordering requests, such as alphabetical [17:45:24] meaning we have really small numbers of variations [17:45:36] literally, the fewest possible [17:45:44] thoughts? [17:46:39] Right so you're saying don't load in order, but execute in order [17:46:45] yes [17:46:52] thanks for summing that up [17:47:01] Like mw.resourceloader.whenImReady( function() { dostuff; } ); [17:47:59] mw.resource.regiser( 'my name', function() { alert( "I'm alive!" ) } ); [17:48:03] some crap [17:48:04] etc. [17:48:38] all JS dependency information should be stored in and evaluated by JS [17:48:42] on the client [17:48:46] never on the server [17:48:48] imo [17:49:05] I just don't see the case for it if we can control execution order [17:49:08] If we can make that work in a way that reduces the URL variance I'm all for it [17:49:33] yeah, so then the urls will always use alphabetical order to list modules [17:50:05] Yes, that's a good first step [17:50:23] so you dont get the load.php?modules=a.js|b.js|c.js being diff. from load.php?modules=b.js|c.js|a.js [17:50:32] But then consider that for module1, module2, ... moduleN, there's 2^n possible requests still [17:50:49] (Granted one of those is empty, but my point is that that number gets huge quickly) [17:50:50] worst case [17:51:00] So we need to hit a minimum of that [17:51:10] Like minimize the possible combos we hit [17:51:12] but that's not very likely, there will be common sets that certain pages ask for [17:51:23] many, most even, of those combos will never be used [17:51:25] Yeah [17:53:30] Looking through the rest of the sheets now [17:54:08] cool [17:54:50] RoanKattouw: I don't think it will result in 2^n possibilities.. your limited by application flows [17:54:56] Yes [17:55:04] I know it won't be nearly as bad in practice [17:55:23] Just saying that there's no real upper bound on how crazy stuff can get, and we have to keep in mind that it needs to be tamed [17:55:47] to be on the safe side the resource loader should have a normal cache purge system [17:56:20] TrevorParscal: <3 division of work between you and me [17:56:35] *TrevorParscal is the client [17:56:56] mdale: nominal cache purge system? [17:57:06] I mean old stuff should be removed [17:57:30] what old stuff? [17:57:40] Yeah but there's multiple layers of caching [17:57:40] huh? [17:57:47] so a DOS variance of script-loader requests does not result in disaster.. although alphabetic order could be checked on the server too. [17:57:54] Caching in the RL itself should only store the most recent version of everything [17:58:02] But Squid will just keep old stuff around [17:58:05] oh [17:58:09] (and evict stuff with LRU I think) [17:58:39] so, the server will get the params, enforce alphabetical ordering, then serve up the (probably cached) version [17:59:01] so worst case scenario, they hit the apache cache [17:59:02] The *client* must also enforce alphabetical ordering [17:59:02] yep [17:59:06] yes [17:59:08] That's where it matters [17:59:09] RoanKattouw: agreed [17:59:16] he's talking about someone trying to mess with us [17:59:24] Ah yes [17:59:36] Yeah you can fill up Squid with that, but you can do that already [17:59:41] so, yeah, we won't regen on improperly ordered module params [17:59:54] Yeah, agreed, you need to reorder on the server side too [17:59:59] and the apache-side cache will still be quick [18:00:26] Yes [18:00:34] It might even serve a 304 response [18:01:08] makes sense [18:03:42] one issue with alphabetical is dependency order.. I know your mentioning above it would wrap the code in a callback and not load it until after.. but that is kind of complicated [18:04:06] It doesn't have to be output alphabetically [18:04:19] It's just the cache key that has to list stuff in alphabetic order [18:04:28] The actual contents can be in a saner order [18:06:04] well, the contents will be concatenated in the order they are requested [18:06:05] hmmm... would it have implicit ordering based on class name like $j.ui comes before $j.ui.drag [18:06:13] or explicitly map all that out in php? [18:06:16] mdale: how is this complicated? [18:06:22] no, no mapping in PHP [18:06:25] Hm well [18:06:34] It doesn't have to be alphabetical order, just consistent order [18:06:49] the registration doesn't have to actually be in the scripts [18:06:55] And whatever dep resolution algorithm we use should always spit out the same set of modules in the same order, hopefully [18:06:59] it can be generated, inserted at the top and bottom of the scripts [18:08:00] yea.. the server can alphabetize and use that for the hash [18:08:04] so jquery ui for instance would get "mw.loader.register( '$j.ui', function() {" at the top and "} );"; at the bottom [18:08:33] you don't need to add that manually, it's always predictable [18:08:39] TrevorParscal: hmm [18:09:11] TrevorParscal: So between all the script loader fun, I was hoping you could look at the details of this sentence level editing idea I was telling you about earlier and maybe tell us what you think http://eiximenis.wikimedia.org/SentenceLevelEditing [18:09:15] there is no dependency map on the server, just a map of "module name" => '"file name" [18:09:24] awesome [18:09:47] bookmakred it [18:09:51] will poke [18:10:40] mdale: hmm? [18:10:50] is that a good hmm or a skeptical hmm? [18:10:53] TrevorParscal: I don't know if you get that much millage out of what your proposing [18:11:04] milage? [18:11:10] mileage [18:11:19] opps .. yea mileage i mean :) [18:11:25] i've seen it both way :)) [18:11:44] you proposing the resource loader add that js? [18:11:52] it could [18:11:56] that's not the critical part [18:11:59] but it would be nice [18:12:01] then for raw file mode you will have to not load alphabetically? [18:12:14] or modify all the files. [18:12:15] because otherwise you would have to modify generic jquery plugins for use with MW [18:12:17] which would suck [18:12:20] yea [18:12:44] mdale: the raw file thing is still up in the air, but yes, that would be a side-effect [18:13:00] then again [18:13:00] I don't see the value [18:13:03] while in "raw" mode [18:13:17] it adds complexity for very small gain [18:13:29] all the javascript modules will be requesting things in the same order anyway [18:13:38] if you hit a cache you hit it.. if you don't .. you don't [18:13:44] spare the initial packages rendered into the page's HTML by PHP, the loader can request them individually in proper order can it not? [18:14:26] mdale: i doubt the modules will always be requesting things in the same order [18:14:36] think about all the cases where dynamic loading is going to happen [18:14:37] yea describe the context where that register would be valuable over just having the script register its self into window['whatever my script defines'] [18:14:45] user scripts, extensions, custom site JS [18:14:50] none of this is controllable [18:14:56] right... but if the server can respond 304 [18:15:02] is that a big loss? [18:16:00] more likely the request set does not include the same set of scripts. then order does not give you advantages since your concatenation will be different [18:16:32] mdale you are missing that we need to server to either understand the order because of dependency resolution and concatenate accordingly, or the order needs to not matter [18:17:14] and if we have to put dependency resolution logic on the server and the client, it's uber-fail for developers [18:17:20] right [18:17:32] so I would lean towards the server not caring. [18:17:58] but then you end up with all these crazy combinations of scripts being requested [18:18:14] I don't think it will be all that common that module A request ABCD and module B requests ACDB [18:18:32] and we need some sort of generic way to make sure tha a,c,b and a,b,c and c,b,a are actually the same thing [18:18:38] if ABCD is a common request set then it should be defined via a named module ABCD [18:18:53] and the module will have a single order to load things [18:20:24] I feel like that's giving developers who are specifying dependencies too much credit - how are they going to know the proper order? they are just listing dependencies, and when you have multiple modules all playing into a grouped request, you are going to end up with a wide variety of cases based on user interaction differences [18:20:33] like when I am invoking the embedPlayer in a bunch of different contexts I am not running mw.load( EmbedPlayerdependencieA, EmbedPlayerdependencieB, EmbedPlayerdependencieC, ... ) ... I just run mw.load( 'EmbedPlayer', ... ) [18:22:21] but there are going to be allot more libraries than just those... [18:22:23] if I want to add TimedText to my EmbedPlayer... I don't run mw.load( 'EmbedPlayer', myTimedTextModule ... ) ... instead I run $j( mw ).bind( 'Load.EmbedPlayer.UpdateRequest' ... add myTimedTextModule ... embed player module loader now puts that in the right order [18:22:53] We could still do what Trevor said: not care about concat order and fix it by executing them in order [18:23:18] mdale: I fail to see the benefit to not controlling the execution order [18:23:53] you do control the execution order by the order in which your request your resources [18:23:54] it' a safety net [18:24:27] so that we don't have to be paranoid about the request order [18:24:43] and also so we can group as many similar requests as possible [18:24:47] for caching efficiency [18:25:21] in the odd case of someone trying to DOS us, we can handle that somehow, but the general case is, we can use simple logic to order them [18:25:21] is this on page-output or dynamic mw.load requests? [18:25:36] either way [18:25:46] PHP can alphabetize just as well as JS [18:27:09] because, if we care about the loading order, how does a PHP extension ensure it's including things in the right order on initial page load [18:27:10] ? [18:27:25] when the definition of correct order is in the JS space [18:28:24] mm it just includes them in the order it needs them? [18:28:41] like $j.ui, $.ui.dialog [18:29:15] if extension B comes along and says I also need $j.ui, $.ui.fish ... then the script output would be $j.ui, $.ui.dialog $.ui.fish no? [18:29:32] how would $.ui.fish get ahead of $j.ui ? [18:30:56] why are you against controlling execution order? [18:31:09] hehe I am pro execution order :) [18:32:04] it's not so much about $j.ui then $j.fish it's solving issues like $j.ui then $j.fish then $j.submarine vs $j.ui then $j.submarine then $j.fish [18:32:22] we need to reorder them, without knowing anything about them (in PHP) [18:32:47] we need to reorder them to make the 2, otherwise identical in behavior requests, be the same [18:33:08] to avoid generating a similarly functioning file 2 times [18:33:37] and to do that safely, we need execution order to be controlled in the JS space, independently of loading order [18:34:11] ... because the loading request order .. would be out of order? [18:34:18] because PHP doesn't understand that fish and submarine both need to be after ui but it doesn't matter which order they are in after that [18:34:47] and we are trying to avoid making PHP understand that [18:35:09] why would php put fish or submarine before ui? [18:35:24] ~ white boards are so much easier ~ [18:35:35] because it's trying to make the ACB and ABC and CBA requests the same [18:35:56] and there's allot of different extensions asking for different modules at different times on different pages [18:35:59] with different configurations [18:36:11] which makes all sorts of ordering variations [18:36:15] because it's chaos [18:36:19] we must control the chaos [18:36:29] by controlling the execution order [18:36:32] I think that would be better solved with some core defined javascript modules [18:36:57] I like the idea of being able to parallelize the core modules with the other code though [18:36:58] yes, the core modules will have the information on what to execute in what order [18:37:10] correct [18:37:20] sweet [18:38:32] let's try and agree allot [18:38:36] ;) [18:40:46] ... yea the core module will request things in the same consistent order ... so that even if there is an on-demand module like add-media-wizard, It can register that the "core ui" request should include $j.ui.whatever .. so then when add-media-wizard is dynamically invoked it can share that $j.ui.whatever from other modules that also registered that they needed that as part of their "core ui" module dependency ... is that about right? [18:42:39] mdale: yes [18:42:48] *TrevorParscal goes to lunch [18:42:50] later [18:42:51] be back soonish [19:33:07] RoanKattouw: i'm back from lunch [19:33:16] what are you up to? [19:33:32] Poking at pthreads for school [19:33:35] Need me for anything? [19:35:25] just synthesizing all these requirements into a specification [19:35:42] there's some conflicting requirements [19:36:08] such as, supporting stand-online use vs. not [19:36:37] Right [19:36:43] I agree with Tim on that one [19:36:45] seems like a non-non-contraversial decision [19:37:08] I'm also not really seeing the value in everything working with and without the laoder [19:37:18] I believe that stand-alone support (assuming that's what you meant) would be nice but is not something WMF will use [19:37:19] the argument had to do with debugging [19:37:31] Therefore WMF should not pour time/money into it [19:37:33] but I think there are much simpler ways to make debugging easy [19:37:50] Yes [19:38:05] there's 2 points, 1 is that scripts should work if included directly as files, without the loader [19:38:34] and the other is that the loading system be able to be divided off from MediaWiki and used for another project [19:39:17] on the first one, I think that's a silly requirement if debugging easiness is the rationale, because there are much more clever ways to make debugging easier [19:39:48] what about enabling debug mode if a determinate cookie is present? [19:40:04] that would make things easier than adding parameters to the url [19:40:39] it has its own share of cache headers issues, of course [19:41:06] Platonides: there's plenty of ways to do it, essentially what is needed is for all scripts to be loaded un-minified/compiled [19:41:15] so line-numbers match to original source [19:41:15] g [19:41:37] <^demon> I'm with Trevor on those points. I don't see the overall benefit to MW either, even outside of WMF [19:42:17] <^demon> The standalone seems like extra work with minimal ROI. [19:42:57] it seems like what we should be focusing on, is ensuring that large software libs don't have to be specially written in MW conventions just to function, but things written with MW conventions don't need to work other places [19:43:04] aka, jquery shouldn't need to be modified [19:43:34] but the mw.loader system need not be as generic and back-end agnostic as jquery is [19:44:12] ^demon: when are you coming to SF? i think I asked but don't know if I got an answer [19:44:22] <^demon> I don't know the answer either :) [19:44:29] RoanKattouw: btw: we are going to book your travel soon, like today/tomorrow [19:44:37] we need more specific dates from you if possible [19:45:01] ^demon: well we are supposed to be getting you here sometime, how's your avil? [19:45:45] <^demon> Out of school until late August. Just have to take time off from Capital One to fly out. [19:46:23] any ideas of what you want to work on while you are here? [19:46:49] <^demon> I'm assuming I'll still be working on FR/PC stuff. [19:47:18] right on [19:47:31] <^demon> I *want* to put some more volunteer time back into the installer. It needs still needs lots of work to clean it up for 1.17 [19:47:43] well, afaik you need to just let us know, keep in mind Wikimania and OSCON dates will thin the office out a bit [19:48:20] <^demon> Neither of which I'm going to ugh. I need to find a conference in DC or something. [19:48:49] we need to do a WMF dev conf in DC imo [19:49:10] <^demon> That's the plan...we just need to all sit down and talk about it. [19:49:12] TrevorParscal: I sent Danese these dates a few weeks ago. I can fly in on Sun Aug 22 at the earliest (from AMS, it turned out flying out of BRU wasn't convenient) and fly back on Sat Sep 4 at the latest [19:49:27] ok [19:49:38] *RoanKattouw is looking forward to an East Coast dev conference [19:49:40] RoanKattouw: brb, talking to people who will do this [19:49:52] Means I get to visit the East Coast, hopefully during the winter [19:50:46] The fact that I've never flown to a place where it freezes in winter depresses me [19:51:58] <^demon> DC gets pretty cold in the winter. [19:52:05] Yeah [19:52:10] <^demon> Certainly colder than here, and it's only 2hrs north. [19:52:38] Dude the avg max temp in an SF winter is like 14 C / 58ish F [19:53:12] That confused the hell out of me when I flew in in January, having walked to the train station in -7 C / 20 F [19:53:46] <^demon> I just hope it doesn't snow during our dev conference in DC. [19:54:02] <^demon> Blizzards last year shut down the airports on more than one occasion. [19:54:14] Yeah I hope there's no /disruptive/ snow [19:54:21] We got a fair bit of that over here last winter [19:54:27] <^demon> Non-disruptive snow is pretty :) [19:54:47] In fact, that flight in January I spoke of got bumped because I was flying through LHR and that airport was snowed in [19:54:59] So I got to go to the airport again the next day for a direct flight [19:55:58] RoanKattouw: that's leaving SFO on 9/4 or landing home at AMS on 9/4 ? [19:56:08] <^demon> I'm going to need someone more organized to help me set things up though. I know nothing about organizing a conference :P [19:56:20] Leaving on the 4th [19:56:23] Arriving on the 5th [19:56:24] k [19:56:28] The 4th is a Saturday, right? [19:57:18] yes [19:57:25] Yeah so that one [19:57:32] Uni starts on Monday [19:57:35] So I need to arrive on Sunday [20:01:01] RoanKattouw: so, explain the 304 thing? [20:01:27] why would we send not modified to someone who asked for modules in non-alphabetical order? [20:01:37] That's not what I was saying [20:01:41] do you mean 303| [20:01:53] What I was saying was that in some cases, we're not returning real stuff but just a 304 [20:02:03] This applies in general, not specific to the order discussion [20:02:12] ok [20:03:08] I said it in reference to your "and the Apache cache will be quick" [20:03:09] if someone asks for things in the wrong order, can we just give them a 301 to the URL with the right order and the squid will from then on out not hit the apache? [20:03:19] We can [20:03:25] Squid should cache 301s as well AFAIK [20:03:38] cool [20:03:55] And Squid's caching and handling of 304s is seriously awesome [20:04:14] It has all kinds of features so it relays 304s and even sends its own 304s when it can [20:04:34] When I asked "Does Squid support 304" I was told that was equivalent to "Does Firefox support HTML" [20:09:14] The question is, is it possible for squid to get a 301 from the apache, and then just send the client the redirected page silently? [20:09:47] so any order of modules will always get a direct response from the squid rather than a possible redirect? [20:10:06] Ah, no, I don't think so [20:10:14] It would make more sense for it to just cache the 301 [20:10:21] right [20:10:26] just wondering [20:10:36] After which the client follows the 301 and gets the real content served, hopefully also from cache [20:10:47] Also, your approach introduces purging hell [20:10:57] Whereas the 301 doesn't really become invalid ever [20:12:23] TrevorParscal: I am not completely sure Squid caches 301s the way I think it does though, lemme check that [20:12:40] cool [20:15:11] one thing that seems to be happening with this approach is a nessecary 1:1 file:module ratio [20:15:14] which imo is a good thing [20:15:18] and is common [20:15:24] hmm [20:15:25] maybe not [20:15:31] you could have multiple modules in a file.. [20:15:33] nevermind [20:16:38] this will combine modules [20:16:42] *files [20:16:52] Yeah but we're not looking to generate combined files [20:16:53] i'm saying in original source [20:16:55] But to combine in PHP [20:16:55] so no problem in setting a rule that there is only one module per file [20:17:14] i was just tripping out... don't mind me :) [20:17:58] but if you have a file, that has 2 modules in it, it will get wrapped with mw.loader.register( ['module 1', 'module 2'], function() { ... code in the file ... } ); [20:18:14] meaning if you want them to be loadable individually, they will need to not be in the same file [20:18:21] otherwise they will always load together [20:18:33] because writing software that can cut up JS files is not a good idea [20:18:34] TrevorParscal: Answer from the experts: Squid will cache 301 happily as long as we set the appropriate Cache-Control headers [20:18:41] Agreed [20:18:47] RoanKattouw: good stuff [20:18:49] Let's just encourage the 1:1 approach [20:18:54] agreed [20:19:04] And hush up the fact that our software secretly allows multiple modules in one file [20:19:13] :) [20:19:25] it will happen automagially [20:19:28] but quietly [20:19:29] Basically we would write no code to facilitate or prevent it [20:19:57] And what happens when you try to use it, who knows, it might work, it might break [20:44:41] what should be the behavior if a dependency fails to load [20:45:07] How do I rebuild WikiEditor.combined? [20:45:20] *.js [20:45:24] should be as easy as make -b [20:45:30] or make clean [20:45:30] make [20:45:38] while in the UsabilityInitiative folder [20:45:43] on a non-windows machine [20:46:17] if you are on OSX, there's bug that causes a UsabilityInitiative.hooks.php-e file to be created, and it needs to be discarded [20:46:29] Is there a debug mode to load seperate files? [20:46:32] TrevorParscal, is it still happening?? [20:46:41] last time I used it... [20:46:42] vvv, I think you can add ?debug=true [20:47:35] r68034 should have fixed it [20:49:08] Platonides: it still loads combined files [20:51:33] TrevorParscal: I see toolbar has its groups named. Are those names used ("format", "insert") somewhere? [20:51:49] yes [20:51:51] the API [20:52:02] it's how they are identified for later modification [20:52:10] like adding something to them, removing them, etc. [20:52:22] Wait, which API? [20:52:27] the toolbar API [20:52:32] the WikiEditor API actually [20:53:10] see the UsabilityInitiative/js/tests/wikiEditor.toolbar.js file [20:53:21] Then why there are two "format" groups (in main and advanced)? [20:53:54] yes [20:54:27] vvv: $wgUsabilityInitiativeResourceMode = 'raw'; for raw files [20:54:40] RoanKattouw: thanks [20:54:47] $j( '#wpTextbox1' ).wikiEditor( 'call', { ...options... } ); [20:54:58] see the example calls in the tests file [20:55:04] vvv: Two groups so we get a group separator between the two [20:57:45] So, the structure of toolbar is "bar (main/advanced/whatever) -> group (insert/format/whatever) -> control (insert button or combobox)", right? [21:03:45] Yes [21:04:00] "bar" is called "section" internally, but that's the structure, yes [21:04:17]