The roads I take...

This has been a long time coming, actually, and recent developments just put the final nail in the coffin.

I am ending all development and support for my "extension"-type add-ons effective immediately.

This affects (daily user numbers according to addons.mozilla.org):

• Jökulsárlón Download Manager (almost 500 daily users, source on hg.m.o)
• KaiRo.at Mandelbrot (roughly 1000 daily users, source on git-public.kairo.at)
• Tahoe Data Manager (slightly over 300 daily users, source on hg.m.o) - this is also a default part of SeaMonkey.

If anyone is interested in taking over development and maintenance of any of those, please let me know and I'm happy to convert their repositories over to github for easier working with them, and and the new developer to their administration on AMO and/or move them over to you completely.

I will leave them listed on AMO for a little while so people who want to take over can take a look, but I will hide them from the site in the near future if nobody is interested.

The reasons for this step are multiple:

For one thing, I just don't have the time for updating their code or improving them. My job is stressful enough that my head is overflowing with Mozilla-related things all the time, and my employer is apparently not willing to give me any relief (in terms of hiring someone to supplement me) that would give me back sanity, so I need to remove some Mozilla- and software-related thing from my non-work time to gain back a little sanity so that I don't burn out.

I am also really sad that apparently nobody finds the time or energy to make decent managing and notification mechanisms available for UI code around the new-style web storage mechanisms like indexedDB, appCache, or ServiceWorkers caching, while we do have quite nice APIs there for long-standing things like cookies. For getting Tahoe Data Manager (which was my most interesting add-on) to work decently, I would have needed decent APIs there as well.

Then, my interest for experimenting with code has moved more and more away from the browser, which keeps changing around me all the time, and towards actual web development, where existing code doesn't get broken all the time and your code is more isolated. As a bonus, I can develop things that run on my (Firefox OS) phone and that I can show other people when I'm somewhere. And even there, I don't get as much time to dig into stuff as I would like to, see above.

And finally, and that's why this culminates right now, I disagree with some pieces of Mozilla's add-on strategies right now, and I don't want to be part of that as an add-on developer.
For one, I think add-on signing is a good idea in principle, but not enabling developers to test their code in any way in the same builds that users get is against everything I learned in terms of quality assurance. Then, requiring developers and other users of unbranded (or early pre-release) builds to turn off security for everything just to use/test one or two unsigned add-ons just feels plainly wrong to me (and don't tell me it can't be done otherwise, as I know there are perfectly good ways to solve this without undermining signing and preserving more safety). And I also fear that, while add-on signing brings a lot of pain to add-on developers and will make us lose some of them and their users, we will not reduce the malware/adware problem in the mid to long term, but rather make it worse, as they will resort to injecting binary DLLs into the Firefox process, which is the primary cause of startup crashes on updates, and I will have more grief in my actual job due to this, next to Firefox losing users that see those crashes.
And on the deprecation of "the permissive add-on model" as they call it in the post, I think that the Firefox UI being written in web (CSS/JS/HTML) or web-like (XUL) technologies and the ability to write add-ons that can use those to do anything in Firefox, including prototyping and inventing new functionality and UI paradigms, is the main thing that sets Firefox apart product-wise from all its competitors. If we take that away, there is no product reason for using Firefox over any other browser, the only reasons will be the philosophy behind Mozilla (which is what I'm signed up for anyhow)and the specific reflection of those in some internals of the browser, like respecting privacy and choice a little bit more than others - but most people consider that details, and it's hard to win them over with those. Don't get me wrong, I think that the WebExtensions API is a great idea (and it would be awesome to standardize some bits of it across browsers), and add-ons being sandboxed by default is long overdue. But we also would need to require less signing and review for add-ons that are confined to the safe APIs provided there, and I think we'd still, with heavy review, signing, and whatnot, need to allow people to go fully into the guts of Firefox, with full permissions, to provide the basis for the really ground-breaking add-ons that set us apart from the rest of the world. Even though almost all of the code of my add-ons ran within their own browser tab, they required a good reach into high-permission areas, which probably the new WebExtensions API will not allow that way. But I also do not even have the time to investigate how I could adapt my add-ons to any of this, so I decided to better pull the plug right now.

So, all in all, I probably have waited too long with this anyhow, mostly because I really like Tahoe Data Manager, but I just can't go on pretending that I will still develop or even maintain those add-ons.

Again, if anyone is interested in taking over, either fully or with a few patches here and there, please contact me and I'll help to make it happen.

(Note that this does not affect my language packs, dictionaries, or themes at this point, I'm continuing to maintain and develop them, at least for now.)

"Jökulsárlón" is an Icelandic glacier lagoon that has pieces breaking off the glacier and swimming through it as icebergs on their way to the sea, just like files through the download manager.

My newest add-on for Firefox 4 and SeaMonkey 2.1 is using this code name and makes the download manager UI run inside a browser tab and in a tabular style similar to what SeaMonkey is using. It also supports the use of progress windows instead of the download manager if preferred.



This is using the code I wrote earlier for SeaMonkey's download manager and even progress window UI, those interested in the actual code find it in the add-on source repo.

I'm not planning to backport this code to older versions than Firefox 4 or SeaMonkey 2.1, any time I put into this id better spent on improving what's there and I'd rather convert more of it to use things like Services.jsm, which only exists in Mozilla 2 code.
I will also not backport this work to SeaMonkey due to the discussions that had been going on around the progress windows. I'd happily support people porting code though - and I'd also accept patches to improve the add-on if anyone wants to help, of course.

And for everyone else, if you're interested in a download manager running inside a tab in a tabular interface, please test this add-on and give feedback!
Right now, it's not reviewed for public on AMO yet, it's in the sandbox, but that shouldn't stop you from testing it - feedback comments improve the chances of the add-on being made public!

The culmination of a long stream of work has just happened: The switch to the toolkit download manager has just landed on comm-central, along with the reworked tree-based download manager UI and the rewritten per-download progress windows (which formally aren't "dialogs" any more).



This is a rather large change code-wise: hg diff -r qparent -r qtip | diffstat before doing the actual qfinish and push told me that all those patches result in:
53 files changed, 5766 insertions(+), 620 deletions(-).

Most of the new code is the manager and progress UIs as well as the tests, the actual switch patch removes more than it adds due to obsoleting pref-applications-edit.xul, which the old file handling dialog needed to save the "remember this decision" checkbox info (yes, an evil hack).
Once we come around to remove the code we actually obsoleted in the mozilla-{central,1.9.1} tree, the deletions of that work will probably outweigh the current insertions of code lines overall - some of the obsoleted code might even still be packaged but not used by toolkit (and therefore, even Firefox).

Thanks to Justin (Callek) for figuring out how to do this all and taking on the work to make the actual backend switch (really work), thanks to Frank (mcsmurf) for fixing all the review comments to the actual switch patch while Justin is mostly absent due to being busy with work and family and not having a useful Internet connection around - and thanks to Neil for all the reviews.
Thanks for MDC and MXR and whoever wrote up useful in-code description of the tree interfaces that are not documented usefully on MDC yet, thanks to those who made it able that dropping in a custom UI to work with the toolkit download manager works at all.
And thanks for all the people who have been patiently waiting for this to happen - including the localizers who couldn't have fully working localized builds - up to now.

And here's what this means for you:

• If you are a SeaMonkey user, you will see a reworked download manager appearing in any 2.x builds from now on, starting with tomorrow's (!) nightlies, and 2.0 Beta 1. This implementation can resume downloads (even across sessions), search in your performed or ongoing downloads, clear the list of completed downloads through "Clear Private Data" and store more download history without making SeaMonkey startup time longer, among other things.
• If you are a localizer, you will see the localized builds working fully (and can advertise them to your testing community), including the download manager, also starting with those nightlies and (pre)release.
• If you are a Mozilla or extension developer, you can count on SeaMonkey supporting/using the full toolkit download manager backend from now on.

There surely are a number of things to improve in the UI still, a number of which are filed as dependent bugs of the download manager and progress UI bugs linked above. We are in a state though where we feel we are ready for putting what we have into the upcoming SeaMonkey 2.0 Beta 1.
Let us know how well it works for you and what we still can improve, both the backend and the UI code we have now (hey, even I understand the latter!) are a much better base to build those developments upon than the old xpfe code we had been using so far - you might even be able to work on it yourself!

I wrote before that I was working on the new download manager UI for SeaMonkey 2. To lift off some work from Justin's shoulders, who fights with flaky (and sometimes just-down) internet connections as well as time constraints due to multiple jobs and a very young son next to volunteering for our project, I decided to also do the redesign of the per-download progress dialogs that we still want to and will support with SeaMonkey 2.


Using those dialogs instead of the download manager window is not the default, and I've never used them since the suite had the download manager UI, but here's how such a dialog looks on SeaMonkey 1.x (on my Linux machine, this is from a German L10n build):



This UI had a few problems from my POV: The target and source locations grow out of the visible area, there's a lot of white space wasted, many buttons that you need to parse to know what they're doing, and it generally feels a bit old-style to me (not to talk about the code, that really calls for throwing away and rewriting). Because of that, I decided to rewrite the whole UI, based on what toolkit's download manager is showing for its entries, only taking what information should be available from the old implementation but redoing everything else. Yesterday, I basically finished my implementation and while I'm holding back on attaching the code to the bug report for the moment to make it base on a hopefully-soon-appearing new backend patch from Justin, I requested UI-review based on screen shots.

This is how the new dialog looks while pausing or downloading a file:


The dropdowns you see on the local file name and the download host come up on either left or right click on those labels in the dialog, and the download can be controlled with the pause/play/cancel icons near the left browser of the dialog. Yes, it's not a copy of the old UI in new code, it's a complete rewrite of the functionality, trying to make the dialog cleaner and easier to understand. What do you think?

And for those of you who only think "Eww! Download progress dialogs are soo backwards, only really old software uses such a thing!" you can be assured that the default mode of operation for SeaMonkey 2 will be to show the download manager window instead (a hidden pref will probably even allow you to switch to the toolkit implementation), which will look like this:

As I mentioned before, I started working on the SeaMonkey UI for the toolkit download manager backend.

In the last few days, I have progressed a lot on that, as one can easily see from the pushlog on the hg repository I created for backing up that work (and having the code out there if someone wants to test).

Here's a current screenshot of my work:



All the commands in the context menu are being activated and deactivated as they should and they are also all working as they should (that is, in SeaMonkey they probably are, opening the home page fails in Minefield, as SeaMonkey's utilityOverlay functions apparently can't open Firefox tabs). Also, the download progress is updated as it should, in the tree as well as the download manager window title.
What's not working yet is the toolbar commands (i.e. search and clear list) as well as sorting. Those are convenient and will of course be implemented before this can go into SeaMonkey (well, we haven't even switched the backend itself yet), but even without those, the download manager is already pretty usable.

If you want to test, just pull the repository, move/copy/symlink the dlmgrui@kairo.at directory in your Firefox profile's extensions/ directory and make sure the symlinks in its communicator/ subdir point to the right SeaMonkey files (or place copies of comm.jar, classic.jar and en-US.jar there).
Having done that, you should be able to launch your Shiretoko or Minefield copy and get this tree-based SeaMonkey download manager whenever the toolkit download manager should else be launched.

Of course, this is an add-on I'm only doing for development of the new SeaMonkey UI, I have no intention of making this a real Firefox add-on but to merge it into SeaMonkey code in the future - once we have the toolkit backend and this isn't WIP but a reviewed patch instead.

It sounds strange, but today I worked on a Firefox (or actually Minefield) extension because I wanted to write SeaMonkey-specific code!

As SeaMonkey 2 will be switching to the toolkit download manager backend but wants to keep its own, much different, UI for the download manager, there needs to be quite some work done. Justin Wood ("Callek") has been doing a large part of that, making SeaMonkey able to build with the toolkit download manager, and trying to get the option for having progress dialogs instead of the manager window working with that new backend.

One thing Callek left out for now is getting a tree-based download manager UI for the new backend though, as he (just like me) doesn't have too much experience with custom tree views. After working on places history, I got a first piece of insight into that area though, and so I figured I could at least try how far I could get with such a download manager window.

The problem I had though is that SeaMonkey still has the xpfe backend, and my code needs to work with the new toolkit one. After thinking about this for a while, I realized that it should be possible to just write some code to replace the Firefox download manager with what we want and move it "back" to SeaMonkey once we have the patches for the new backend.

This is what I could get in a few hours of work:



Using nsIDownloadManagerUI, this completely replaces the toolkit download manager even though it's an in-profile extension. Note that it shows grippies as I just symlinked comm.jar etc. from SeaMonkey into my extension and made it define the "communicator" chrome package - I'm not targeting Firefox but SeaMonkey in the end.

The screen shot probably also looks better than reality, the current state doesn't show all info correctly yet or update active downloads, or even do fancy stuff like sorting, searching or managing the downloads yet.

What it does is loads a basic list of downloads at the time the dialog is opened, and show some raw info about it in the cells, without nice formatting.

It's a somewhat interesting way to work on (to-be) SeaMonkey-specific code as a Firefox extension, but I hope it'll help to achieve getting the UI and backend we want in a similar timeframe for SeaMonkey 2.