Weekly Status Report, W43/2008

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 43/2008 (October 20 - 26, 2008):

• Build System:
  The newest build system sync landed, removing more lines than it added.
  Some locale Makefile update could land as well, but Axel Hecht landed some rework of the browser file recently, and we should port that as well. And then, localizers complain right now about disagreement of en-US files and the installer string check tool on variable usage.
• Geolocation:
  The geolocation prompt for SeaMonkey could land now that the Firefox bug we found has been fixed as well. With this, geolocation support in SeaMonkey is the same as in Firefox 3.1 - we can plug providers of location info but right now rely on extensions to implement those, and if a website requests geolocation info, we prompt the user if we should hand it exact location, neighborhood or no information at all.
• Helpwanted Items:
  As discussions and bug fixes in other areas went along, I filed a few bugs that basically fall in the helpwanted category, i.e. we're looking for someone to work on them: breakages and followup ports related to jmita's kill-rdf work in Thunderbird, a context menu for the HTML5 <video> element, and a fix for secure favicons (for those who switch on the related pref).
• Mozilla Camp Europe:
  This weekend, a significant part of the European Mozilla community, including myself, met in Barcelona for MozCamp Europe. It was nice to meet some of those people from the community again, and get to know a few folks I haven't met in person before, like Ian Neal or Serge Gautherie.
  In addition to a few quite interesting talks, a huge part the notable things was going on in personal talks between people - for example, I realized that all related people I could talk to have pretty uniform thoughts about how Thunderbird and SeaMonkey should work together regarding sharing, forking and unforking of code, which to the most parts can be summarized as "share all the backend, those dialogs that are as they are because they can't be a much different and the utility functions to access backend functionality (ideally as JS modules); fork the main frontend". We still care about each other's forked frontend code to some degree though, as we like to port parts of it back and forth and apply our own twists on each other's ideas. This is actually quite similar to a lot of the relationship we have with Firefox, with toolkit as the code sharing hub. In the mailnews case, we should just make all that interaction and structure cleaner, including for example the sharing of L10n files for shared code, which is not happening right now.
  This was only one of the quite interesting topics were were able to talk about, and I'm looking forward to having more of those personal talks with people at other similar events.
  Tristan called Mozilla, like that event, being all about "fun, work and friends" - I think I rarely heard a better summary of why our community works so well.
• Various Discussions:
  killing MOZ_XUL_APP, tabmail and Lightning, places history and location bar, etc.

One of the areas I've been thinking about more and more recently and what also came up at MozCamp in Barcelona is the long-term vision for SeaMonkey. This is not about specific features we want, and this is not about SeaMonkey 2 or 3 or so - this is more about the stars shining on the horizon that give us a clear orientation of where we want to be moving to in the long term. That vision is closely related to our target audience, and is built up by high-level goals. For now, we are busy with making SeaMonkey 2 catch up to modern technology and represent where browsers and mail/new clients are supposed to be currently, but after we will have achieved that, we will need to know where to go from there, in what direction our software should develop.
Is conserving historic UI our goal? Is merely throwing copies of Firefox and Thunderbird into the same process our goal? Is tight integration and breaking up borders between browser, mail, chat and maybe even web page creation our goal? Is overloading the UI with options almost nobody uses our goal? Or having everything a power-user regularly uses available as easily and fast as possible? Is a strict structure of predefined UI our goal, or as fully customizable user experience? Is SeaMonkey relevant at all in the long run? Why (not)?
I'd like everyone who considers himself part of the SeaMonkey community to take a few moments in a probably otherwise unused timeframe, let you thoughts circle around this topic a bit, perhaps take notes, and try to figure out where you want SeaMonkey to go in the long term, where you see those visions and why. I'll start a thread on the development newsgroup about this soon, and I'll probably blog about it even more.
It will be interesting to hear your thoughts and figure out where we all will be heading in the future!