Hardcoded Software articles

Going Open Source

Wed, 05 Aug 2009 18:00:00 GMT

Free Software and proprietary software are seldom seen as compatible. Free Software proponents are telling us that users should have the "freedom to run, copy, distribute, study, change and improve the software", and proprietary software developers are arguing that it's very hard to earn money from producing Free Software. Both sides have good arguments, but a consensus can never seem to be reached.

Recently, the author of E Text Editor, Alexander Stigsen, has made a very bold move by opening the source of his proprietary software. Although I'm not convinced by the Trust Metric system he proposes, I think it is a very interesting move, a move that could potentially, finally, reconcile shareware and open source. More

Using QTreeView with QAbstractItemModel

Sat, 26 Sep 2009 18:00:00 GMT

For someone coming from the Cocoa world, understanding how QTreeView and QAbstractItemModel work can be quite hard. While the concept of an item model for a tree view also exists in Cocoa, the way QAbstractItemModel works is quite different from NSOutlineDatasource's.

The biggest difference between the two models is in the way they refer to cells. In Cocoa, we use an arbitrary identifier supplied by the model through outlineView:child:ofItem:. Then, this identifier is used in combination with a NSTableColumn instance for calls like outlineView:objectValueForTableColumn:byItem: (which is supposed to return what must be displayed for a particular cell). On the Qt side, we use a QModelIndex instance that is supplied by the index(row, column, parent) method. The strange thing with QModelIndex is that it not only holds an identifier, but it also holds a row and a column. Therefore, if index(1, 2, parentId) is called on the model, what must be returned is a QModelIndex(1, 2, childId) instance.

To a Qt newbie, this requirement for the model to return redundant data (row and column) might seem stupid. They might even think that it's downright insane when they discover that subclassing QAbstractItemModel also requires you to implement a parent(index) method. After all, the view knew what was the parent of that index when it asked for it in index(row, column, parent)! The poor Qt newbie might spend quite some time wondering what the heck was TrollTech thinking when they designed this API.

It turns out that there's a reason for this strange and complex API: TrollTech over-engineered this part of the toolkit. They wanted to design their item model so that it would be possible for a single model instance to have table views and tree views connected to it at the same time. While I'm sure that there are cases where this feature is very useful, there's a lot of QTreeView users out there who have no need for it and are suffering because of this over-engineering. More

Cross-Toolkit Software

Sun, 20 Dec 2009 18:00:00 GMT

Developing cross-platform software is easy: use cross-platform libraries, and you're set! When GUIs are involved, however, things get a little trickier. Different platforms tend to have different ways of doing things, GUI-wise. There are libraries that attempt to abstract away these differences to allow developers to build "write once, deploy everywhere" GUI-enabled applications (Qt, wxWidgets, GTK+, etc.), but they always seem to fall short when it comes to the "nativeness" of the look and feel, especially for Mac OS X. To have a cross-platform GUI-enabled application that looks and feels native on all platforms, one obvious solution is to have a cross-toolkit design.

By "cross-toolkit", I mean an application that uses more than one toolkit for the different platforms it supports. For example, my own applications use two toolkits: Cocoa (through PyObjC) under Mac OS X, and Qt (through PyQt) under Windows.

But going cross-toolkit, although it gives your software nativeness, brings its own share of problems. When you create a cross-toolkit software, you have to decide what code belongs to the core, and what code belongs to the toolkit-specific code. If you put too much code in the core, you end up re-writing your own little toolkit wrapper. Then, you realize you abstracted away too much when a platform's specificity forces you to either hack around your core design or rethink that design. If you don't give your core enough responsibilities, you end up with logic duplication among your different toolkit-specific codebases.

In this article, I'm going to take a look at three softwares: A single-toolkit-cross-platform software (OpenOffice), a cross-toolkit software with logic duplication in it (Transmission), and then my own attempt a creating a great cross-toolkit software (moneyGuru). More

How To Customize QTableView's Editing Behavior

Mon, 28 Dec 2009 18:00:00 GMT

QTableView's default editing behavior seems to have been designed with spreadsheet-like usage in mind. When your table needs a more "row-based" editing with some columns being read-only, it becomes rather difficult to customize QTableView to support that. I recently needed to do it for moneyGuru and this article explains how I did it. More

Building 64-bit PyObjC Applications With Py2app

Tue, 19 Jan 2010 18:00:00 GMT

64-bit is upon us and has been for a while now. With Mac OS X Snow Leopard putting so much emphasis on 64-bit applications, you don't want to be left behind with your py2app built applications, don't you? Well, it turns out you're not entirely out of luck! It requires a bit of tweaking, but building 64-bit Python based applications with py2app is possible. More

Embedded PyObjC

Mon, 08 Feb 2010 18:00:00 GMT

When people think of a PyObjC application, they usually think of a Python application that uses Objective-C libraries. However, it's also possible to do the opposite: An Objective-C application that embeds Python code through a plugin. Building an application this way has advantages (speed, integration and memory usage) and should be used more often. This article explains why and how to achieve this. More

High Level Testing

Wed, 03 Mar 2010 18:00:00 GMT

Too often, developers new to unit testing see them as a liability. They're hard to write, and when you want to deeply refactor your code (for example, when you want to re-organize your classes' respective responsibilities), you have to change your unit tests. This then discourages you to refactor your code, making you less agile. These developers will probably abandon unit testing and write on their blog that TDD sucks (because it's common knowledge that unit testing is good, so you can't say that it sucks. It's easier to attack TDD, aka. too many unit tests).

You know what? They're right. I think we do way too much unit testing when we should be doing integration testing instead. If you have a class that is all neat and cute and unit tested and that a new requirement in your application requires you to split that class in two (to do it correctly), you either have to change all your tests, or you implement a kludge that allows you to keep your former architecture (don't do that).

What I've been doing for about 2 years (for moneyGuru's development, to be precise) is what I call high level testing, which is like integration testing, but without (or very little) unit testing. It has some downsides, but it's been working great so far and has empowered me with nearly unlimited refactoring potential on the whole project. I'm under the impression that a lot of developers have a narrow view of unit testing, which prevents them from even considering this possibility. I hope, with this article, to broaden their horizon a little bit. More

Send Files To Trash On All Platforms

Mon, 03 May 2010 11:56:53 GMT

If you've ever needed to send files to trash in your cross-platform application, you've probably noticed the painful void in your toolkit. It's just not there. You can copy, move, delete files, but you can't send them to the trash. There's no easy solution (until now) and you need to implement platform-specific code for Mac OS X, Windows and Linux.

On Mac OS X, you have to call FSMoveObjectToTrashSync (or its async friend) from CoreServices. But then, either you have to make a C extension for it or you have to call it through PyObjC. If your app is a Qt based app, you might dislike having to add such a big dependency just for a little FSMoveObjectToTrashSync call.

On Windows, a SHFileOperation (in fact, SHFileOperationW if you're not stuck in the last unicode-less decade) is needed. Again, if you're not comfortable with C (or you don't want to touch the win32 API with a ten foot pole), you need a dependency on pywin32 (and Tim Golden's winshell if you want to make your life even easier).

On Linux, it's free-for-all (pun intended... in hindsight). There's no unified API to send files to the trash. The convention seems to be that sending stuff in ~/.Trash is good enough, but then there's always the problem of external volumes (you don't want to copy files from external volumes on your main hard disk when you send them to the trash!) and systems with alternate trash conventions (Ubuntu makes further organization of the files inside the .Trash folder).

In other words, it's a mess. You thought you could code your cute Qt app once an run it everywhere, but that damn trash thing gets in your way. Well, if you use Python, you're in luck because there's a library for that now! Say hello to send2trash. It's a cross-platform library that sends files to trash using native API calls (without external dependencies).

>>> from send2trash import send2trash
>>> send2trash('some_file')