The roads I take...
KaiRo's weBlog
| Displaying entries published in September 2010 and tagged with "SeaMonkey". Back to all recent entries |
September 30th, 2010
OpenSearch Support in SeaMonkey
SeaMonkey now supports OpenSearch through toolkit's search service!
We're late into this compared to Firefox, but this is one of the last, maybe even actually the last, item we needed to pick of from "the toolkit". The good thing is that now, all the search plugins that work for Firefox and possibly other browsers also do work for SeaMonkey. The bad news is that the special feature we had, the scraping of search results into the sidebar, is gone now and we don't have a clear idea if it would even be possible to get it back.
Also, we don't have a search bar available yet (it's planned to have it as an optional item through toolbar customization), the sidebar does some of its job for now, but even things like detecting site-specific engines or search suggestions are not available there yet.
The current state is a first step to get this feature in at all for SeaMonkey 2.1 Beta 1, now further steps can be taken to refine and improve it for the second beta and the final release.
By KaiRo, at 19:46 | Tags: Mozilla, OpenSearch, SeaMonkey, SeaMonkey 2.1, sidebar | 9 comments | TrackBack: 0
September 28th, 2010
My Upcoming Trip to the SF Bay Area
I hope to be working next week (October 4th through 8th) from the Mozilla headquarters and having a number of meetings with different people working from there, on a mission to improve communication and cooperation between different parts of Mozilla and the SeaMonkey project.
If you are around in that area or at Mozilla, please contact me via email or on IRC and I hope we can arrange meeting up - after all, talking to people involved with Mozilla is what I'm there for.
Of course, being out of my usual environment, I'll try to have some fun next to the work engagements, and so I already have tickets for a Friday night Country Music concert (Rascal Flatts, Kellie Pickler, and Chris Young) and a Sunday night football game (Eagles @ 49ers) - and I'll probably take most of the second week I'm there to drive around (I have a rental car for the whole stay) and do some sightseeing and relaxation, though I haven't planned details yet.
In any case, I'll spend most of this Friday (Oct 1) at airports and on planes to get there, and most of Oct 17/18 traveling back the same way.
I should be around on and off on IRC the first week of those two, but probably not or very rarely the week after - still I should be back in Vienna with some time left before the core SeaMonkey community will convene here.
Oh, and I hope to get even better photos than on previous trips due to having an (older, but still quite decent) DSLR with me in addition to the good-quality pocket cam I usually took all my pics with.
By KaiRo, at 14:35 | Tags: California, Mozilla, SeaMonkey, SF Bay Area, travel, USA | 1 comment | TrackBack: 0
September 27th, 2010
Weekly Status Report, W38/2010
- Build Machines and System:
After our Windows builds had been broken with yet another problem of us not building libxul, Mark Banner bit the bullet and made SeaMonkey and Thunderbird build on libxul by default and on all our build machines. I then worked on cleaning out old builds and making packaging fit with that change.
Based on that work, I worked on enabling Plugin Crash Detection (Out of process plugins) for SeaMonkey and succeeded. But then, we found out that universal builds were broken due to PPC not enabling that feature, it had build problems, for which I had to do several iterations of patches until it was fixed.
Those switches also came out with linking a debug libxul needing a real lot of RAM, esp. on Linux, and so we needed to request increasing memory on build machines, which was mostly done, but brought up other problems, like the Parallels host not being able to support that much RAM on VMs and one build machine being down now as a result. Due to that, we had hiccups in the whole system, as even the build master runs on that host, and some some Mac minis are missing right now after reboots and we need Mozilla IT to manually tackle them. I hope everything turns out alright in the end, but it's another sign of how fragile our build machine pools are at the moment. I'm working on improvements, though, but need to convince the heads of Mozilla to help us there. - Data Manager:
Ian did his reviews on Data Manager, we filed some more followup bugs, and I fixed up some things in the code, but in the end, this feature that IMHO makes SeaMonkey stand out somewhat could land and is a part of SeaMonkey now! - OpenSearch:
OpenSearch support got reviews from Karsten after I did another iteration of the patch. Now I'm waiting on super-review before being able to land that as well, which I hope can still be done before this week's string freeze for SeaMonkey 2.1b1, so localizers will adapt to this now for the first beta instead of their work getting broken later on. - Personas:
My patch for making sidebar look good with Personas got reviews and could land, so browser windows should look good with lightweight themes in the upcoming beta. - Places:
When I landed places bookmarks, I unintentionally gave us a broken Move Bookmarks dialog. I finally found out what was wrong and fixed that. - German Community:
I added a few more people to Planet Mozilla (de), I hope more will join this in the upcoming times. - Various Discussions:
JavaScript speed and my Mandelbrot demo, SeaMonkey Development Meeting, visit to Bay Area and Mozilla HQ, resolving gcc 4.5 issues, Firefox add-on bar, doorhangers, 2.1b1 freeze and adding another beta, Mozilla web task force and domain name strategy, etc.
A lot of great things are happening right now that should make SeaMonkey 2.1 Beta 1 a really compelling milestone for testing what's upcoming for our next stable release - and that one will be surely be the best application suite we ever delivered, as it should be.
Next week I'll be on a mission to improve cooperation with Mozilla Corporation and visit / work from their headquarters in Mountain View, and I also hope to be able to start creation of our Beta 1 builds from there, which we should still release before most of our major contributor meet face to face here in Vienna.
Interesting times we're living in, indeed!
By KaiRo, at 21:17 | Tags: L10n, Mozilla, SeaMonkey, Status | no comments | TrackBack: 0
September 24th, 2010
Data Manager Now Part of SeaMonkey!
Data Manager
I have reported about the add-on and on the features before, but now this idea I started working on four months ago has made one more step and is included by default in SeaMonkey, starting with manual builds from today as well as tomorrow's nightly builds.
Right now, you find it in the Tools menu or by entering "about:data" in the location bar and it's a pure addition to the other managers of the same data for the moment, until it can do everything those can do and we can remove them. There's a lot of work to do until then and the bug report has a long list of dependencies for those work items - help is appreciated there!
Once again, SeaMonkey 2.1 Beta 1 in early October will be the first version we'll ship to a wider audience for testing this feature.
By KaiRo, at 18:18 | Tags: Data Manager, Mozilla, SeaMonkey, SeaMonkey 2.1 | 1 comment | TrackBack: 0
September 23rd, 2010
Plugin Crash Protection in SeaMonkey!
Since today's nightly builds, this is available in SeaMonkey 2.1 as well. This means that you'll find "plugin-container" processes running when you're using the SeaMonkey browser, those are the processes in which the actual plugins run in. Also, it means that a crash in Flash code will not take down your browser or even mail component of SeaMonkey any more!
We'll make this feature, just like the faster JavaScript and the Data Manager, available for more wide-spread testing in early October in our first beta.
Happy browsing with SeaMonkey 2.1!
By KaiRo, at 23:48 | Tags: Mozilla, SeaMonkey, SeaMonkey 2.1 | 3 comments | TrackBack: 0
September 22nd, 2010
The Speed of JavaScript in SeaMonkey
I ran 3 tests there: my personal Mandelbrot demo 1.0 with default settings (blue), the pretty common SunSpider benchmark (red), and the new Kraken benchmark (yellow). Note that the scale of Kraken results is different to the scale of the other two.
(Update/Note: I was told that my Mandelbrot demo uses JavaScript 1.7 and HTML5 features that Mozilla 1.8 supported but other browsers still don't, so there's a more cross-browser Mandelbrot demo 2.0 now - that one performs even a tad better on Mozilla trunk than the results here.)
The builds I tested were current pre-2.1 trunk builds, which already have the first stage of the new JaegerMonkey JavaScript engine, 2.0 branch builds without and with the venkman JavaScript Debugger add-on enabled (without JSD means that TraceMonkey can fully work, as activating venkman makes JSD put JavaScript into a non-tracing debug mode) - and finally, the 1.1.19 release build.
Unfortunately, I can't get data for Kraken on 1.1.19, as after a very very long time of running (given the "slow JavaScript" warning is deactivated), it errors out with not finding any JSON support. Comparing to the other tests, it suffices to say that SeaMonkey 1.1.x, coming from the Mozilla 1.8 tree, is very slow - but then, that's the baseline we started from.
SeaMonkey 2.0.x - even with venkman on and JSD knocking tracing off - is 90% or more faster than 1.1.x in those tests we can run in the older version. Suffice to say that Mozilla's JS team has made tremendous improvements between the 1.8 and 1.9.1 branches of the platform. One might think it's hard to go even further after such a jump, and indeed it has become much harder - but things could still get better. First, turning the debugger off and tracing on wins 19% in SunSpider, 13% for Mandelbrot and 2% for Kraken (the latter either doesn't have a lot of tight loops, which is what tracing help most with, or we are bad at tracing them in this version). At this level, SeaMonkey 2.0 looks already nice - but that's still 1-2 years old code, and development continued.
The current pre-2.1 builds of SeaMonkey bring another 61% win on Mandelbrot, 66% on SunSpider and 72% on Kraken - over 2.0 with full tracing! While the basic Mandelbrot set image took over 25 seconds to calculate and display on 1.1 and significantly over a second on 2.0, we're under half a second now for pre-2.1 code. And, as I already mentioned, JaegerMonkey work isn't even finished yet, there's a few more things to come there.
Of course, the question is if what those tests run is what Web sites and applications really need - we know a few things in SunSpider are non-realistic workloads. Kraken tries to look into CPU-intense workloads that could be useful for actual web applications, esp. if they want to to things like image and audio processing. My Mandelbrot set demo may look far-fetched, but then, I can surely see websites or even more web games dynamically generating fractal-based shades and textures based on variable parameters, and there you might have very similar code.
For those people who want the hard facts, here's the numbers for my graph with all details:
- Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre SeaMonkey/2.1b1pre
- Mandelbrot: 483.0ms +/- 1.4% (0.481, 0.492, 0.474, 0.487, 0.481)
- SunSpider: 477.4ms +/- 1.1%
- Kraken: 11151.6ms +/- 0.5%
By KaiRo, at 18:10 | Tags: JaegerMonkey, JavaScript, Mandelbrot, Mozilla, SeaMonkey, SunSpider | 4 comments | TrackBack: 0
September 21st, 2010
Köln 2010 - Tag 2
Dort ging's ans Eingemachte - nach Vorträgen und Präsentationen am Vortrag war dies der Tag der Arbeiten und Entscheidungen. Vorerst war mal zu klären, was wir mit der Domain mozilla.de machen wollten, alle waren sich einig, der die aktuelle Weiterleitung auf die deutsche mozilla-europe-Seite nicht ideal ist, sondern eher die Community-Seiten aller Produkte verlinkt werden sollten. Und auch sonst drehte sich alles darum, wie wir wohl die Community in bessere Kooperation bringen könnten. Deshalb wurde auch beschlossen, die Newsgroup mozilla.dev.l10n.de nicht nur bestehen zu lassen, sondern auch wieder mehr zu nutzen. Schließlich erarbeiteten wir in Gruppen und später wieder in der gesamten Runde unsere Top-5 Ziele für die nächsten 6 Monate. Alles in allem eine sehr fruchtbare Diskussion, die das Treffen gut abrundete - ich hoffe, wir können diese Ziele auch erreichen.
Schlussendlich ließen wir die Veranstaltung ausklingen, in dem wir gemeinsam warteten, bis die jeweiligen Transportmittel abfuhren, zuerst in einem Cafe am Domplatz, später an div. anderen Orten rund um den Dom - Rothaut und ich waren so ziemlich die letzte, die Köln wieder verließen, denke ich.
Zurück in Wien war ich zwar kräftig müde, aber konnte auf ein Wochenende zurück blicken, an dem ich viel gelernt habe, von neuen Gesichtern über Accessibility-Technologien bis zu den gemeinsam erarbeiteten Plänen für die deutsche Mozilla-Community. Eine Veranstaltung, die sich wirklich deutlich gelohnt hat!
By KaiRo, at 18:35 | Tags: Köln, L10n, Mozilla, SeaMonkey | no comments | TrackBack: 0
Weekly Status Report, W37/2010
- Releases:
Worked on our first "oilspill" release, which shipped as SeaMonkey 2.0.8 this week to fix a startup crash seen by some people upgrading to the 2.0.7 version.
The turnaround times were pretty good there, collaboration with Firefox and Thunderbird folks worked flawlessly where needed, and our release automation systems showed how well they can work - it took them about 8 hours of wall-clock time from the signal to start builds until builds and updates in all 24 languages had been built and verified for correct application of updates. - Doorhanger notifications:
This is off my plate now, I hope someone else will look into those, but as Neil is rewriting the system and I'm tight on time in the next few weeks, I can't bring myself to wait for him and them rewrite all the patches to fit his ideas. I got other work to do and I have to care about shipping builds, deferring work indefinitely for a large rewrite is nothing I can work with in the last weeks before a feature freeze. - Data Manager:
I started addressing the first review comments from Ian on Data Manager, it looks like we're making good progress there, I'm waiting for his actual code comments as those have been mostly from testing so far. - OpenSearch:
We had a few discussions on OpenSearch support, I think we are coming to terms on how to progress with this, but I need to put a bit more work into it to address comments. - Personas:
As one more step to make them look better, I created a patch for making sidebar look good with Personas, I think the browser window is coming around to looking really decently with those lightweight themes now. - SeaMonkey L10n:
Finnish could be added as a new locale for SeaMonkey 2.0.x, I hope we'll get it to a shippable state in the next updates. - Various Discussions:
SeaMonkey Development Meeting, visit to Bay Area and Mozilla HQ, gcc 4.5 and libffi bugs causing js-ctypes and therefore Sync problems, building with "fatlibxul", JavaScript speed and JaegerMonkey, Firefox add-on bar, etc.
A lot of my time in that week was occupied by planning the SeaMonkey Developer Meeting 2010, our first ever event of this type. Invitations are out now, the hotel is settled, and we are going strong in getting the rest of the event together.
Also, on the weekend, I had the privilege to attend the German Mozilla Community Meetup in Cologne, reports from that are available in German language for both day 1 and day 2 (though the latter one still needs to get finished and published).
By KaiRo, at 14:00 | Tags: L10n, Mozilla, SeaMonkey, Status | no comments | TrackBack: 0
September 18th, 2010
Köln 2010 - Tag 1
Ich hatte das Privileg, unsere "Rothaut" auf dieser Reise zu begleiten, gemeinsam mit Thomas (Lendo) stellten wir Österreicher damit ein Sechstel der anwesenden Mozilla-Community-Mitglieder - ein respektabler Anteil in dieser Gruppe von hauptsächlich Übersetzern und Community-Betreuern der verschiedenen Aspekte des Mozilla-Projektes.
Wir fanden uns am Vormittag in der Lobby des Hotel Cristall wieder, das als Tagungsort fungieren sollte. Nach kleinem Umherirren rund um den riesigen Dom und damit verbundener Nahrungsaufnahme begann dann zurück in diesem Hotel unser eigentliches Erlebnis, wobei nach einigen technischen Wirren ich den Reigen der Vorträge mit SeaMonkey eröffnen durfte, und denke ich deutlich genug machen konnte, wie wichtig der deutsche Sprachraum für unser Projekt ist, und dass SeaMonkey 2.1 jedenfalls am aktuellen Stand ist.
Die Kollegen von den anderen Projekten haben jeweils die Situation ihres Teiles dargestellt, wobei ganz klar wurde, dass es doch gute Möglichkeiten geben müsste, zwischen verschiedenen Teilen enger zu kooperieren, um uns alle zu stärken. Besonders interessant fand ich Rothaut's Präsentation der Accessibility-Technologien - ich hatte schließlich noch nie einen Screen-Reader und eine Braillezeile in Aktion gesehen, und es war echt spannend, einen kleinen Einblick zu bekommen, wie Software und das Internet für jemand aussieht, der/die keinen Bildschirm verwenden kann.
Einige Neuheiten konnte ich sonst auch noch aufschnappen, wie die Existenz von auf deutsch übersetzen MDN-Seiten oder dass die deutsche Firefox-Version 10% der gesamten Benutzer-Anteile ausmacht, aber auch altbekanntes wie die fast zum "Running Gag" advancierende "Ressourcenknappheit".
Mittlerweile sind wir im Zielspurt des heutigen Nachmittags in einer Diskussion der Probleme bei den Mozilla-Übersetzungen, besonders im Bereich von div. Webseiten, angelangt, bevor wir uns zum Einchecken für die Übernachtung und dann zum Abendessen und gemütlichen Tagesausklang begeben.
Der Informationspart heute war sehr ergiebig, und ich hoffe, dass sich das in Einzelgesprächen heute noch fortsetzt - und morgen geht es dann zu den produktiven Diskussionen!
By KaiRo, at 19:11 | Tags: Köln, L10n, Mozilla, SeaMonkey | no comments | TrackBack: 0
September 15th, 2010
Our First "Oilspill"
So, recently, Mozilla land adopted the name "chemspill" for those - needing to clean up after spilling chemicals represent the actual case better for sure.
But then, after recent events, I realized that for maritime life-forms like Sea-Monkeys, it's really more fitting to call it an "oilspill" in our project. Thank goodness, we didn't need that expression for quite some time after I came up with it - until now.
With SeaMonkey 2.0.7, we saw a sudden rise of a previously-rare crash signature in our topcrasher statistics, along with comments from users that it was on launch after updating that this happened, and the affected users were not able to run SeaMonkey at all any more in this version. Now, that's unacceptable, of course, so we stopped issuing updates from 2.0.6 on the release channel and went into investigating the problem.
It turned out that we had both a problem on our side with cleanup after updates as well as a platform problem that affected Firefox and Thunderbird as well, and it looks like both together were even worse for us. We found fixes for both now and decided to take a fix for font face in HTML email signatures along for the ride on creating a fast update that has nothing but those changes in comparison to the 2.0.7 release.
We now have candidate builds of this SeaMonkey 2.0.8 version up for testing and will ship it to the public between today and Friday of this week if everything looks as good as expected with it.
So, after all, we have our first "oilspill" release situation on our hands and I hope we are dealing with it in a satisfactory way. I just wish that real oil spills would be as easy to deal with as those in our software.
By KaiRo, at 16:08 | Tags: chemspill, firedrill, Mozilla, oilspill, release, SeaMonkey, SeaMonkey 2 | 11 comments | TrackBack: 1
September 13th, 2010
Wie schnell wird SeaMonkey 2.1?
Der letzte aus der 1.x-Serie, SeaMonkey 1.1.19, der vor einem Monaten die Wartung dieser Versionen beendete, brauchte auf meiner Maschine 17501ms für diese Tests - das also war unsere Startlinie in Erneuerungen.
Eine aktuelle SeaMonkey 2.0.x-Version kommt auf der gleichen Maschine auf 1738ms mit aktiviertem JavaScript-Debugger (Standardeinstellung) bzw. 1402ms, wenn dieser deaktiviert wird. Dass das Deaktivieren des Debuggers unter 2.0 einen Vorteil bringt, liegt daran, dass dort bei seiner Aktivierung die TraceMonkey-Beschleunigung ausgeschaltet wird - trotzdem ist auch ohne dieser eine gewaltige Verbesserung gegenüber 1.x feststellbar, braucht der Test doch nur mehr 1/10 der vorherigen Zeit.
Aber in der heutigen Welt kann das nicht genug sein, und für weitere Verbesserungen hat SeaMonkey 2.0 bloß eine neue Startlinie gesetzt - die Mozilla-Gemeinde ruht nicht und arbeitet intensiv weiter.
Die heutige SeaMonkey-2.1-Vorversion integriert die neuen Arbeiten an "JaegerMonkey" für noch schnellere JavaScript-Ausführung und landet nun bei 477ms für diesen Test auf meiner Maschine, nochmal auf 1/3 gegenüber 2.0 reduziert!
Dabei muss man bemerken, dass die Arbeiten an JaegerMonkey noch lange nicht fertig sind, einige Dinge können hier noch signifikant verbessert werden, und Mozilla's JavaScript-Engine-Entwickler arbeiten bereits kräftig daran. Ich denke, SeaMonkey bewegt sich (wie Firefox) in die richtige Richtung.
By KaiRo, at 22:19 | Tags: JaegerMonkey, JavaScript, Mozilla, SeaMonkey, SunSpider | no comments | TrackBack: 0
Weekly Status Report, W36/2010
- Releases:
Shipped SeaMonkey 2.0.7 on Tuesday but pulled updates soon after for a startup crash seen by a number of users, which stops them from even launching the application or getting further updates, so we went for rather safe than sorry and stopped updating the other half of users still on 2.0.6 and not yet having applied the update. We will create a 2.0.8 release soon with fixes for the crasher and then will deploy updates straight to that one.
Given that, I worked on fixing one issue related to the crash, but there's a second one pending that affects Firefox and Thunderbird on the same platform version as well. I also readied us to take a mail signature fix along with that update. - Build Machines:
Just when that requirement landed, I got note that we need to install YASM on Windows slaves and upgrade other systems, so I set the time aside to do that, and after some investigation on how Firefox release engineering did that, could complete it successfully on all our machines. IT also once again was very fast and helpful when one slave decided to go missing on the network. Thanks for that! - Automated tests:
I landed the test for reusing empty tabs that I created the week before. Apart from that, I didn't get to look into a lot in that category, but Callek, IanN, Aqualon, and sgautherie have been quite busy there, which is nice to see, as the oranges come down to manageable numbers now. - Places:
After some more reviewing, the fast bookmarking button has been accepted and I could land it. - Doorhanger notifications:
I did another followup patch, this time for lightweight themes installation, but given that Neil seems to have decided to rewrite the system, I'm seriously thinking of throwing the towel on the whole stack of bugs and patches, unless he'll backport all this work to Firefox as well. - UA string:
After doing a Council vote on including a Firefox token by default in our UA string, and that vote running positive, I got reviews and checked this in. - Data Manager:
After addressing Neil's last super-review comments, I uploaded a new version 1.0.2 to AMO with those improvements.
Ian came around with some review comments on Data Manager, but from a first glimpse, either his build has problems or my code does. Need to find out about that. - OpenSearch:
After a number of additional hours spent on it, OpenSearch support has a patch up for review, but it looks like some points of my work are controversial and it will take some time to agree on something there, I fear. I filed a few followup bugs for things this first patch doesn't cover. - Various Discussions:
SeaMonkey Development Meeting, visit to Bay Area and Mozilla HQ, building with libxul and/or "fatlibxul", organizational future for SeaMonkey, more prompts converted to doorhangers, JavaScript speed and JaegerMonkey, message account wizard, Firefox UI work, etc.
We had a few messages recently about JavaScript speed and SeaMonkey, and it's quite fitting to those that the new "JaegerMonkey" method tracing just landed on the developement "trunk" and our nightlies this weekend. Out of personal interest and for calming people who fear we wouldn't work on speed, I did some runs of the popular SunSpider benchmark today. While the SeaMonkey 1.1.19 versions with which we announced the end of the line for the 1.x series comes in at 17501ms in that benchmark on my machine, a current SeaMonkey 2.0.x build comes in at 1738ms with the JS debugger enabled (default) and 1402ms with it disabled, which is a huge improvement - but just the baseline for current work. Now, today's pre-2.1 SeaMonkey build again just takes about a third of that baseline time and lands at 477ms - and the JaegerMonkey work isn't even finished yet. I think we are moving in the right direction.
By KaiRo, at 22:05 | Tags: L10n, Mozilla, SeaMonkey, Status | no comments | TrackBack: 0
September 6th, 2010
Weekly Status Report, W35/2010
- Build Machines:
I fixed the missing L10n nightlies by applying a trick the Firefox build engineers team told me about - all locales that build right now should have nightlies out for all platforms again.
When I noticed that two machines were missing, I filed a bug and IT promptly got them back to work for us - thanks for that! - Automated tests:
While a few other people in our team are churning along to reduce our test failures, I only helped marginally with this effort this week - but when one fix landed and didn't have the wanted effect, I investigated that a bit, wrote a test specifically for the new issue we're seeing and found out what the actual problem there is - we're still discussing a solution.
I did create a patch to only build Web Console for Firefox, which should make our test failures there go away - if it gets accepted. - Places:
I did one more patch for cleaning up the places library, reverting theming for some parts to ease getting it reviewed.
The fast bookmarking button got some more review comments and finally got as far as being OKed for the Classic theme, so I updated it for mac and Modern as well. The star button nit backport got review, I requested approval to land.
The Mac problem of bookmarks being broken when no windows are open is solved after some more teamwork between Stefan and me. - Doorhanger notifications:
While the main patch is still waiting for review, I updated the followup on add-on installation notifications following some more Firefox work. I also filed a bug for "Learn more" on geolocation notifications, but I won't work on it while the rest is still in limbo. - UA string:
I did a patch for the somewhat controversial change of including a Firefox token by default in our UA string, after I realized the fight for this has been lost. There will be a UI pref in the advanced panels, and some don't believe this fight is over and want to prolong needless fighting, but I think this change needs to be done and the discussion ended if we don't want to continue losing users over this. - Data Manager:
From what I can see, the updates to the Data Manager patch and the review comments seem to get very close to final with respect to Neil's super-review. Now all I'm waiting for is the official marking of that and Ian's actual review. - Site-specific zoom:
I updated the patch for remembering zoom per site after I found out how to mitigate errors I had earlier and requested reviews now, but that might just be stalled for using a controversial event right now, which Neil just doesn't like to see at all in our code. - OpenSearch:
One thing that comes up time and again when users try to use it unsuccessfully and ask in our channels is OpenSearch support. This has been stalling for a long time basically just because we now have crufty, badly documented binary code around for search and a sidebar of which we don't know usage but which is crafted around a model that is far away from OpenSearch and not even fitting the current code.
After we have decided some weeks ago that we'll set no priority on the sidebar working, I finally bit the bullet and tried to get our code to work with toolkit's OpenSearch module and so far, it has been easier than I thought - even though we are still missing a few things in my current WIP patch. I also did a very rough WIP for an optional search bar, but that needs a lot more work and isn't as high a priority as the main OpenSearch patch. - Various Discussions:
SeaMonkey Development Meeting, SeaMonkey build machines, visit to Bay Area and Mozilla HQ, building with libxul and/or "fatlibxul", organizational future for SeaMonkey, etc.
Esp. in the first half of this week I've been under a lot of strain, and generally I'm badly overworked and having too many things I think I need to take care of, resulting in symptoms that are very much pointing in the direction of an oncoming burn-out. At the same time, I'm trying to organize or help organize a few things that in the short term cause me some additional stress for planning, but should relief a lot of stress and frustration in the end. I hope that all will help my sanity somewhat (in the mean time - sorry when I might overreact at times) and help the SeaMonkey project to improve significantly in the future.
By KaiRo, at 16:46 | Tags: L10n, Mozilla, SeaMonkey, Status | 3 comments | TrackBack: 0
September 4th, 2010
Bridging Web and Local App(lication)s
Now, as with many other things, I don't think this extreme will be the common case (or else we should stop caring about Windows, Mac OS or any other "fat" operating system and all jump fully on ChromeOS) - but I'm sure that "web apps" will play a very much larger role, and I agree that almost everyone will at least use some of those.
In such a future, where the common case will be to use both web and local applications to some extent, probably also with a mixture of cloud and pocket data, it will matter a lot to have solid and well-thought-out ways of bridging their differences and working well with both - esp. for professional and advanced users, who spend a lot of time "in front of the screen" (whatever that will look like).
Also to keep in mind is that pure web applications in the currently done ways pose a problem for some people - I had an interesting conversation recently with a guy working in development aid for some African regions where he said there are entire communities of people that share a 256 KBit/sec Internet connection and things like Facebook or GMail cause nightmares for him.
That surely doesn't mean they should not exist, but those cases need thought, just like cases where you (intentionally or unintentionally) have no or a very bad network connection but might want to do work with your (mobile) computer (device). Not every place where people go in or around this world will have high-volume Internet access available for everyone all the time. We don't even have light all the time on this world, even though life on this planet heavily depends on it, and we have a transmitter right in our neighborhood (well, in terms of what we need there, 8 light-minutes are right next door).
Still, web applications allow the incredible stunt to have the same software on a free and open platform that runs on all kinds of devices with mostly quite permissive licensing. And they allow getting productive immediately, without long install procedures or continuous updating - as well as unprecedented collaboration and other features only the web can make possible.
On the other hand, they're currently one of the worst examples in cross-application consistency, easy adaptation to the personal look and feel preferences and integration with the people's work environments, leaving any current or past desktop environment looking like a champ in comparison.
To improve those situations, we of course need to have possibilities for web applications to cache code and data locally so they don't need to load everything a new all the time, they need ways to adopt to a common look and feel defined by those accessing them, ways to integrate with the work environments - and a richer toolkit of easy-to-use controls to match desktop applications. All those are being worked on by the teams of Mozilla and other browser vendors in committees working on improving HTML, CSS, ECMAScript and other web technologies as well as in implementations in our web runtimes ("rendering engines" is not the correct term any more, I guess).
What we also need, though, are smooth transitions between desktop and web applications - in both ways - and between local and cloud/remote data, both in terms of the user-facing side and in terms of writing applications. We need local and web applications that can work with local and cloud/remote data, we need technologies to write local application with (basically) the same set of technologies as we're writing web applications, and we need to be able to convert one to the other rather seamlessly.
The Mozilla platform already works very much with the a lot of the same set of technologies as the web, so we are in a good position in this area already, but we need to become even better by making the technologies even more similar (and there's a lot that future HTML can learn from XUL, too, even if XUL is being treated a lot like the ugly stepchild nowadays). A lot of awesome things can be done today, but I'm convinced that's nothing compared to what we'll be able to do tomorrow if we follow those paths we're already on to the most part.
And then, I'm quite convinced that there's a tremendous potential on an application that bridges web browsing, running web applications, and running local application code built around web/Internet communications. All those things should seamlessly integrate, work together, be able to exchange data where the user allows it, and give us the power of being productive, social, communicative, efficient, informed, and interconnected all at once. Right now, there's nothing as productive and efficient than fast, organized local application interfaces, and there's nothing as social and interconnected as some web applications. An integrated Internet application could build a bridge between them, bring that together and beat all the single offers out there, and there's none better situated in that particular race than SeaMonkey. We just need to grab the chance and bring it there.
Who is with me in that?
By KaiRo, at 18:37 | Tags: future, Mozilla, platform, SeaMonkey | 5 comments | TrackBack: 0
September 3rd, 2010
Not For You, But With You
I think that says a lot about our spirit in Mozilla about how we work on our products. Nobody pays us to produce products like Firefox, Thunderbird, or SeaMonkey - even if some of us might earn money for doing it, that comes through indirect paths, and not from those using our products. And we're nothing more than community members, just that we're playing a certain role in the community, but we're still parts of it, and we are just as much users as we might fulfill other positions. On the other hand, every user has a chance to work with us to improve the products - we're open for (constructive) feedback and help. We even give you access to the code, and accept patches very much - with the result that some features we ship in our products get developed completely by people not earning a cent for working on it, but being 100% volunteers. This is how open source / free software should work.
Still, we have a lot of dreams of where we want to go, and our teams are always too small to fulfill all those dreams at once, so that help is not just appreciated but very much needed. As Mike goes on:
Feedback is good and often helpful, but very often things only happen if someone steps up and takes matters into his own hands (a lesson I sometimes think I have learned too well).
We need you to help us to become even better. We need you to work with us, just like we are working with you.
By KaiRo, at 15:48 | Tags: Firefox, Mozilla, SeaMonkey | 5 comments | TrackBack: 0