Hardcoded Software articles (python)

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 18:00:00 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 and 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')

Getting Started with Python GUI Applications

Tue, 23 Nov 2010 18:00:00 GMT

A recurrent question to Python developers is "Which GUI toolkit is the best? How do I get started?". The answer to this question is subjective, so we end up with a pretty long list of toolkits to try. But then, it's only a matter of playing with demos, picking the best toolkit and then creating our application by basing ourselves on demo code, right?

There are several problems with this approach. First, demo code is usually contained within a demo showcase framework and is hardly an application by itself. The poor newbie often has no idea how to properly structure his application from scratch. Second, comparing toolkits side by side is not so easy to do when demos differ from one toolkit to another.

Moreover, some GUI application designs are no so easy to start from scratch. I've been talking about cross-toolkit design as well as embedded PyObjC lately and these methods are hard to adopt unless you have a simple example in front of you.

This is why I'm publishing guiskel, a collection of GUI layer skeletons. It's a simple cross-toolkit application that does "Hello [name]!". To create a new application, all you have to do is to copy the project and remove toolkit layers you don't want.

For now, it supports only two GUI layers (those I use myself), namely PyQt and embedded PyObjC, but I hope others will participate and add additional toolkits. More

New py2app fork: pluginbuilder

Mon, 21 Feb 2011 18:00:00 GMT

Python 3.2 brought with it a couple of changes that broke py2app. It had been a while since I wanted to work on that project, but because the main command is distutils-based, I lacked the motivation to properly learn how its code works. I saw Python 3.2's breakage as a good opportunity to get my feet wet, since as far as I can tell, there's very few of us using the "plugin" feature of py2app, and I'm pretty sure to be alone to, additionally, use Python 3. Nobody was going to fix it except me.

py2app being a distutils-based command brings needless complexity to the code. Unless you know how distutils commands work, you don't really know what's the main entry point or where options are stored. Because (1) fixing py2app involved code changes that I wasn't sure were backward compatible, (2) I'm one of a very few users of the "plugin" feature, and (3) distutils was increasingly getting on my nerves, I said "screw that, I'm tearing that package apart", and that's what I did. It felt rather good :)

What's different? Apart from not supporting application building like py2app does and not being based on distutils' command, there's a few things that are different in pluginbuilder.

Invocation is simpler. Instead of having to go through distutils' setup() to build your plugin, you can call build_plugin() directly or use the pluginbuilder command line script.
The "main" binary file is compiled on your machine rather than being prebuilt. py2app ships with prebuilt binaries for all possible architectures combinations, but it never worked on my machine so I had to rebuild them anyway. A benefit from this is that it simplifies the code in "main.m" because dynamic symbol bindings aren't necessary anymore and Python.h can be included directly.
Collected source files aren't zipped. That's actually a drawback, but it was part of the fix for Python 3.2's breakage, which didn't like encodings-related modules to be in a zip file. I'm not sure yet, but I think that feature could come back if I use the newly introduced Py_SetPath function.

Roadmap: For the first release of pluginbuilder, I didn't modify a lot of code. I merely, step by step, refactored the thing until I could get rid of distutils' command. The code is not as clean as it should be and I'll probably slowly start to actually change the code. I'm also contemplating the removal of modulegraph's dependency (I think the additional complexity brought by this mechanism is not worth the convenience of not having to manually specify dependencies), but that's something I haven't thought through yet.

That's all I have to say about this. Here's some links:

Embedding Python in Objective-C: Part 2

Fri, 20 Jan 2012 09:57:28 GMT

Two years ago, I wrote about how I embedded Python in Objective-C through PyObjC. It worked well and everything was fine. The only problem I had with PyObjC was that I felt that such a massive library (pyobjc-core has over 5,000 Python SLOC and over 55,000 Objective-C SLOC, not counting tests) was overkill for what I used of it. The whole library was a black box to me and that made me a bit uneasy.

Then, a few weeks ago, I started getting report of weird crashes which seemed related to 64-bit and the presence on the system of some 3rd party app with specific settings. I could never reproduce the damn crashes on my computer, but they came around exactly at the same moment as dupeGuru 3.3.0 which updated PyObjC to fix another 64-bit related crash, so I could only assume that PyObjC (and/or libffi, which is used by PyObjC) was the cause. The problem was that I didn't know where to start the bug hunt because of my inability to work within PyObjC's codebase.

So, out of curiosity for its feasability and to know if it was going to fix my crashes, I started working on ObjP. Instead of dynamically dispatching function call between Python and Objective-C, I would generate source code for static wrappers which would simply use Python's C API. Early tests were encouraging because it fixed the crashes on my users' machines, so I continued working on it and a few days ago I completed dupeGuru's conversion from PyObjC to ObjP and published dupeGuru 3.3.2. So far I haven't heard from crashes, so I guess it works well. More