So, I just started my day off with a big bowl of Apple Cinnamon Cheerios and some fresh orange juice, c\/o Mozilla Messaging.\u00a0 Thanks, team.\u00a0 \ud83d\ude00<\/p>\n
Another great thing about Mozilla is that, since its spread out around the world, somebody is awake and working pretty much 24 hours a day.\u00a0 That means if I write a bunch of code and go to bed, there’s a chance that when I wake up the next morning, the code review is done and I have some feedback on my next steps.<\/p>\n
And that’s more or less what’s happened at the start of today.\u00a0 That add-ons manager grouping feature I was working on for Firefox<\/a> got looked at in the night, and I got some feedback on some changes I can make.\u00a0 Awesome.<\/p>\n So here’s the scoop:<\/p>\n First off, a conversation got started regarding where add-ons with pending installs<\/a> or uninstalls<\/a> go.\u00a0 The answer:\u00a0 pending installs should go into the group they’ll be in once the install is complete<\/a>, and pending uninstalls should stay in the group that they were in when the install happened<\/a> (in order to prevent the add-on from jumping around in the list).\u00a0 That’s good – that makes my job easier, I think.<\/p>\n With regards to implementation, I don’t think my nifty Shwarzian Transform<\/a> is gonna fly:<\/p>\n I don’t think that this is the right approach to take here. Instead the more straightforward way is to just make sortElements accept an array for aSortBy (and update all callers to pass one) of fields to sort by in order of preference. If the elements match by the first field then move onto the second and so on. For the non-search list views use a specially named field “uiState” and then use your function as the comparison function for that field.<\/p>\n (from one of my reviewers)<\/a><\/p><\/blockquote>\n So this approach involves me changing a bit more code.\u00a0 See, my original approach was to try to change as little as possible.\u00a0 I guess that’s just me being the “new guy”, and trying not to rock the boat.\u00a0 But clearly, they want me to go deeper.\u00a0 I’m happy to oblige!<\/p>\n But there’s a bit more complication.\u00a0 According to the Bugzilla page, this bug I’m working on<\/a> depends on this other bug<\/a>, where somebody else is also tinkering with the sorting functions<\/a>.\u00a0 That means I have to be uuber careful, and make sure to base my work off of their patches.<\/p>\n In particular, it looks like this patch is going to be altering the sorting tests, and removing the ability for Firefox users to sort add-ons by anything besides the add-on name.<\/p>\n So what I’m going to do is download and apply this patch, and then start basing my work off of it.\u00a0 Each time the patch is updated in Bug 623207<\/a>, I’ll just re-base my work off of it.\u00a0 Nice.<\/p>\n Ok, so first of all, I wipe out my old work using hg strip (using Blake’s handy script<\/a> to find the HEAD revision number of that branch).\u00a0 Next, I grab the patch for 623207, and use patch to apply it.\u00a0 Then, I use pnew to create a new pbranch with that change, and then create another<\/em> pbranch on top of that.\u00a0 That second pbranch is where I’ll do my work.\u00a0 If\/when the patch to 623207 gets updated, I’ll update the first pbranch, and then merge it into the second.\u00a0 Awesome-sauce.<\/p>\n Argh.\u00a0 It seems I have to recompile in order to get that 623207 patch to work.\u00a0 And not an incremental compile either, since “make” doesn’t seem to do much in toolkit\/mozapps\/extensions.\u00a0 *sigh*…compiling<\/a>…<\/p>\n Just stopped by UofT to drop off my old keys, and get my old computer wiped.\u00a0 Stopped by and talked to Karen, and helped two new MarkUs<\/a> students.\u00a0 Kind of bitter sweet moment.\u00a0 Goodbye school.\u00a0 It was a long battle.\u00a0 Well played.<\/p>\n