Hold it, breathe, reflect and plan

I'm not happy with qvdial. It doesn't "just work". Its UI is barely usable. The phone integration is horrible.
The debugging is barely functional, the artwork is non-existent, there is no branding, the icons are worse than amateurish, users need to do so much to submit an error report...
It's patchwork on patchwork and it does not scale at all.

Time for a rework.
But first some links to help with the new design:
Extended panic codes on Symbian.
Offline storage API for QML.

Harmattan build

qgvdial is slowly being made into a full fledged Harmattan application. However, porting to Harmattan wasn't as simple as setting up the build environment and recompiling (even though it's almost all Qt).
Just compile and run *did* work on the n950, but it wasn't a great experience:
1. The main window refused to rotate and was stuck in landscape mode.
2. Any edit box used to pop up the Software Input Panel and that never disappeared.
3. The phone's Dbus services for phone control could not be accessed.
4. qgvdial could not publish it's own Dbus service

Besides all this, compiling qgvdial in Qt SDK consistently fails with a gcc segfault!!

The Nokia help files are here

To summarize, here's all that I had to do to set up a working build system:
1. Create an Ubuntu 32 bit server virtual machine.
2. Download the python install script from the Nokia Harmattan developer website into the server vm. I did this with

wget http://harmattan-dev.nokia.com/unstable/beta/harmattan-sdk-setup.py

3. chmod +x the script, then sudo run it.
4. Log out of the server, then log in again. This step is necessary for scratchbox changes to be made available to your login.
5. /scratchbox/login and you're off!

Now to the changes needed to make it work fairly well on the n950:
1. Rotation: All Harmattan apps must be housed within a Page in a PageStack. I eventually figured this out after reading this thread. Since I want to keep qgvdial as cross platform as possible, I had to make the Main.qml an Item in a Page that was pushed into the pageStack.
Note that "pageStack" is the name of the variant that holds all the Pages in a PageStack. It is not the id of the PageStack.
2. Software input panel: I've not gotten through this completely, but it's possible to trap keys and for keys like "Enter", call TextInput::closeSoftwareInputPanel()
3. Read up on "Aegis": the security framework used by Harmattan.

QtQuick 1.1 on n900

Fought a lot with making QtQuick work everywhere today.
I am too tired to explain, so I'm just going to post links and hope it makes sense.

Thread that has the announcement for the port of QtMobility 1.1 to n900.
This link explain in greater detail how to install to your development systems.

Symbian s^3 and Qt rock

I've finally got qgvdial working on Symbian to the point where it might actually be a candidate to send out on to Ovi.
I've tested qgvdial only on the Nokia C7, but from what I understand, that should mean that it works on all Symbian s^3 phones.

If you're the sort who likes to live on the bleeding edge, then head on over to the downloads list and look for the one that says "Symbian s^3. Testing only".

This sis file may not last out there for as long as you'd hope. I keep updating it as I add bug fixes. It comes and goes as I do this. It will break stuff.
You have been warned.

Symbian^3 and the Ovi store.

I've fought long and hard at figuring out how to make my app work on Symbian. Any Symbian.
It was just recently that I found out about the entire signing side of creating Symbian apps - thanks in part to the new Nokia SDK that has inbuilt Symbian build, sign, deploy and debug.

As I started reading more and more of this entire process, I got to learn about Symbian "target capabilities". These keys influence what your Symbian app can or cannot do.
For example, NetworkServices is necessary to be able to do *any* network communication - either you doing sockets or QtWebkit doing any sockets.

But that's not all. What the documentation does not state and what I found out after loooooong long hours of wasting my time searching Google, was that the following combination "Self sign + capability=NetworkServices + QtWebkit classes" can provide me with only http browsing.
If I want to do *any* https / secure sockets / ssl communication, then the sis file MUST have a valid signature. It cannot be self-signed.

So now what? How do I go about getting it signed?
The price for a signing certificate is about $250 / year. That may be affordable, however, Verisign (or any other trusted authority) will not provide a certificate unless they are able to validate the existence and the legitimacy of *your company*.
Which mean I need to have a company (?!?) Yikes.

..... or I can go the easy route and sign up with the Ovi store, which signs sis files that are published to the Ovi store for free.

Guess how I'll be signing qgvdial and where they will be? :D

C Linking is so much simpler

To make mosquitto support work in Windows, I rebuilt the mosquitto source to get mosquittopp.dll
All fine thus far, but then actually using it became a massive pain. The name mangling just didn't match up even though I was using the same compiler.
I gave up and started using the base C api and created my cpp wrapper around it based on the mosquittopp source.

Now it works for Linux, Windows, Maemo.
Time to start hacking at it on Symbian.

Mosquitto-es!

qgvdial does it's best to not update anything unless the user explicitly asks.
But then there is the issue of timely updates about new messages and calls - missed, received or otherwise. Google doesn't have a push api for this.
Why don't I just poll for it? Because polling means waking up every few seconds, opening a socket, sending a request, getting the data, parsing it, and then more times than not, figuring out that there is nothing new. This absolutely kills the battery life on the phone.
What I needed was a robust push mechanism.

This is where a qgvdial user - xur17 - suggested Mosquitto - a publish/subscribe message broker.
I've ported Mosquitto to Maemo and Diablo and added functionality to qgvdial to subscribe to a mosquitto topic to get inbox and contacts updates.
So now, qgvdial gets updates by just waiting (select) on a socket. No polling involved on the qgvdial side. All the heavy lifting and polling done on the publisher side, which resides in a place where there isn't any constraint on battery life or CPU consumption.

The publisher is a bunch of python scripts that continuously poll for changes in the GV inbox. On any changes, it publishes the change to the mosquitto server on the predefined topic.
This publisher can run on anything that has python. So any regular desktop OS would do. But I had another constraint: I wanted to energy footprint of the device to be as low as possible. What low power device do I have that I can afford to run continuously? I have 2: My DD-WRT router and the n810.
Right now, I've only run the scripts on the n810 and it turns out that this works pretty well to give me all the updates I wanted.
Pretty soon I'll attempt to make it all run even on the router so that I can really truly have only one device that is "always on", doesn't burn a lot of energy and still is a powerful enough machine to do everything I want.

Minor modifications and new build: 0.2.387

-> By user request: Inbox selector is saved and retrieved.
-> Inbox entries are now on two lines and slightly smaller font. Big enough to click, small enough to fit.
-> Tab order in settings page - not applicable to Maemo5, but oh so useful on desktop builds.
-> Windows setup is now an MSI.
-> About page has a link to the changelog.

Stop timing out Mr Hurricane!

timing out before the web page loads is a drag. Especially if we're on a slow connection. qgvdial 0.2.385 is the beginning of what will be a real fix to this. Right now all I have introduced is a way for the caller to change timeouts and set the timeout for the initial login to 60 seconds.
Later releases will try larger timeouts starting from 45 seconds.

That's what I was thinking about when I realized, this is not a browser. I should leave these sort of settings to the user - accessible from "Advanced Settings".

Until I get to that, get your fix from the download list.

Starbucks effect

Starbucks uses a captive portal for its free wifi.
This means that the wifi device gets an IP address, and data transfer does happen, but it is not what qgvdial wants.
The symptom is that when qgvdial attempts to make phone calls (or send texts or listen to voicemail), it fails to get the data in a timely manner.

0.2.383 released today is the result of about 2 hours of Starbucks wifi and sugary drinks. Hopefully it takes care of the Starbucks effect as reasonably as possible.

Frosty piss

Excuse the childish subject but this is the first post in this blog, and I wanted to legitimately use this meme.

This blog is to follow the exploits of me as I continue to enhance and improve qgvdial - the Google Voice Dialer written in Qt.
The awesomeness of Qt allows qgvdial to be compiled and run on a variety of platforms.
The ones that I have managed to make it work on so far are Windows, Linux, Maemo5 and Mac OSX.
The Symbian one should have worked straight out of the box, but doesn't - I'll work on that as soon as I make qgvdial stable on the platforms that it's being used on the most: Maemo5, Linux and Windows.
Next on the agenda will be Meego.

There will be a WebOS port and hopefully soon enough an Android port as well.
At least at this point, the WebOS port seems to be easier and sooner than the Android port.
Didja notice how I excluded iOS out of this so far? You did? How astute of ya!
I'm not going there until I finish everything up to Android.
Hopefully by then the iOS port of Qt will be done and I won't have to be distracted by a lack of Qt there.
Windows Phone 7: Do not want. Cannot develop. No Qt = No go.

So in order of stuff to work on:
* Stability on Windows, Linux and Maemo5
* Symbian port
* Meego development
* WebOS
* Android
* iOS

This should keep me busy for the next few years.