Category: mozCC

MozCC with Firefox 1.5 Beta 2

Just a quick note to head off the stream of email I’ve been receiving (yes, both of them): mozCC doesn’t work with Firefox 1.5 Beta 2.

Actually if you tried to install it, you’d be told it’s not compatible, since mozCC 1.1.2 claims it’s only compatible with Firefox 1.4 (the internal version for Beta 1). At first I thought this was gratuitous version incrementing, and then I discovered that after incrementing the supported version in mozCC, it doesn’t work. At all. I’ve tracked down the problem and hope to have a release out later today or tomorrow that fixes both this compatibility issue as well as a rather embarassing issue pointed out by Jeff yesterday. Stay tuned.

UPDATE: Just to be clear, it’s not really gratuitious per say to increment the version from 1.4 to 1.4.1 — I just assumed it had gone to 1.5; mea culpa. Also, the update is now available.

date:2005-10-09 10:47:04
wordpress_id:342
layout:post
slug:mozcc-with-firefox-15-beta-2
comments:
category:mozCC

mozCC 1.1.2 Out

mozCC 1.1.2 is out; no feature improvements, just compatibility with Firefox 1.5 (and current nightly builds, alphas, etc.). I am working on some improvements to mozCC which should improve the overall user experience. In particular, I want to handle the following situations:

  • support for embedded, licensed content: Currently mozCC looks for a page license, and displays it’s information in the status bar. It’s perfectly valid, however, to license the text of a page with one license and the photographs with another. So we want to have an easy way for users to see that distinction.
  • support for discovery: mozCC lets you see that content you’ve found is licensed, but how do you find new licensed content? I want mozCC to help with that.
  • support for remix and re-use: I have two pages, can I mix them? Under what license? mozCC knows about the licenses in use, so I hope to help users re-use content.

To people who have inquired about localizing mozCC, I’m holding off until I get some of these fixes landed. They’re going to change lots of the internals, so it doesn’t make much sense to translate strings that may very well change or go away. If you’re interested in helping to localize mozCC, contact me, or subscribe to my blog’s feed — I’ll announce a call for translations there.

As always, let me know if you have any problems with the new release. Users who’ve installed an update to Firefox and found mozCC marked as “disabled” should be able to click “Find Updates” from the extension manager and download it auto-magically.

date:2005-09-08 09:52:45
wordpress_id:328
layout:post
slug:mozcc-112-out
comments:False
category:mozCC

mozCC 1.1

mozCC 1.1 is now available for download. This release corrects a few bugs, including:

  • license attributes were not displayed correctly on pages which published Work metadata (with a license reference) but no License block
  • pages which contained multiple work elements (including those at, ahem, ccMixter) weren’t displayed correctly
  • some pages incorrectly displayed license elements (such as the “by” icon) multiple times

This release should be picked up by the Firefox Update Manager. You may also download it directly from the mozCC install page.

date:2005-06-13 10:36:23
wordpress_id:303
layout:post
slug:mozcc-11
comments:False
category:mozCC

Secrets

All Things Considered had a story yesterday on PostSecret, a web site which invites people to send in postcards with their deepest secrets, and have them posted online. Some of the secrets are poignant, and some and a little scary. But what an amazing way to connect people in collaborative art that can actually move people.

Oh, and in less interesting news, mozCC 1.0 is out. I guess I have to remove the bit about it being “pre-release software” now.

date:2005-03-31 10:19:35
wordpress_id:282
layout:post
slug:secrets
comments:False
category:mozCC, my life

mozCC 0.9.9 Available

So I promised a new release of mozCC to users back in December. And it was released… this morning. Right, so you can see the release announcement for all the gory details. The cool thing is that this is the 1.0 Release Candidate and we’ve fixed a couple of bugs that were pretty annoying. So update your installation, and get your feedback and bug reports in so we can get 1.0 out the door.

date:2005-02-23 12:04:23
wordpress_id:262
layout:post
slug:mozcc-099-available
comments:False
category:mozCC

Updating mozCC

I recently announced the release of mozCC 0.9.0, promising that existing users could simply use the Extension Manager to update. Apparently I was wrong. The update.rdf format changed from Firefox 0.9 to 1.0PR, but thanks to Jed Brown’s excellent resource, that problem has been fixed. Update away!

date:2004-10-14 07:23:05
wordpress_id:214
layout:post
slug:updating-mozcc
comments:
category:mozCC

mozCC Update

From the mozCC News page:

mozCC 0.9.0 has been released. This upgrade includes support for the new Developing Nations license, as well as improved detection and support of the Sampling and Sampling+ licenses.

It’s not a huge upgrade, but more of a maintenance release; check it out and let me know if you find any bugs or have any suggestions.

I also just realized that the screenshots on the site are horribly out of date, displaying a details dialog that’s be gone for half a dozen releases. Here’s a new screenshot, showing off the new details dialog. And by “new” I mean “added in the last 9 months.”

date:2004-10-11 15:45:36
wordpress_id:208
layout:post
slug:mozcc-update
comments:
category:mozCC

mozCC 0.8.3 released

(reposted from mozCC news)

mozCC 0.8.3 has been released, and all users of mozCC are encouraged to upgrade. mozCC 0.8.3 is a bug fix release which corrects conditions which caused Mozilla and Firefox to lock-up when certain license combinations were encountered. Pages impacted by this bug include the Creative Commons license selection process.

Firefox users can seamlessly upgrade by going to the Extension Manager, clicking on mozCC, and then clicking the Check for Updates button. The XPI can be found in the release archive.

As always, comments, feedback and bug reports are welcome. Send them to mozcc@yergler.net.

date:2004-07-27 12:04:03
wordpress_id:162
layout:post
slug:mozcc-083-released
comments:
category:mozCC

The Importance of dot-slash

Sometimes it’s the little things. Often it’s the little things, I guess. I like to write cross-platform software. The less I need to worry about whether I’m building on Mac OS X, Win 32 or Linux, the happier I am. mozCC was one of the first projects I developed that had to run on all three platforms, and as such, I wrote a set of scripts and tools for building and testing the code base.

During the development of 0.8.0 I transitioned from my original build script, make_jar to a more generic version I developed for DemoExt, build.sh, which was generally a “good thing.” Around the same time I noticed that building mozCC on Mac OS X didn’t work quite right. OK, it didn’t work at all. It would appear to build, but installing that build just didn’t work. Nothing. Nada. No acknowledgment that mozCC was installed at all. Of course, I was in a hurry to get 0.8.0 out the door, so I turned my chair, turned on my Linux box, and proceeded to build there. And funny thing, the builds from Linux worked just fine on Mac OS X.

Today I’m working on fixing a serious bug in mozCC. I’m at OSCON, and only have my iBook. And I had completely forgotten about the build problems from 0.8.0. After beating my head against the wall for an hour yesterday and about an hour this morning, I finally figured it out: it’s all about the ./ (dot-slash).

Build.sh is a simple shell script that assembles the necessary files for a Mozilla extension in the appropriate relative locations for the JAR. To pull out the list of files to zip up into the JAR, it uses the UNIX utility find. In particular,

find ./content -path './*CVS*' -prune -o -type f -print | grep -v ~

What I found was that on Linux, find returns a list of files with relative paths and no leading dot-slash. For example,

 1926  06-25-104  12:47   content/mozcc/prefs.xul
 1560  06-25-104  08:25   content/mozcc/prefsOverlay.xul
 2708  06-25-104  12:47   content/mozcc/seamonkey-prefs.xul
.
.
.

Mac OS X (and maybe BSD, I don’t know how deep this goes), on the other hand, returns files with a leading dot-slash:

 1926  06-25-104  12:47   ./content/mozcc/prefs.xul
 1560  06-25-104  08:25   ./content/mozcc/prefsOverlay.xul
 2708  06-25-104  12:47   ./content/mozcc/seamonkey-prefs.xul
.
.
.

And this breaks Mozilla and the extension. A subtle change to the find command, namely removing the dot-slash, fixes the problem (at least on Mac OS X). I’ll have to test it on Linux to make sure it works in a cross-platform manner, and then I’ll update DemoExt.

Success: the sweet taste of frustration.

date:2004-07-27 11:23:15
wordpress_id:161
layout:post
slug:the-importance-of-dot-slash
comments:
category:development, mozCC

The Road to 1.0

Now that I’m actually getting paid to work on mozCC, we’re starting to discuss what’s necessary to call it 1.0. Generally, I think that there’s three things a 1.0 should represent (I say “should”, not “does”; we’re talking best practice here):

  • stability: a 1.0 shouldn’t crash, cause corruption or otherwise seriously break things
  • polish: a 1.0 should look complete, and look like the UI has actually received some lovin’
  • longevity: more on that in a moment.

I think we’re well on the way to mozCC 1.0. The 0.8.1 release addressed issues with both stability and polish, and began to address longevity.

So what do I mean by longevity? I don’t mean to imply that a 1.0 is a stopping point for development, or that every feature has to be fleshed out and complete to be a successful 1.0. What I mean is that 1.0 should be a platform for users to trust and depend on. The recent release of 0.8.0 is indication that we’re not quite there with mozCC. For 0.8.0, I unfortunately reorganized the code in a way that I viewed as necessary, but which required me to recommend that users first uninstall previous versions before upgrading. This sort of extraneous requirement exposes more of the underlying mechanics than users should need to know about. They shouldn’t care that the code was reorganized: they should only need to care that performance and functionality improved. A few days after releasing 0.8.1, I have a few bug reports, but none relating to the upgrade process. This leads me to believe that we’re making progress on the longevity front.

So what needs to happen before 1.0? Here’s the short list:

* support the remaining methods of embedding RDF in HTML, as specified here * make the details UI Mac OS X friendly; it currently doesn’t look quite like it belongs * make sure linked RDF is working correctly; Wikipedia is the most visible test case for this * resolve outstanding lock-up issues; these are few and far between, but I do have two reported with 0.8.1

At this point, there’s only one thing we’re pushing out to post-1.0, and that’s support for RDF embedded in SVG, and viewed with the Adobe viewer (we already support RDF+SVG with native Mozilla SVG support).

If you have any suggestions, or think I missed something, “open a bug” or contact me.

date:2004-07-12 13:54:04
wordpress_id:150
layout:post
slug:the-road-to-10
comments:
category:mozCC