Porting Firefox to Qt…?

After reading Zack's blog about the Mozilla port to Qt, I started thinking (warning, this is a very idiotic idea)… lets remember what Zack said: Qt is a toolkit, Mozilla has its own toolkit, Qt has networking library, Mozilla has a networking library, Qt has a JS engine, Mozilla has a JS engine, Qt comes with QtWebKit…


How about writing a XUL engine using Qt4 and WebKit…? and then porting Firefox to the new XUL/Qt engine…? This will give us a Firefox based on WebKit and pure Qt4 instead of the gecko mish-mash that's available upstream for using Qt4 as a widget toolkit.


Sometimes the translation makes the product

I have just recently (2 years ago) finished to read The Lord Of The Rings. It was a huge task (I read the whole 6 books + history + languages + …) specially since I read the English version. So, now I have to move to the next challenge, and it seems the Dune books are a good idea.

Only this time, people suggested I read the Hebrew translation and not the native English version. It seems the pseudo Arabic using in the books (1) gets translated really well from English to Hebrew. And really, the books felt to me like they were written in Hebrew and not translated to Hebrew (even tough the 3rd and 4th books are a mess, as they contain bad translations and printing errors (2)). I assume it felt more natural for me then reading the English version.

This means that the translator did a good job: some of the spelling errors available in the English version were fixed in Hebrew version – and that made the book easier to read, well at least to me (3).

The same happens in computers. Most people in Israel are used to Windows English users interfaces, and when they see a Windows Hebrew users interfaces, they run away – because the UI is made in such an ugly way. One of the examples, is the light source which comes from right-to-bottom instead from left-to-bottom in RTL windows. But hey! You can have LTR and RTL windows in the same desktop, so you will see the light source coming from different locations in different windows! It's even funnier when you try to close a window and the close button is in different locations in different windows, on Hebrew/RTL windows the close button is on the left of the window title! Thankfully KDE3 behaves better, and I am very happy about the way it looks and fells. Now what about KDE4?

This week I sat down and compiled KDE4/trunk for the first time, in hope to improve the Hebrew support in KDE4. I hope to get the translation of KDE 4.2 in good shape to be officially released as an official language (Hebrew is missing in KDE 4.0, and KDE 4.1, for the first time since KDE 1.1.4!). The problem is that many applications are really borked under Qt4 (4), and I am shifted aside to many small tasks. I will blog about them in the next days/weeks, for the other developers to see how can they code more "right-to-left" friendly (5).

So this is a note all to the KDE developers: if you are maintaining an application and got some ugly RTL/BiDi bug report and you don't even understand what the user is complaining about, please send me an email and then assign the bug to me. Please mention module, file, class and if possible lines to fix. My email is "elcuco" (I assume you can guess the rest (6)). Ah… and in case you missed it: my name is Diego and I am one of the KDE developers which is making KDE usable for right-to-left users.


(1) I found real Arabic in the 3rd book, but the 1st and 2nd books did not really contained real Arabic as far as I can tell. But what do I know about Arabic? I only learned it at high school 😉
(2) Local publisher fault, really.
Not the 4th one, all I see is Leto bla-bla-ing about that GoldenPath and other mambo-jambo. Boring! SHUT UP WORM!
(4) Plasma is the worst as the graphics scene layout system does not support setLayoutDirection( Qt::RightToLeft). I talked with el presidente about it a few months ago, and worst case scenario I can write a special layout class for plasma. Hope the Trolls/Nokia/QtSoftware will fix this issue before I do.
(5) Actually KDE folks really kick ass in this area – they are sometimes abusing this issue. More on that in the future.
(6) You can also find me on the IRC, I will let you guess the nick.


Moonlight – fail

As I previously mentioned, Microsoft had a talk in August Penguin 2008. They said that Silverlight is available for free from Microsoft's site. Which is a lie, since the site clearly says you are running a non supported browser/operating system.

Here, look at this page: http://channel9.msdn.com/shows/Continuum/Building-NBCOlympicscom-with-Silverlight/ and click the link to install Silverlight.

So lets install Moonlight from Novell/Mono. Here is the link: http://www.go-mono.com/moonlight/. I tested version 2 on Firefox 2, Mandriva 2008.1, and when playing the video on Channel9 Firefox crashed. Don't worry, version 1 also kills Firefox when I click the play button.

But… but.. even if it did… I went to http://www.nbcolympics.com/ and tried viewing a video (they are telling for months that they will provide the best experience for the Olympics using this technology) and I get an error from the site telling me I am not running Firefox (1.5,2,3) on Windows (2003, Xp, Vista). I can also choose IE and Safari.



QHOCR updates

I am maintaining (writing … ) an application based on libHOCR (an Hebrew OCR library) in Qt4 called QHOCR. The project started as a test for my abilities to port a Linux/GTK only application to Qt4/Windows. The last version I released was based on version 0.8.3 of Kobi's library, and since then he did a lot up upgrades to the library – and now I need to port the application to the new API provided by the new library (stable API/ABI is for sissies).

So, the first thing I did, was compile the command line application using qmake. Now, this application is compiled right now using auto*, and links to GLib, so it was fun. Took 2 hours, but then I got the new (qmake based) binary to run exactly like the original (autohell based) one. Funny thing is that after stripping the new binary was 10k smaller then the old one, so go figure…

One interesting bug I found, is that both the library and the demo/command line application have a file named hocr.c. Now, since I am hacking an application – I don't care about libraries and all this other issues, I just statically link all *.c files into the same EXE. Now, the problem is that you cannot have 2 files with the same name on the same project file (if both files are on different directories). That is because for both files, the target will be .tmp/hocr.o, and only one will be built. The solution is to rename one of the files, in my case the one which contains main(), to qhocr-cli.c.

Another interesting thing I did, is having 2 different *.pro files on the same directory. In theory I should use the subdirs template, but there is no reason why not to abuse this hack meanwhile.

The next stage will be get rid of all GLib/GTK function calls, and use cout(), and QString internally in the command line application to understand the API. Tomorrow I will be focusing on porting the command line parsing from GLib to Qt4 (somehow, don't know how). The last stage will be migrating the GUI application to use the new library with all the experience gained from previous tests done on the command line utility.

The code is available in my trunk, and contains the GUI which links to libhocr-0.8 and the CLI application which links to libhocr0.10 (and glib! and x11!).

PS: yes, qmake can build plain C applications… I have used it once to build a GLUT based application since I am too stupid to learn auto* and CMake was not existing back then.