Archive for the ‘Uncategorized’ Category

Preface

Two commonly touted aspects of Python are the readability of its code and how quickly it can be used to creating working applications. Among the complaints regarding C++ are legibility of complex applications and difficulty in debugging the same. The flourishing number of programming languages and flight from C++ to scripting and just-in-time compiler-based languages over the past decade (or two) forced developers to take a deep, hard look at the development process. Why is it that a language that can be so obfuscated as C++ remain able to do what others cannot? I won’t go into the reasons, because that’s a holy war on its own. The end result of the rise of Java, Perl, and other web-development languages that followed, along with the failure of so many languages to topple C++ is a deep retrospective among developers and engineers on the design and development process. Concepts like unit and integration testing, rising and falling popular “styles” of development (e.g. Agile, Waterfall, Extreme Programming), and the examples of both successful and failed open-source development models are changing the way software development happens.

Trains Don’t Turn Easily

Anyone who’s worked with undocumented and badly written legacy code will tell you that it’s a terrible, terrible thing. Poorly designed APIs, non-descriptive variable names, and the fear of regressions in mature code (what might be called the “if it’s worked this long, don’t touch it” effect) hound application developers. Once a library or application reaches a certain point in size or development milestones, fear of breakage spells doom for mistakes made early in the development process. If software were mansions, a warped support beam on the first floor is hard to fix when you’re putting up the third floor. Wooden roller coasters are infamous for this problem: a 2-by-4 off by an 1/8″ at the base can become three feet at the apex.

Once It’s Done, It’s Hard to Undo

The larger the application, the more time needs to be spent in the design phase. Unfortunately, until the code is written, compiled, and tested, some things just aren’t obvious. Unit and integration testing certainly help here, particularly if modular programming is properly adhered to. Nevertheless, compiled languages like C++ make revisiting the design phase after development begins is a painful process. An application written entirely in C++ can be written slipshod to get it working or slowly to do it right, but not both. Writing modules in Python first saves time by making mistakes and pitfalls visible early on and quickly repairable. Because Python is designed to be easily readable (assuming one doesn’t use get too clever with some of the core libraries), it can be used as an intermediate stage between design and implementation to get the algorithms right, tweak the APIs, and generally make sure ideas that are time-intensive to implement will work.

It may seem foolish to write a program twice, but that’s not what I’m advocating at all. Python is such a flexible language that it is possible to write code that closely mirrors C++ and can be reused with a little scripting. In the case of Qt and PyQt (or PySide) this is particularly true, as most of Python and C++’s core libraries can be replaced with their QtCore counterparts.

I will be following this relatively short post with a more extensive discussion on writing legible Python code that readily converts to C++ and how to go about doing so.

Qt5 just hit Alpha a few days ago. I have a number of thoughts and concerns about the new edition of Qt. Major releases–like 4.x to 5.x–typically are the time to do major reorganization, feature additions, and API changes. Typically, such a major release is a time to worry less about bug-fixing and incremental improvements and more about merging major projects or revisions that might break things. It’s a time to take risks.

The current project plan for Qt5 concerns me. Some of the new stuff is great, but the planned replacement of the (very flawed) model/view framework doesn’t seem to be surfacing. I’ve been frustrated with the idea of Model-View-Controller being replaced by Model-View since I started working with it, and KDE’s shift to a MVC back-end for KDE 4.8 really brings it home. The MVC Dolphin now uses comes from work QtLabs did quite some time ago as an intended replacement for the current model/view framework. I had hoped that Nokia/Trolltech would pick up on this and make the current model/view framework part of a legacy library, but this doesn’t look to be the case.

Internal documentation for Qt (the code itself) and various project plans refer to QFileSystemWatcher as flawed. Qt’s called for ideas regarding an alternative, but I haven’t seen discussion on this. I had also hoped that QtLabs would release something along the lines of a QWinFileSystemModel. A common complaint among programmers, C++ and Python alike, is that access to Windows shell functionality is limited. With Windows 7, Libraries are in increasingly painful missing component in Windows support, and not having the “My Computer” root node in a QTreeView paired with QFSM is a UI no-no.

That segues into something else that concerns me. While I realize that cross-platform portability is key for Qt and mobile support Nokia’s primary emphasis, Qt is still the primary alternative to Microsoft’s libraries for Windows development. That’s a source of funding and support for Qt’s existence and growth that shouldn’t be neglected. I doubt Nokia cares about licensing incoming from Qt anymore, but the more developers who are familiar with and use Qt for Windows, the more it will see adoption in the mobile arena. Creating a separate library for Windows-specific support (like ActiveQt) is just common sense. Not having to “roll-your-own” is a big part of Qt’s appeal, and Windows developers presently have to do for a large portion of Windows Shell integration. QFileSystemModel is just the most obvious example of this.

I’d also love to see two related features that are cross-platform: elevation requests and recycling bin/trash support. Presently, denied requests for file operations due to insufficient privileges leave the developer hanging. For GUI applications, being able to call native sudo and UAC functionality for such operations would be delightful. The same would go for adding a function to QFile to trash/recycle files. A simple check to see if the running application is an instance of QApplication would bring up a native recycle or trash dialog; otherwise, QFile::remove() would be called.

Integrated file compression support, such as Qt wrappers bzip2, lzma, lzop gzip and other patent-unencumbered compression algorithms would be wonderful. I realize that libraries exist for this, but a Qt library to wrap this functionality would 1) be cross-platform and 2) make the lives of developers easier. Since Qt is increasingly modular, this wouldn’t bloat QtCore and offer API consistency in file operations. Compressing files is, well, it’s just something that happens often. Adding a library to support file compression and decompression seems to make sense to me.

On a related note, I’d love to see support for Windows icon files. I realize Qt has QImagePlugin for this, but it wouldn’t hurt to throw in support for something used so frequently by Windows developers. Again, avoiding rolling-your-own is good.

I feel as if I’m berating Nokia, but ignoring desktop developers (particularly on Windows) is just a bad idea. The rapid pace of development for mobile devices is wonderful, kudos, the more the merrier, but with the weight of Nokia behind Qt now, continuing to support desktop developers is not a difficulty. I would particularly point out that many mobile apps have desktop counterparts (Kindle comes to mind). If Qt shores up their desktop support, the incentive to use Qt for mobile devices goes up. Software companies whose use Qt can shift from mobile to desktop development relatively easily if the toolkit remains up-to-date in both areas, this only increases the incentive to use Qt. With Qt now being primarily community driven, this will only further increase the pace of development. It’s cyclical.