Linus is always right

Linus is always right: SVN users are stupids, GIT is superior. I am now starting to move my personal projects from SVN to GIT. When doing local development, GIT is by FAR much better then SVN: easier to setup ("git init" and you are done, and SVN?), it's the fast and it's branches are super cool. So, lets use it.

In order to learn how to use GIT, the best way is to use it. So I decided to start helping again in Arora (which is hosted in github). The result is that the next version will have a nice RTL user interface (I must admit, the bridge between JS and C++ in Qt is really cool), and you can also have i18n without installing the application. A nice side effect is that you can have local translations (different then the ones in /usr/local/arora/* in ~/.arora/i18n). This may help translators, to finish the translations of the applicaiton, even if they installed from source. If not in practice, at least in theory as the code is more or less there.

Back when I was studying, I had this class which was called "data mining", in which we learned a few clusterization algorithms (KMeans, PAM and a few others). We were given an exercise: to code a program that implements Clara. I decided to code this in Qt4, using QWT. As an exercise, I decided to clean it up, and save it in a git repository. I just finished uploading the project to github, and I am also planing a few other changes (move the code from the Qt containers to STL). The code is GPL3, so feel free to use and abuse. The dataset code is self containing and soon will have no dependency on Qt, so it may be-reused in other projects.

Since this is the KDE planet, here is the mandatory screen shot:

Stackoverflow and Konqueror

As a huge fan of stackoverflow.com and one that is trying to reduce his usage of Firefox (Konqueror is faster, consumes less memory and looks more native) I had problem browsing to this given site.

When you try and associate the Google account with your stackoverflow account, I was redirected to the front page and I was not recognized. Today, I tried identifying Konqueror as Firefox2 (from Tools/Change Browser Identification) and I was able to login. When I was logged in I removed the false identification and the site is working perfectly. SWEET.

GMail almost works when you identify as Firefox2. The new user interface does not work (you cannot change... directories? folders?) and the chat does not work even with FF2 enabled.
This might work if I identify as a newer Safari... who knows...

This means Google are spoofing for specific browsers and hacking around problems (which do not exactly exist). Anyway, the user agents strings might need a little update... it's like they are stacked in the remote past... when we actually needed to spoof the browser identification ....wait.... what?

A reason to keep KHTML

I have read that people are not happy about KHTML. As one who spoke once against KHTML, and pro QtWebKit (or QWebKit?). This is why I want to keep KHTML:

Native widgets. Not emulated like WebKit/Gecko, but real Qt widgets. This means that I can have a text widget which fully supports BiDi (not gecko, not webkit, only IE has one... and KHTML).

Also, widgets get drawed funky if the direction of the page is opposite to the direction of your desktop on WebKit (you can see it in chrome, Arora and Safari). For example see the combo boxes in http://www.aljazeera.net/Portal.

Still, I think that KHTML is not something we can handle today. Sorry, even tough KHTML is great, WebKit is what the market needs, it's what we as a community need.

QDevelop 0.27 is out

Get it while it's hot! QDevelop 0.27 has been released!

Sources and builds for Linux/Windows are avialable at the GoogleCode project, as always: http://code.google.com/p/qdevelop/downloads/list

Removed Hebrew translations of Plasma 4.2.1

I just removed the Hebrew translation of plasma from the 4.2 branch, which means only plasma will not be translated to Hebrew. The reason, is that QGraphicsScene does not support RTL interfaces in Qt 4.4, and it's still not sure if KDE 4.2 does support Qt 4.5. Even if it does, it's still not tested.

If KDE 4.2 will work with Qt 4.5, the translation will get pulled from trunk again.

I hope that no more files need to be remove, otherwise I am afraid of going bellow 85% and in theory Hebrew will not be a supported language.

Freeze in KDE4.2 - now lets check out the strings

KDE's trunk is now frozen and no new features can be added, nor visual strings can be modified or added, we are in release mode. Lets see some of those strings:

Inactive contrast effect type, taken from colorsettings.ui:830 in kdebase, the string is found somewhere in kcmcolors.pot. I understand this as the non-active contrast of a type of an effect or the type of the effect for the contrast of non-active (something).  This is how it will sound when translating to my language, it might sound ok in English but it does not always sound good enough in other languages. Looking at the spanish translation it seems the second translation is what the original developer meant.... you see? I need to look into another translation to understand the original string. How can a user understand it?

You have a Logitech Mouse connected, and libusb was found at compile time, but it was not possible to access this mouse. This is probably caused by a permissions problem - you should consult the manual on how to fix this. This one comes from kcminput.pot, and my question is: which manual? ... are you sure it will have information about something like "chmod a+rw /dev/usb-mouse-blabla"?

And then are the giziliion-gazillion technology names we use: plasma, akonadi, strigi, phonon, dbus and more. What am I speaking about this? since some languages leave those names in english even though the langauge is not latin based (for example the Hebrew team is doing this) and others do try to translate the latin letters to the alphabet (the Arabic team does this for example). This is fine, until we start talking about "plasmoids"... and then things get funky. I might need to re-think my policy and translating plasmoid to פלסמואיד and also plasma to פלסמה or פלסמא (the latter sounds more Aramic then Hebrew so I might keep the first one). 

Again, why mumbeling about local decitinos? Because when choosing technology names developers do not think about i18n and l10n (1), what happens when the technology name cannot be transcribed into a specific language? I once heard that CocaCola cannot be transcribed exactly to Chinese and when localizing the trade mark CocaCola used the closes sounds they could find to write the name of the product (2).

Don't get me wrong, KDE 4.2 will kick ass, and the next Mandriva distribution will come with it will get in my laptop (3). But still, as a contributor I am not happy about some decitions, and that's OK.  Since I am using Gnome at work (4) and I see the applications on the other side, and I like the ones KDE is shipping/developing.

(1)  lazy... write the full words!
(2)  any chinese reading this? can you confirm this?

kate and Konsole. Just because the kubuntu-desktop is not stable enough.

(3)  yes, I am still using KDE 3.5.something. Stable and usable, I need to do work and not fight my own system.

(4)  Ubuntu 8.10 (64 bit) with kubuntu-desktop installed, running a GNome session with Dolphin. Dolphin kicked mc's ass.

QTextEdit and QTextCursor fun

My problem is simple: when I open lokalize, it's using the RTL interface and I see the original English text in RTL mode. This just looks bad, as it always needs to be LTR. Should be simple, not?

So I started writing some small tests (yes David, I do small scale tests!). In this test I am doing the exact opposite: I am forcing an RTL paragraph on an LTR interface.

First test:

QTextEdit *e1 = new QTextEdit;
QTextOption o;

o = e1->document()->defaultTextOption();
o.setAlignment(Qt::AlignLeft);
o.setTextDirection(Qt::RightToLeft);
e1->document()->setDefaultTextOption(o);
e1->setText( QLatin1String("1) Currect direction on QTextEdit, wanted RTL!") );

This seems to work fine. However, lokalize creates a QTextCursor and inserts text to that cursor. Ok, second test:

QTextEdit *e2 = new QTextEdit;
QTextCursor tc = e2->textCursor();
QTextCharFormat tcf = tc.blockCharFormat();

tcf.setLayoutDirection( Qt::RightToLeft );
tc.insertText( QLatin1String("2) Wrong direction on QTextEdit, wanted RTL!"), tcf );
e2->setTextCursor(tc);

This does not work. The text is still LTR, even tough I modified the text char format of this text cursor. I sent a bug to Nokia with this mini-application, and it's marked there as N229677.

I talked with a fellow hacker here, and he sent me this piece of code (which does work), third test:

QTextEdit *e3 = new QTextEdit;
QTextCursor tc = e3->textCursor();
QTextBlockFormat tbf = tc.blockFormat();

tbf.setLayoutDirection( Qt::RightToLeft );
tc.setBlockFormat(tbf);
tc.insertText( QLatin1String("3) Correct direction on QTextEdit, wanted RTL!") );
e3->setTextCursor(tc);

Now, I don't really understand why the second test does not work. IMHO, the higher level API used in the second test should work, but I assume that using this low level (which is used in the third test) is fine as well... I will commit this to lokalize as soon as I test on a live lokalize, but it's just crashing on startup since 3 days ago (yes, I am using runk). Is this a known issue?