Ubiquity 0.6 Released!

About a week and a half ago, the Ubiquity team (I’m the one in red) had a little meeting at the 2010 Mozilla Summit and we discussed the past, present, and future of Ubiquity.

One of the main goals of this meeting, in my mind, was to get a new release of Ubiquity out, so that the greater masses could be exposed to all the wonderful work satyr has been doing over the past many months. After being reprimanded by the hotel staff no less than twice, we finally were able to get down and discuss the logistics of that. We had a couple of issues to deal with. For one, there were still a number of users on the 0.1.x branch of Ubiquity, despite the 0.5.x branch being available for quite a while, and the reasons for this included a lot of backwards compatibility issues: the 0.5.x branch used a new parser that could break some of the older, 0.1.x commands; the 0.5.x branch didn’t properly support Firefox 3.6; etc. And there was also the issue of the 0.5.x branch never being released on AMO, leaving many users unaware that it even existed.

So, originally, the idea was to release satyr’s code as 0.5.5—simply an extension of the 0.5.x branch. However, a number of people on the team felt it best to bump the version up to 0.6, and I didn’t disagree, given the aforementioned issues. And since we were attempting to clean the slate as best as possible with regard to backwards compatibility, I also suggested that we bump the minVersion up to Firefox 3.6 for Ubiquity 0.6, from 3.5 (which probably still works). This had the added benefit of allowing people stuck on Firefox 3.5 to keep plodding happily along with the 0.1.x branch (which has now—finally—been discontinued).

Before I continue, let me just point you to Ubiquity 0.6 on AMO so that you can download if you don’t already have it.

If you allow me to briefly jump ahead a bit, it was soon discovered that Jono (who had access to the AMO account, and who was charged with packaging the release) could not remember his Hg password. I don’t know if that has since been rectified, but the bottom line was that all the changes he made in order to package up the release could not be committed to the Ubiquity repository. So that left the repo and the released 0.6 package as differing from each other. (I think satyr has mostly restored those changes to the repo, but that was only within the past few days.) So releasing Ubiquity 0.6 was quite the event—and I haven’t even mentioned the fact that we completely sprung it on satyr! (I’d told him a few weeks earlier that I was gunning for it to happen, but he had no idea the meeting was even going down.)

Now back to the meeting, where we also discussed the future of Ubiquity. One of the most forefront targets, I think, would be rewriting Ubiquity as a JetPack (or at least with a JetPack wrapper). That would allow much more uniformity across the Ubiquity codebase, as well as giving Ubiquity access to all JetPack has to offer. Mitcho and cers attempted to take the first step towards that goal (that being the wrapper) during the JetPack Hack-A-Thon at the Summit, but ran out of time. So that work still needs to be done.

At the meeting, we also discussed resurrecting the effort to make Ubiquity more ubiquitous (Aza’s pun) by getting it incorporated into Firefox as Taskfox. I don’t recall what the first steps for getting that done are, but I think it’d be a worthy task.

So, at the end of the meeting, I (and, I think, the others) came out seeing the future of Ubiquity as brighter than we previously thought. All we need now are some brilliant, dedicated developers to make it happen. Unfortunately, many of said developers are spending their time with more high-priority tasks: Jono is working on Test Pilot; Mitcho and Aza are working on TabCandy; Atul and cers are working on JetPack. And these are all extremely worthy tasks. But if you want to help out with Ubiquity, don’t hesitate to drop by the #ubiquity channel on the Mozilla IRC server!

Do you use Ubiquity?

As you may or may not know, Ubiquity is officially “on hiatus”. That means that the official Mozilla Labs team is not currently working on it at the moment. Unfortunately, when they made that decision, the latest released version of Ubiquity (0.5.4) was not compatible with Firefox 3.6.

Luckily, community member Satyr Murky (satyr) decided to keep maintaining Ubiquity (all alone!) and was able to bring it to a state where it works in Firefox 3.6 and even the latest trunk builds off mozilla-central (mostly). Satyr also fixed a number of bugs that were present, beyond support for the latest versions of Firefox. Unfortunately, none of Satyr’s fixes have been made officially: Ubiquity has been wallowing in dev-only land in an Hg repository, downloadable only from a BitBucket attachment.

But now Ubiquity 0.5.5 is just about ready (see bug 528417), and I’d like to see it get released. Who’s with me?

Do you use Ubiquity? Which version? (The older 0.1.x line works fine on Firefox 3.6—did you downgrade your Ubiquity?) Did you know about the developmental version? (Your add-on updater didn’t tell you about it, after all.) Or were you too scared to install it? Let me know in the comments.

SVN Support in Bespin

A couple of weeks ago, I kicked off the addition of SVN support to Bespin (bug 493038). This required two things: One was the actual ability to choose which VCS you’re using, as it defaulted to Hg and the auto-detection was primitive and long since functional. (There were rumors that it had even been missing from the code for a while already.) But that was the relatively easy part, as it was mostly just manipulating HTML.

The (relatively) harder part was writing the code that would do the actual work with SVN. (VCS support in Bespin is powered by UVC.) A factor in this difficulty was that the backend code is written in Python, which I’m not especially familiar with. Nevertheless, the process was actually simplified by the way things are set up, because I was able to copy the Hg code and just modify to fit the SVN commands. I was able to add basic checkout, commit, and update support, as well as username/password authentication. Kevin later came in and finished up the push/commit differentiation, among other things. I believe SSH support still needs to be done, but we’re looking for a method to use to do it. (Kevin has suggested using environmental variables, as SVN does not have the ability to pass SSH details via command line, like Hg does.)

Kevin and the other Bespin folks are in the process of getting the 0.4.0 release out the door today or in the next couple of days, and that will include this support for SVN, as well as collaboration.

Real Tab Support in Bespin

Over the past week, I have been attempting to add real tab support to Bespin (bug 474055), under the guidance of Ben Galbraith (bgalbraith). Discussion on this issue has ensued in many places, including on Ben’s blog (in which he indirectly called me a weird hippie), as well as in at least two topics on the Google Group/mailing list Bespin Core.

The issue behind supporting real tabs is getting the editor to know that a tab is a variable width character. I was able to solve the problem of calculating just how wide that character is supposed to be, but that turned out to be the easy part. The problem that I’ve/we’ve been having is whether to contain all that knowledge in the cursor code (since it is essentially only a display issue) or to allow it to seep into the model code (which does all the actual text manipulation). That discussion is still ongoing right now, but either way, the change would require a little bit of refactoring of a lot of different functions, so that we can keep track of whether the function is getting the cursor position or the model position (as the latter is really just the nth index in the array, with all characters being equal).

So that’s where I’m at now. I’ve tagged the bug with the “student-project” keyword, since I’m a student and I’m working on the project, and I’ve posted a couple of patches in the bug to track my progress (the first one actually works, for the most part; the second one, not so much). All suggestions welcome.