The roads I take...

Finally, there is a website up where I can post the wallpaper (and possibly other) designs I made with SeaMonkey imagery!

You may remember my earlier "Knock, Knock, Alpha." post with the Matrix-inspired wallpapers and the recent Mandelbrot app post with that SeaMonkey logo coming out of the Mandelbrot set. Now you can get all those in full quality, comment on them, vote for them and whatnot.



Where? On MCC - the Mozilla Creative Collective!

Thanks to everyone at Mozilla who made that site possible!

This week, I found some more time to hack around on my fun project to do a Mandelbrot set fractal renderer in XULRunner - some of that fun hackery done on the N810, some on my desktop, finally some on my laptop, and now those sources create a really usable application.
The only thing holding me back from doing a downloadable "(pre)release" package of any kind is that it's still somewhat hard to do that for XUL/JS-only XULRunner apps. I'd need to compile my own XULRunner and package it with that or such to get a usable downloadable thing.



What I added this week to bring it over the top was a zoom function that works by dragging the mouse over any piece of a rendered image and a possibility to bookmark locations and call them up again at a later point. With that, one can easily navigate to different places and get pictures like the one above - my laptop calculated and rendered the original 1280x1024 picture in a matter of seconds, with a 1.9.1 XULRunner from some time this weekend, so the same TraceMonkey present in Firefox 3.5.2 to calculate all those iterations, and I did save the contents of the canvas used to paint it as a PNG with the functionality I have in the application. Any quality degradation comes from scaling and converting to JPEG on my web server.

Oh, and there's one more interesting picture I did get out of this work:


(larger sizes linked, original 1280x1024 desktop-wallpaper-ready version available on personal request)

All the fractal pixels in this image come from TraceMonkey's calculation again, of course, but the GIMP helped slightly to finish off this one.

I have been writing about the APNG hassles surrounding the SeaMonkey throbber a few weeks ago already. This Tuesday, I fixed the bug about this by checking in newly created APNGs (16px and 32px sizes) into the SeaMonkey trunk tree, and current nightlies should contain it. Those animations are not the ideal solutions and were quite hard to do, though, and I was faced with multiple problems while doing them.

First, I couldn't just use the frames of the animated GIFs we had as they are 256 colors (which would probably still be acceptable by itself) with 1-bit transparency (which was the actual problem I needed to solve in the beginning) and we needed (8-bit) alpha transparency, which is non-trivial to generate from those GIF image frames. The GIFs are coalesced animations though, with each frame only containing the pixels that need to change compared to the frame before, which is an elegant space saver. Still, we couldn't use those, so I needed another image source.

That brought me back to the original work of the author who created both our SeaMonkey logo and the "bubble" throbber we are using - in an SWF format (yes, the one used by Flash). Now that format is not known for being open or easy to edit. He provided us with the GIF version and also gave us an SWF showing the original animation in some SeaMonkey window mockups. So I took that original SWF and tried to get some tool that would allow us the extract that animation and convert it into some format that would allow me to convert frames to PNG and assemble them into APNGs.

So I looked for tools to do that. SWFExtract from the SWF Tools collection sounded promising by its name, so I tried it. It didn't lead me very far, as it only extracts elements from the SWF into SWF format again (except for bitmap images, but I learned we're dealing with vector drawings here), but at least I now had both a non-animated SWF of the SeaMonkey logo only and an SWF movie of the bubble throbber animation only.

Again, I looked for tools, this time looking closer for something that might make it possible to get vector data out of an SWF, ideally in SVG format. After some searching and some unsuccessful tests of other tools, I found the command line version of and swf2svg tool called Flash Exploit that would run on my Linux machine and be able to extract single frames of SVG data when specifying the sequence number of the frame. I had an SVG of the original vector data of our logo in no time - if we'd only have had that from the beginning, CTho (Chris Thomas) wouldn't have needed to redraw it in SVG. In case of the animation, I found out it was completely vectorized as well, and frame 50 was the same as frame 20, i.e. it was building up to that point and then looping those other 30 frames (the GIF had 30 frames as well, so that looked reasonable). I exported all 50 different frames into SVGs, so that I hopefully will never need to extract stuff from the SWF again. So far, so good.

Now, I tried to take a look at the SVGs. They all looked fine and high-quality in Gecko and Konqueror but Inkscape had a problem displaying the bubbles. GIMP could render them nicely as well, which should help with creating PNGs, but I found out that there was a white background in all the frames, and when I rendered them in a size that would make the logo roughly 32x32px, I needed to use 512x512px as import setting. A look at the source (yay for open formats!) of the SVG provided me with the info to remove the background rectangle and reduce the reported size of the frames from 512 to 32, which I both did in mass-edits for all frames using MySQL's replace utility.

Now I could render an SVG to a bitmap in GIMP and save it as a PNG, but repeating that at least 30 times for the 32px version and again as many times for the 16px version didn't sound like something I'd like to do, a manual process is tedious and with the additional cropping to get the ideal image format it would also be somewhat error-prone. So I looked into batch-processing with the GIMP and found a tutorial on doing it with their language called Script-Fu, which is based on Scheme. It took some fiddling with an unknown language but I could get a script up that goes through all SVGs, loads them into GIMP in a specified size, crop them to the correct target size and save them as PNG images. This way, I could generate all frames I needed - and more: I actually did 128px, 64px, 32px and 16px versions of all 50 frames.

So, then for the assembling. APNG Edit sounded like a good choice, but I realized that I could only adjust delays between frames for single frames there, and I needed to decrease from the default 250ms to 100ms on all frames, so I also tried Animat, which can do that more easily. I edited the XPIs of both to let the install.rdf accept SeaMonkey (I know I could use extensions.checkCompatibility=false for that, but I wanted it cleaner) and also edited their overlays to make the caller menuitem available in SeaMonkey's menus as well (I'd be happy to contribute those changes back tot he original authors if they want to). With that, I could generate APNGs for all the four sizes I mentioned before.

Due to the animations not being coalesced, the images are quite large, the 128px version takes up ~530KB and the 64px one ~210KB, so I won't publish them right now, the 32px and 16px images are in nightlies now and look like that (the exact same images are shown on different CSS-set background colors):

(You need an APNG-capable browser to view the animations, of course, else you just get a plain logo image.)

The animations are not completely perfect, as I said in the beginning - they consist of full frames, no coalescing (though I'm unsure how it would work with alpha transparency), and the bubbles are cut off hard at the edge of the image rect. I have the SVGs and the GIMP script, maybe I'll improve on them some time again, but I think they are pretty usable and much better than the GIFs even in their current state.

Wake up, Alpha.

The SeaMonkey has you...

Follow the frozen tree.

Knock, knock, Alpha.



Whoever can read this matrix code should realize by now:
Yes, we're knocking at the door of our first Alpha. It's been dozing along in our repositories long enough - the real story of its life is about to begin. The code is supposed to freeze for SeaMonkey 2 Alpha 1 on Tuesday - after that line we will only accept changes to SeaMonkey code that are either blocking the Alpha (pref panels!) or have explicit approval.

We will release the actual Alpha 1 as soon as all the blockers are fixed and we get a QA run to confirm it's ready for testing by a greater community than nightly testers. It will still be a testing-only preview of what SeaMonkey 2 has to offer, but it will be a very huge step compared to the current stable 1.1.x series.

Additionally, I think we should set up a collection of SeaMonkey-themed desktop wallpapers and SeaMonkey-themed web button images somewhere, I'd need good ideas of where to do that.



For now, I can only provide low-quality images of those two I have designed for my personal fun, but if we have a good place to put up such thing, I have the first one as a 1024x768 PNG, the second one in sizes up to 1600x1200 as PNGs.

Last week was packed with a huge mount of non-work activity for me, but here's a short summary of SeaMonkey/Mozilla-related work I've managed to do in week 49/2007 (December 3 - 9):

• SeaMonkey Statistics:
  This week, I came around to do updated blog posts about SeaMonkey download statistics and www.seamonkey.at browser statistics. Both give interesting looks into numbers about our user base and I think it was good to share a current state of those.
• Window Icons:
  The long-standing bug on window icons matching the SeaMonkey artwork has now been fixed for Windows, Linux and OS/2 on trunk. You may remember that I posted requirements for those in August and a proposed set from spinello in September. Now, I added those proposed icons, some of which have been revised due to comments since, into our codebase, including the SVGs they were created from. There's probably still room for improvements, but those icons now are surely more fitting for a modern SeaMonkey suite than the previous Netscape4/Mozilla-style ones.
• Even More Artwork:
  For toolbar customization, we need alpha-transparent navigation icons in the Modern theme. I took this as a good case for training my GIMP skills and looking at the new 2.4 version of that open source graphics tool and created such a set.
  For completing the in-code URL changes for the new website (posted in last week's status update), I also updated the splash screens for branch builds.
  And then, I also created a proposal for a new background image to add for Mac disk image improvements.
• SeaMonkey Project Structure:
  Was once again too busy to drive this forward this week, will pick it up again soon. (yes, I know, c&p from last week )
• Source L10n:
  I created a patch for always checking out all files for a locale when building localized builds for it, so that optional localization can work. I hope this gets reviews so finally CVS-based ChatZilla langpacks can be done.
  Additionally, I added one more language for trunk L10n (Swedish). I'm looking forward to add even more in the future.
• German L10n:
  Trunk core was kept in sync with en-US, so that FF 3 Beta 2 can also be released in our language.
• Various Discussions:
  Leaks, customizable toolbars, feed discovery and support, mozilla.org projects list, Firefox freezes, release tags, popup blocking notification, SeaMonkey blog, etc.

Justing Wood ("Callek") has put in some work to get the SeaMonkey team blog up and running again, where we'll inform about releases (including candidates), project-wide status and other official news (while this blog here always represents my personal opinion). The blog is syndicated on Planet Mozilla as well as mozillaZine feedHouse and will be linked from the SeaMonkey website soon. Thanks to Justin for this effort!

A few weeks ago I requested new SeaMonkey window icons, and I'm glad that someone found the time to really work on those and came up with really good proposals. With spinello, we have an experience icon designer on board, who already did some quite nice work for different Mozilla-related projects over at Add-Ons Mirror.

And here's the current state of the proposed new icons:


There's also a image of all available sizes along with the respective window names, see also the forum thread on Add-Ons Mirror.

It's still a bit undecided which of the two variants we'll take for the error ("JS") console, and there might be a few smaller changes still until they go into the tree and will be our official set for SeaMonkey 2, but we quite like those icons for the most part. If you have any comments or feedback on the icons, please direct them to the "Icons for SeaMonkey windows needed" thread on the SeaMonkey development newsgroup.

Thanks to spinello for the great work on that very noticeable improvement we'll have in place for SeaMonkey 2!

While the SeaMonkey project itself has proven itself as a mature community that can do quite well, and we even get better and better with our migration to the "new toolkit", some code parts lag a bit behind, like those targeted by my bug bounty program. But there are also other areas that need help, one of which is artwork.

There's a long-standing open bug report around on one area where we badly would need someone to help us out: we need new icons for all our application windows.

This might sound like an easy task, but there's quite some rules to follow, which makes this hard work - and we need a bit over a dozen different icons!
Those are the requirements we have for those icon designs:

• We need to replace all icons we have that contain "window" in their name, see our Windows icon collection for what those are and their current versions (still those made a long time ago for the Mozilla suite).
• The new icons need to make clear at the first glance that they are SeaMonkey icons, so they should visually refer to the SeaMonkey logo in some way.
• Similar to that, the icons need to be consistent enough to each other in style and basic look, so that a user sees at the first glance that all those windows belong together.
• At the same time, the icons need to be distinct enough that a user does not mistake one of them for another and they need to clearly enough identify the purpose of the window they label.
• The icon designs also need to fit in with the new icons in the reworked default theme of SeaMonkey 2 (trunk nightlies), so a look similar to those new icons is preferred.
• We need all those icons in different size and color depth variations, at least 16x16, 32x32, 48x48 and 128x128 with 24bit RGB and 8bit alpha (i.e. 32bit RGBA) as well as 1-bit-transparent versions with 24bit RGB colors, 256 colors (custom palette) and 16 colors (standard EGA palette), all for the 16x16, 32x32 and 48x48 sizes.
• We need to get all those single images in PNG format, additionally providing a Windows .ico would be nice but is not strictly required. We need to create icon versions that fit for Windows, OS/2, Mac and GTK2, but once we have the raw images to use for those, it's just technical work to produce the correct file formats from them.
• Due to size constraints, it might be a good idea to have minimalized shapes for the 16x16 versions that might look a bit different than the respective bigger icon sizes, just like the current icon set (see above link) has. That current set is a good example for everything we need, actually - just that it still is based on the old Mozilla suite "m" logo and the old "Classic" theme imagery, which both are gone in SeaMonkey 2.
• Last but not least, all the copyrights for all imagery must be assigned to the SeaMonkey Project / Mozilla Foundation (per at least an email from the creator to the Mozilla licensing group and the SeaMonkey Council - Mozilla may additionally require you to send a signed assignment message per paper mail), we'll then set them under the MPL/GPL/LGPL tri-license with committing them to the source code repository.

If those requirements don't intimidate you and you feel you have enough artistic talent and icon design knowledge as well as want to contribute some work to the SeaMonkey project, then please create some preview designs (a selection of icons, including at least browser and mail in 16x16 and 32x32 versions), post them as an image somewhere publicly on the web and inform us in the SeaMonkey development newsgroup/mailing list!
Once we arrive at a design we all like, it'll be time to work on the full set and go to the bug report, but before that, the newsgroup is a better idea.

Oh, and if you need a SVG version of our logo to work on such icon designs, please contact me at kairo-at-kairo-dot-at or on IRC - we're still waiting on getting a trademark policy up before we will publicly put up such a SVG image.

I know the target for such icons is pretty high, but I hope we'll get someone to provide them and vastly improve the look of SeaMonkey 2