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.

ejpi includes some custom icons as well as using theme icons.

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.

I guess chock this up as another thing to abstract away when running on various platforms.

I'm not saying this was hard or anything but just another lessons learned in porting to Qt.

I just saw a good post on this from the Google Testing Bog.

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?

This is a general problem whether it be long standing technology flamewars (VI is better btw), to religion, or to politics.  Sometimes the very nature of having two groups forms an automatic antagonism (see also George Washington's Farewell address).

I find Krister Stendahl's rules for religious understanding to be very applicable to all of these areas of our life:

1. When you are trying to understand another religion, you should ask the adherents of that religion and not its enemies.
2. Don't compare your best to their worst.
3. Leave room for "holy envy."

Sometimes it seems like the horse is already dead but today I came across a fun article describing Erlang's concurrency model.  This is no surprise because Actors (along with STM) seems to be a favorite on the various programming sites.

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.

Previous and Future ejpi UI

"e**(j * pi) + 1 = 0" is the more complete name of this project.  Throwing the "j" in their might be confusing but blame that on my engineering background.  Why yes, I love that fact that Python follows the EE notation over the Mathematical notation.

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.

Lately I've been reflecting on my commitment to Maemo.  Olivier's blog post made some great points in both directions.

So let's see how the two versions of Gonvert compare:

Qt Version

• Feature parity with the GTK version
• 5 Windows (Two ways of unit conversion, quick jump, and recent)
  
• 1985 LOCs
• From May 26 to June 15th
  

GTK Version

• 1 Window
• 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.

Starting from scratch made it a bit easier to redo the architecture and pieces of the UI.