Adrianer's corner

After more than 7 years (with a half year break for Mountain View, CA), I finally had to say "goodbye" to Wuerzburg and leave for another city: Dresden. Each time when I think about both cities at the same time, my first thought is: spring 1945 - both cities were badly damaged by the bombings (more than 90% damage). That's what I knew. So I thought, Dresden would look exactly as bad as Wuerzburg: the cheapest possible buildings build in the late forties and fifties, and just a few churches and other buildings build up again like they were before... And I was wrong, partly.

Two mistakes in my thinking were:

• at least the southern part of Dresden (were the bombing started) wasn't damaged as badly as I thought: after some walking in the Suedvorstadt and Plauen, I see around 30-40% of the houses to pre-date 1945. In the words of a historian I met here: "there, where you can see a "modern" house or just an empty space, there were houses staying before 1945. All the houses pre-dating 1945 are still here, just because they were lucky enough to not see any bomb falling on them". To compare it with Wuerzburg: I know of less than 10 houses that were still staying after the March, 16th 1945 bombing...
• in the Old Town (Altstadt) the damage was at least as badly as in Wuerzburg, but now, after 1989 not only the churches and bigger buildings were restored: they are restoring the centre of the Old Town to look exactly like before 1945! I was completely stunned, when I saw e.g. the buildings left of the Frauenkirche as that buildings just weren't there a few years ago!: Yes, this buildings were rebuild from scratch too look exactly (from the outside) like the buildings that were there before 1945. The story of the rebuild can be read here (in German). Just a 200-300 meters to the west of that buildings, another ones are being rebuild: . It's the exact opposite of Wuerzburg, where more ugly buildings were build in the last few years...

Now I just have to find some time to take my own "semi-professional" pictures of Dresden.

BTW. I still know not really much about the history of Dresden, so I hope I've got it right here...

Once again I was reminded, that proprietary file formats are not only evil, but are real trouble for the user at the end. Here is the story:

After finishing secondary school seven years ago, I started a movie project using all the pictures and video material we have gathered in school. As the software I have chosen "Pinnacle Studio 8", because my uncle was using it at that time too. I should have listened to him, when he was telling me, that "this is the worst software I have ever seen", because he was right. It took me nearly two years and an upgrade to "Studio 9" to be able to finish the project - the software was simply so buggy, that it was impossible to encode a one hour movie without bugs (e.g. missing transition effects, reversed transition effects) or crashes.

But finally - about five years ago my free time project was ready, burned to DVDs, and I was happy that I don't have to use Pinnacle's software anymore

2005 I wasn't thinking about HD videos (and my PC would be even too slow to allow me to watch them, not even considering encoding HD videos). But now I'd like to have that movie in HD.

I still have all the project files, so it would be really nice to just: choose a good video editing software, open the project and export it to 1080p. Unfortunately, that's not possible, because Pinnacle stores the project in a proprietary format. So the only choice I have, is to rely on "Pinnacle Studio 14", which can export my movie project to HD.

In theory, "Studio 14" can open projects saved by "Studio 9" or newer, but I remember my experience upgrading "Studio 8" to "Studio 9" - it took me several days to remove all the glitches it created in the project... I don't have so much time for it now - I just want to have it working and be ready with it in one single day.

To come to a conclusion: my hopes are, that:

• maybe someone reading this knows a converter for Pinnacle Studio projects to use them with other software?
• if the above will not work... The I'll have to give "Studio 14" a try, but that is my least favorite option - I read too many comments about that version saying "as buggy as the previous versions" :/

At least I've learned my lesson: never, absolutely never store anything in a proprietary format - even if you think you won't need to use it in the future - you never really know. And you never know what (and if any) software will support that format in the future. Stay on the safe side - stay open.

Wasn't the whole ballot thing about preserving the users choice? Then wtf is this:

Procedure to reproduce:

1. choose to install your prefered browser, but not IE (actually, my prefered browser, SeaMonkey, is not in the list, even when it is the 6th most popular desktop browser in Europe... That's a big fail too.)
2. close the ballot screen by clicking on "Choose later (Später auswählen)", because you couldn't find a "Close" button
3. install the downloaded browser and set it as default
4. restart your system
5. see the ballot screen asking you to set IE as the default browser

Is it just me, or does this look like a violation of what Microsoft has signed in Brussels?

After reading Mike Connor's blog post about in fact forcing extension authors to use JetPack and theme authors Personas, I'm horrified: That's killing of what have made Mozilla and Firefox so successful - extending the application in *ANY* possible way. That includes extensions implementing features *no one was thinking of before*.

I have learned the downsides of writing XUL and JS based extensions. JetPack may help authors of smaller extensions, but bigger ones require, and will always require, more. So please: let every extension author decide if he wants to use JetPack or the current way of writing extensions. Don't replace the "old way" entirely by JetPack!

Projekt SeaMonkey, stojący pod patronatem Mozilli, ma zaszczyt zaprezentować wydanie następnej generacji swojego kompletnie unowocześnionego pakietu aplikacji internetowych: SeaMonkey 2.0. Pakiet łączy idee stojące za Netscape Communicatorem z nowoczesną platformą Firefoksa 3.5 w celu stworzenia jednego z najciekawszych produktów open source dla zaawansowanych użytkowników.

Kombinacja przeglądarki internetowej, klienta poczty i grup dyskusyjnych, edytora HTML, klienta sieci IRC oraz sieciowych narzędzi programistycznych, używana przez szeroką rzeszę użytkowników, została przebudowana na bazie nowoczesnej platformy Mozilli, zawierając m.in. najnowocześniejszy system zarządzania dodatkami. Dodane zostało wsparcie kanałów RSS i Atom (wraz z czytnikiem tych kanałów w kliencie poczty), nowoczesny wygląd, przywracanie kart i okien przeglądarki po niepoprawnym zamknięciu bądź restarcie przeglądarki, karty w kliencie poczty, automatyczne aktualizacje programu i dodatków, inteligentne przeszukiwanie historii z poziomu paska adresów, szybszy JavaScript, wsparcie HTML5 (np. wideo i pobieranie czcionek) jak i wsparcie dla kalendarza "Lightning" (oficjalne wydanie beta, ze wsparciem instalacji w SeaMonkey 2.0, zostanie wydane w najbliższych tygodniach).

W "Informacjach o wydaniu" została załączona dokładniejsza lista usprawnień oraz znanych problemów w tym wydaniu, jak i wymagania systemowe oraz instrukcje. Więcej informacji o SeaMonkey 2.0 jak i o Projekcie SeaMonkey można znaleźć na seamonkey.pl oraz seamonkey-project.org!

Po kilkuletniej pracy grupy ochotników wokół nieoficjalnego lidera projektu SeaMonkey, Roberta Kaisera, dzieli nas już wyłącznie kilka dni od premiery finalnego wydania SeaMonkey 2.0!

Kto nie chce czekać, i już teraz chciałby zobaczyć prawie-gotową wersję, ten może wypróbować drugą wersję kandydującą do wersji finalnej (RC2):

• SeaMonkey 2.0 RC2 PL dla Windows
• SeaMonkey 2.0 RC2 PL dla GNU/Linux
• SeaMonkey 2.0 RC2 PL dla Mac OS X

Po kilkuletniej pracy grupy ochotników wokół nieoficjalnego lidera projektu SeaMonkey, Roberta Kaisera, dzieli nas już wyłącznie kilka bądź kilkanaście dni od premiery finalnego wydania SeaMonkey 2.0!

Kto nie chce czekać i już teraz chciałby zobaczyć prawie-gotową wersję, ten może wypróbować pierwszą wersję kandydującą do wersji finalnej (RC1):

• SeaMonkey 2.0 RC1 PL dla Windows
• SeaMonkey 2.0 RC1 PL dla GNU/Linux
• SeaMonkey 2.0 RC1 PL dla Mac OS X

Z pewnym opoznieniem, ale lepiej niz wcale: Pakiet SeaMonkey w wersji 2.0 Beta 2 zostal wydany! Jezeli nie chcecie czekac na ukazanie sie finalnej wersji 2.0 (za 3-4 tygodnie), to zobaczcie to wydanie.

• dla Windows
• dla Linux
• dla Mac OS X

Tomorrow at 10 am we will present the Koala - Komodo Advanced Localization Addon - project. If you are in Prague at the MozCamp, you'll will have a great opportunity to learn more about it.

Florian S. and I are already there, so if you have some feedback or questions - don't hesitate to talk with us.

It has been a while since we announced the Koala - Komodo Advanced Localization Assistant - Project. While we work on the project on a nearly daily basis, we are just three students that need to do other work (like preparing for the upcoming examinations...), and because of that, the progress isn't as fast as it could be, if Koala would be our only project, but: we have a target for the final release: August, 23rd - September, 15th - and we plan not to miss it.

Our project schedule is of course more detailed - it consists of four big stages: preparation, implementation, integration and stabilization. That's the process of software development we did learn at our university, and our goal is to develop Koala that way.

During the first project stage, preparation, we've investigated as much as possible how Koala should work and look like, and as a result, we have written the Software Requirements Specification and Software Architecture documents.

In the Software Requirements Specification, we've listed the must-have features and have split them into modules with similar or dependent functionalities. In the now ongoing implementation stage, we are working on that modules separately. What does this mean? We code e.g. the "compare-locales" access module, make a few tests to be able to test it if it works as expected - and leave it there. So it's a single module, not (yet) connected with other modules.
As a result of this software development model, it's not possible to have something you "could touch" now - there won't be anything really usable until the next phase of development.

During the integration stage, we will make an working extension out of the many standalone modules. We will connect the modules through the, in the preparation stage specified, API's, one by one. It may look easier than it'll be, because this stage never comes as expected.
That will be also the time where we will start releasing pre-release versions of Koala: alpha and beta releases. They are to be expected late July.

After getting rid of the biggest blockers, we will enter the stabilization phase, where we will just fix known bugs and look for yet undiscovered bugs, by: testing, testing and testing. Because of that, in the middle of August you can expect an release candidate (hopefully just one).

The final release target is August, 23rd with a margin up to September, 15th.

If you'd like to help us in any way with this project, please drop a line in the comments.

Short update: between writing this posting and publishing it, we already entered the integration stage - but because of our examination session, the integration will start at full speed not earlier than in about three weeks.