LOCs are measured by "wc -l" rather than getting fancy. I wrote both apps and they were written in a similar style with similar amounts of whitespace and documentation.

The LOC counts look nice, more drastic than my Gonvert port for what it is worth. I had a lot more distractions going on during my port of ejpi so a comparison of implementation times between Gtk/Qt or Gonvert/ejpi is as meaningless as the title of this post suggests.

My main Qt disappointment in this port is what seems like high coupling both in Qt itself and in code written by others (the example pie menus).

Now for some of the upsides. Though I implemented them differently, the similarity in the drawing code between Qt and Cairo helped. Also finding out about QStandardItemModel made my life easier.

I'm split on which direction I want to go in my learning of Qt. Originally I had planned on porting Dialcentral for gaining experience with threading. I have too many ideas though and not enough time. Possible directions include: porting other apps of mine, a new app using QGraphicsView, or some QtMobility contacts (and eventually calendar) plugins (though then I'd also have to learn the quirks of Qt in C++ and deploying compiled apps to Maemo).

For me, one thing that differentiates the quality of a calculator on a mouse or touch driven device is having a calculation history and having it be interactive. In Gtk I implemented this with a TreeView and a ListStore. I had never implemented a custom model in Gtk, the included models were simple enough and flexible enough that I didn't have the need.

The custom icons are used for a couple of buttons. I know the path to the custom icons and I load them up and everything works as expected.

The stock icons are used for deleting items in the calculator's history as well as a severity indicator and close button for the error info box.

I ported the GTK code from using theme icon names to QIcon.fromTheme. It was fun for me to find out that fromTheme was added in Qt 4.6 (I still support Maemo 4.1 with my applications and it only has Qt 4.2 I think). How did applications do this before 4.6? I don't think I've used KDE since v2 but I think its generally supported icon theming along with everything else which precludes the application building all icons in as resources.

I also had fun with fd.o icon names not being available on all platforms so I had to find alternatives for each and put in fallback code.

Despite my dislike of Apple and their treatment of developers (and my disgust that developers are flocking to receive their flogging) I think we should be careful how we react to this. Problems happen. There is both good and bad to how Apple handled this. If we feel a bit annoyed in how they handled this we should have that same annoyance no matter the source rather than giving in to fanboy-ism

Do we look at this and think how much better our platform is but get annoyed when others point out the problems with our platform of choice?

Because of my off-repeated distaste for making custom widgets unless needed, the pie menus for ejpi are my first real custom widget. Learning to write custom widgets is the reason I chose to port ejpi.

The idea for ejpi was born from reading a complaint on planet.gnome.org about how computer calculators overly mimic handheld calculators much to their detriment. On a computer there are a lot more ways to interact with a program than a device with a one-line display and a fixed set of hardware buttons.

So ejpi is designed as an RPN calculator that has an interactive history. You can delete item and duplicate items. With a one-line calculator it is easy to forget where you are in a multistep calculation, so ejpi shows you not just the result but the equation that got you there.A 4" device (n8x0) is limited on what all you can put on the screen and shrinking it down to 3.5" (n900) makes it even harder. Making matters worse is that even if the device has a qwerty keyboard (n800 doesn't) its not well suited for math. So I chose to experiment with pie-menus as the keyboard. Typical pie-menus behave more like a context menu and have the middle of the pie be cancel. I changed this up a bit to mimic my favorite keyboard for the Palm, MessagEase. The pies are buttons that if you just click will perform the center's operation. If you click-drag the pie will popup and then release in the direction of another symbol for it to perform that operation.

There is a trade-off in how much of the pie's contents the button shows. If you show too much then it is cluttered. If you show too little then the user has to explore every button to know what operations are supported and where.

Sadly on Maemo devices, the performance of the pie menus is not what I would like which makes this more of a toy program. I actually use the HP42 clone more than my own calculator

Unlike when I blogged about Gonvert, I am still working on the ejpi port. I've got all the basic functionality working except switching keyboards. I also plan on adding rotation support, directly editing history, some UI tweaks, and maybe one or two other things that crop up. If the performance of the pies is better I might add an algebraic entry mode to make ejpi more widely appealing.

So far I plan to write about my experience in writing custom widgets for Qt, handling of dynamic layouts, and the various tree models. We'll see what is left by the time I am finished.

1658 LOCs (766 of that is hildonize.py which Gonvert doesn't use all of it)

From October 29th to January 9th

LOCs are measured by "wc -l" rather than getting fancy. I wrote both apps and they were written in a similar style with similar amounts of whitespace and documentation.

So for all of my criticism of Qt this went fairly quickly without a lot of code. I look forward maintaining this code base going forward. It is still hard to compare the numbers because of how meaningless they are. How much should hildonize.py count towards the GTK version? How much of the GTK development time was me learning the code and providing a smooth refactored path through revision history rather than doing a fresh rewrite?

One nice side benefit of not having to modify the actual unit list or the base conversions is that I'm still shipping the GTK version in case someone really doesn't like the new stuff. Now that I'm well beyond feature parity I don't think that is as much of a concern anymore.

I've already started on the next phase of my Qt learning process, porting ejpi. Some outside things have come up which has slowed down my progress. I'll follow up with posts on that later.