Blowfish requires the input size (in bytes) to be in multiples of 8. So QBlowfish optionally adds PKCS5 padding to the input data to make its size a multiple of 8. (For example, if the input is only 60 bytes long, 4 bytes will be padded to bring the bytecount to a multiple of 8.) When padding is enabled during decryption, QBlowfish will also remove the padded bytes from the output.

QBlowfish is meant to be compiled with your code – you just drop in 3 files into your project. Then you can do stuff like:

QBlowfish blowfishObj("Some secret key");
blowfishObj.setPaddingEnabled(true);
QByteArray clearText("Some stuff to encrypt");
QByteArray encryptedBa = blowfishObj.encrypted(clearText);
QByteArray decryptedBa = blowfishObj.decrypted(encryptedBa);

You can get the code from github here.

Back in July 2011, I had just started using Evernote on my iPad, and I really liked the service. But I missed having access to those notes on my Nokia phone. The Evernote discussion forum had quite a few requests for a Symbian client, but Evernote had made it clear that they had no plans to make one.

Given that background, it’s no surprise that I started thinking about writing an Evernote client for Symbian myself. Here’s my thought process on deciding whether to go ahead and do it or not:

Genuine need: Like me, I could see that many others wanted an app like this, and they were expressing their need in blogs, forums and comments.

Market size: There are significant number of phones running Symbian^3 today. Given that Notekeeper is Qt-based, I could have picked Symbian^3 or N9 as the first release platform. Symbian^3 won purely on market size.¹ The number of people who buy Symbian^3 phones is on a steep decline, but Notekeeper targets those who already have these phones, not those who’re going to buy them.

Niche problem: The addressable market might not be as big. The prevalent perception is that the subset of Nokia phone owners who would want to pay for an app is much smaller. So, an app that solves one niche problem well is a good fit for iOS, but might not be a good idea on Symbian. Can accessing Evernote (or, to generalize, accessing a cloud-based note-taking service) in Symbian be considered a niche problem? Maybe. Maybe not.

Pricing: On a somewhat related note, even if the app solves a problem people have, and solves it well, there might be a reluctance to pay a premium price (like in the case of PaperMill for Android). Of course, there have also been instances where a quality app has sold well: Gravity.
Given these, I thought the risks were well worth taking and went ahead with creating Notekeeper.

Future: Symbian isn’t quite dead yet, but it’s days are numbered.² Qt5 won’t support Symbian, as was known long back,³ but it has no business doing that – major Qt releases are for the long term (Qt4 was released in 2005, and will be in use for a few more years to come), and there’s no need for Symbian support when Nokia’s strategy is to move out of Symbian. That said, there’s a lot happening with the immediate future of Symbian in mind: Qt 4.8 already runs on Symbian, and a good amount of Symbian-specific work⁴ has gone into Qt 4.8.1, released last week.

So, given that the future is not with Symbian, we won’t be writing Symbian apps a few years from now. But right now, it doesn’t look like it’s such a bad idea.

1. 16.8 million Symbian^3 devices sold in Q3 2011 alone, given that the “Smart devices” mentioned here couldn’t have included the N9, which started shipping only in the last week of that quarter. The number of N9s shipped has not been made public, but my guess is that it’s far less than the number of Symbian^3 devices sold.
2. Updates and support for Symbian will continue “atleast upto” 2016.
3. “The initial thinking is that Qt 5 will focus on a small set of operating systems/platforms (i.e. platforms Wayland and X11 on Linux, Mac and Windows)” – Qt Blog, May 2011
4. Changes in Qt 4.8.1

Notekeeper is a Qt app I have developed that acts as an Evernote client for Symbian Anna / Belle devices. Key features are:

• Notes can be created / edited even without an internet connection; changes will be pushed to Evernote during the next sync
• Supports notebooks, tags
• Lets you search for a note
• Can access rich text notes (but these notes are not freely editable)
• Can see images in notes (but cannot add / remove images, for now²)
• Supports favourite notes and offline notebooks

Notekeeper: Start screen, Plain text note and Rich text note

I’m currently testing and bugfixing the app. I hope to get it published in the Nokia Store in about a week or so as a paid app. I’m also considering making a trial version for people to try before buying.

The app uses a Qt/C++ backend to talk to the Evernote Cloud API, and wraps it all up with a UI designed with QML and Qt Quick Components. Many thanks to Evernote for offering a complete, well-designed and free API to access their service, which makes it possible to create an app like this.

Update Apr 7, 2012: Notekeeper has launched. Trial version is undergoing QA.

1. Not counting WRT widgets like this and this
2. Adding / removing images is planned for the next release

I couldn’t attend the event in San Francisco because I had to attend to some personal matters. Johannes and Donald covered for me there on very short notice (thanks guys!). For that matter, I have been mostly ‘offline’ for the last 2 months or so and will continue to be offline for atleast end of this month. So, if you sent me mail, I will get back at some point

Let’s call the computer with wifi connected to the router as I (as in connected to Internet). Let’s call the other computer C.

1. Connect I and C using normal ethernet cable. You don’t really need a cross-over cable since most ethernet cards these days are smart enough to do automatic cross-over.

2. Select a IP range for the ethernet connection between I and C. I chose 192.168.10.x.

3. On computer I, set the ip : sudo ip addr add 192.168.10.1/24 dev eth0

4. On computer I, Enable ip forwarding and setup iptables to masquerate (nat) the wifi connection.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE


5. On Computer I, install and configure dnsmasq. dnsmasq is a dhcp and dns server. The only configuration I needed after installing dnsmasq was adding a line “dhcp-range=192.168.10.100,192.168.10.150,12h” in /etc/dnsmasq.conf. That line specifes the ip range for dhcp leased addresses and the validity time. dns support is enabled by default, so nothing to configure there.

6. Run dnsmasq. Just “sudo dnsmasq”. I actually used “dnsmasq –no-daemon” which lets me the see the debug output on the console.

That’s it. Computer C should not get an IP address and be able to access the internet. You can use ‘dhclient eth0′ or ‘dhcpcd eth0′ to get an IP address through DHCP.

Am really looking forward to interesting conversations about Qt5, Qt Quick and the Qt project

Here’s the solution: Compile Qt with -system-sqlite.

The problem: Qt uses it’s own sqlite3 headers under src/3rdparty by default which are completely out of date. Qt 4.7 has sqlite3 header from 2009-10-14 version 3.6.18. Almost 2 years old and current sqlite version is 3.7.7! That’s like using Qt 4.5.3 in 2011 FTS3/4 table queries fail consistently when using Qt’s own headers.

I have opened QTBUG-21040.

In WebKit lingo, “WebCore” is the thing that takes of parsing/layouting/rendering of various css/svg/html documents, providing DOM bindings etc. “JavaScriptCore” implements JavaScript support and is also referred to as SFX (Squirrel fish Extreme). JavaScriptCore can be used as a stand alone JavaScript engine and has no dependencies on WebCore. WebCore uses JavaScriptCore to support JavaScript in web pages. WebCore also contains support for NPAPI plugins (like flash). “WebKit” uses the WebCore to build a platform/toolkit specific API. For example, the Qt “WebKit” port provides QWebElement which exposes the WebCore’s DOM. By definition, WebKit is platform/toolkit/port specific. The Qt port is simply called QtWebKit.

The QtWebKit port is released periodically independent of Qt releases. These ports have the number QtWebKit 2.0, QtWebKit 2.1, QtWebKit 2.2 etc. QtWebKit 2.0 is identical to what was shipped with Qt 4.7.0. QtWebKit 2.1, intended to be mobile friendly, is not part of any shipping Qt release. QtWebKit 2.2, which will be shipped as part of the upcoming Qt 4.8.0, is yet to be released.

Now for WebKit2. The first and most important thing you should know about WebKit2 (even before you know what WebKit2 is) is that WebKit2 is NEITHER AN UPGRADE NOR A NEWER RELEASE of WebKit. It is a parallel port that can happily co-exist with “WebKit”. Let me reiterate: Stop trying to think of WebKit2 as WebKit version 2 Think of it as a completely different API from existing WebKit.

WebKit is the traditional in-process renderer. If you create 100 web pages, they all reside in one process. If one page causes a crash, it brings everything down. WebKit2 provides a system and an API to make it possible to render a page in a separate process. The process management is taken care of by WebKit2. The actual rendering of the page happens using WebCore. WebKit2, therefore, spawns out processes, renders pages in these processes and makes the end result available to the application. It provides mechanisms deliver events from the application to the rendering process. The Qt port of WebKit2 is simply called QtWebKit2. QtWebKit2 is what is used in the N9 browser.

White-space has never been more important. QtWebKit 2.x is a completely different beast from QtWebKit2. QtWebKit 2.x is plain old QtWebKit releases. QtWebKit2 is Qt’s port of WebKit2. This unfortunate naming is a result of Apple announcing WebKit2 shortly after the Qt guys deciding to call their releases QtWebKit 2.x.

WebKit2 and Chromium are similar in their goal. Chromium does not use WebKit2 and probably never will. The Chromium code was intended for the chromium browser specifically. The WebKit2 code was designed upfront to be an API. This difference in motivation resulted in different implementations. See this page for more details.

Because of the multi-process nature of QtWebKit2, many APIs that existed in QtWebKit simply don’t exist anymore. WebKit2 design lends itself to an asynchronous API compared to WebKit where most API was synchronous. For example, DOM introspection of web pages using QWebElement is not possible since the web page’s DOM resides in another process.

QtWebKit2 has a hard dependency on Qt5 and is very much a moving target like Qt5. QtWebKit will probably not work well with Qt5, we have to wait and see.

Current status: Nokia’s Qt WebKit team has decided to focus on QtWebKit2. They have decided to pass on maintainership of QtWebKit to someone else. At the time of writing, there is no publicly announced appointed maintainer to QtWebKit.

Update: Mentioned about QtWebKit 2.x releases based on Jocelyn’s comment.

At the Qt Contributors Summit, Johannes‘ showed me his Qt/Caca Lighthouse plugin. Caca is a graphics library to output text instead of pixels. So this plugin lets you run Qt programs on the console

His code needed some love, so I forked it and cleaned it up. Caca does not provide a event fd and so we have to keep polling caca for events. Since this wasn’t ideal, I moved the event handling to a separate thread and blocked for events. Unfortunately, I found that the caca library is not thread-safe and rendering and processing events in separate threads makes caca crash at randomly. So, I ended up moving the rendering to the event processing thread and having to resurrect the 20ms event timer again The cool thing though is that now Qt renders to QImage in the main ui thread and hands it off to caca. Caca opens a X connection (or similar), converts the image into text, displays a window and handles events in another thread. With some refactoring and thanks to QMetaObject::invokeMethod, the threaded and non-threaded rendering are pretty much the same and can be switched using an environment variable (THREADED_CACA=1).

Animated tiles:

If you want to hack further, code is on gitorious. (Caca doesn’t seem to deliver gpm events with ncurses, so that would be a nice fix to have)

Update: Welcome slashdot readers