Digested

I have an itch. I need to get hundreds of pieces of paper to my bookkeeper who happens to be on the other side of the country. And as usual, when poking an itch things happen in interesting ways, opening up possibilities. So start with Python, PyQt and the KDE python bindings. The plan was to write some kind of bulk scanning application, with the ability to annotate notes to the scans, bundle them up in a pdf, and send them off by email. Some issues that I ran across. The python-imaging-scan module is quite flakey. Repeated scans would lead to crashes. I encapsulated it within a subprocess, which seems to prevent bringing the whole application down, and somehow allows it to do it's thing each time reasonably reliably. Still has issues however. The python-keyring-kde works nicely. Very simple to use, and it works. I use it to keep the password needed to login to send emails. The python-imaging is very nice. I clip the images to remove whitespace around it, and it is very easy. To create a QImage is trivial using the QtImage module. The reportlab pdf creation module is very nice. Once you get your mind around the structure, which is much easier than the documentation seems to portray, it is very easy to create a simple pdf. The code is at code.google.com. There are doubtless many bugs, and I have only done testing with the scanner that I have.

Jasper's blog (and the seeming tenor of planetkde today) seems negative. It isn't. It is the truth. The Linux desktop is, for all it's advances and neat stuff, pretty limited.

There are a few reasons for this. Starting from the premise that it, for the most part, is written by individuals or groups to scratch a specific itch:

Major parts of the infrastructure are either missing, old and outdated, or unstable.

The process of filling the gaps and getting things working has required throwing away quite a bit of stuff, requiring updates elsewhere in the stack. Which consumes resources and creates instability and raises the cost of entry.

The amount of basic infrastructural work required to write even a modestly ambitious application limits the field to the devoted and few.

Throw in the tendency for distributions to attempt to differentiate themselves by infrastructure projects that try to solve a problem, but end up being either chronically unfinished, poorly thought out because of lack of communication, and many times eclipsed by smaller projects that work well, are well maintained but refused entry by the NIH syndrome.

And because the whole thing is necessarily in flux, the cost of entry and cost of maintainership rises.

Have no fear. It will get worse before it gets better. By the time the Xorg guys are done, and the kernel guys get a file system and scheduler that works for the desktop, and all the *Kit stuff gets finished, we will have something great. In the meantime, a mess.

What all this means is that we will have new media players every week. We don't have users that require the broad range of applications and functionality, some of which will write that stuff if the basics were there because the functionality isn't quite there yet. Linux and desktop will always be a developers platform, and as the basics get sorted out, people needing specific function for vertical or specialized requirements will flock to it. For the simple reason that it is cheap and easy.

It isn't easy now. But it is getting closer. Stuff like akonadi is amazing, opening up possibilities that the pim guys haven't imagined, and making basic function easy for developers. PyQt is simply awesome as a RAD environment. The stuff I'm doing with it makes me wonder why I would ever use C++ again. Fast and stable. The nepomuk stuff is cool, and we are going to see very neat things come out of it. Not some Nepomuk Application, but making it easy for developers to sort and index and connect their data opens possibilities that otherwise would take too many resources to write.

As for attracting and expecting commercial ports of applications to Linux, we might as well wait for the moon. It won't happen. The only way we would get a stable Skype on linux is if someone wrote one. The commercial houses have no interest in doing anything but token support of linux to check some boxes for someone. And they will never fit in with our very nice packaging and updating systems. As it always has been, if we want something good, we have to write it.

I still believe in a rich and thick desktop computer. Web based applications take me back to edlin except with colors and pictures. Serious handheld applications remind me of a time at my local credit union, oh 25 years ago, watching a woman enter information into a dbase table. She typed in a bit of stuff, hit enter, and waited a while for the data to be transfered to floppy I think. When I say serious I means something I can do business with, not texting or even email. The desktop allows a rich experience, and with quad cores, 2 terabyte drives for cheap and low cost seemingly unlimited memory, the possibilities are endless. And we will write them.

Oh, and finally. The stable, well finished and usable desktops from Apple and Microsoft are as good as they are because a bunch of guys in their basements, in their spare time made fools of them. OS9, Windows95, even NT as a server were pretty bad. They were forced to improve their wares, their processes by free software nipping at their heels. That is something we can all be very proud of.

I've packaged up a tarball to make a first release of idfeditor, an application to create and edit the configuration files for Energy Plus building simulation. It can be found at code.google.com/p/energyplus-frontend. The first release is very basic allowing editing of most elements of the configuration file.

Next is to simplify viewing and editing the building geometry. Energy Plus has a few different ways to represent the information. One way is vertices, with a building element made up of a series of 3d points. The points can be relative to a building basepoint, or zone, the points can be clockwise, counter clockwise, starting at any of the four corners, etc. Or there is another way which has azimuth or facing angle, tilt, origin, length, width. Again from origin. It is quite flexible, meaning quite complicated and error prone.

Right now I'm working on translating the various input types into xyz space, something suitable to transforming, rotating and such. The first goal is to get the code to the point where it reads and writes the data reliably with all the defined input types. The math is fun. I vaguely remember learning all this stuff in school, and have the horrifying memory of doing the calculations on a slide rule. I can't honestly say that it is coming back, that would assume there was some memory remaining. It is all pretty basic vector geometry.

Almost ready for the first release of Energy Plus frontend, idfeditor. code.google.com/p/energyplus-frontend. The link lists the features that are done. I'm in the process of testing by building and editing a simulation, and am finding the odd thing that needs fixing. There are many things I want to do to make creating a simulation easier, but they will have to come in future versions. Anyone who wants to test can checkout the svn tree and run "python idfeditor.py".

One issue that I'm not sure about is regular crashes when calling QFileDialog. It doesn't crash each time it is called, but seemingly random. The traceback shows a call to free() in Qt. The PyQt folks may have some ideas, but has anyone else run into this? I'm not sure if it my Arch Linux setup which is somewhat bleeding edge.

Been rereading The Brain that Changes Itself (link). A friend had a severe injury a number of years ago, lost two limbs. He experiences phantom pain, where the missing limb hurts or itches. Quite common for amputees. A neurologist figured out a mirror box, where for example if you have one hand amputated, you put the good hand in this box, and you see the mirror image in another compartment. The patient is told to imagine putting his phantom hand in the other compartment.

The movement of the good hand is reflected, and the brain sees the mirror image and gets the impression that the missing hand is moving. People would find the pain and odd feelings from the missing hand go away. About half of the patients treated in this way improved.

The gentleman who figured this out, V. S. Ramachandran says to his students "when you go to meetings, see what direction everyone is headed, so you can go in the opposite direction. Don't polish the brass on the bandwagon". He describes pain as "an opinion on the organism's state of health rather than a mere reflexive response to injury". Out of these insights come therapies that help in dramatic ways.

The energy plus frontend is progressing. I wrote a script that reads the class definition and generates python classes representing all the elements that make up a building simulation. Right now I'm working on models that encapsulate the data for the variety of views that are needed. Andreas Gerber, who teaches building technologies, has contributed code for writing out the definition data from the classes.

An itch showed up, I needed (wanted) a simple, or so I thought, application to edit or create a definition file for the Energy Plus building simulation suite. Energy Plus is a US department of energy sponsored project. You need to define the building quite specifically. There are applications available for windows, or for purchase. So I decided that the best way to learn the rather complex structure was to write some code to fool with it.

I started with Ruby, but when I needed some gui stuff, found the bindings not up to date. PyQt is up to date and well supported, so I started writing. First was to parse the definition dictionary provided in the suite to build python classes representing each needed description. The classes would know how to read, write, edit and draw the particular element. Or would once I wrote it. Then read some example definition files, and work on the edit code. So far, so good. There is still a ways to go, but I'm seriously impressed how quickly one can bang out a working application for a specific purpose. This isn't trivial; the definition files are complex, long and involved. I have some widgets to write, some careful parsing through the results to check for accuracy, and some code to draw a few elements onto a graphics scene to represent the building outline. I suspect another 40 or so hours on top of the 40 or so I have into it already to get something useful.

Very impressed so far. PyQt is well documented and works, python works well and is reasonably quick. Qt is of course very nice to work with. It is so quick to build something useful.

The project is at http://code.google.com/p/energyplus-frontend. You need python, and pyqt. And the energy plus suite mentioned above, which is free. Get both the linux and windows one, it runs in wine. The windows package has the dictionary files required to build the classes. I'm working with the v3.1 stuff, and eventually may test with earlier versions.

The prerequisite screenshot. Note the empty space in the middle. A graphics scene ready for one's imagination.

The opening of the Qt repository is potentially the most important move Nokia has made.

Jeff Jarvis documents the decline of print media and explores strategies that could be adopted to keep in business. He describes an attempt to build a news product with community involvement, attempting to use the community. He probably inadvertently describes some of the attempts to leverage free software developers. It only works if people are building something for themselves.

Nokia is building something for themselves, and opening the repository (and adjusting the license) so that developers can build something for themselves.

One might add that having developers by definition as users of the library makes it more likely that valuable contribution will happen. End user applications face a bigger hurdle in eliciting contribution.

I have an article in lwn.net this week regarding the Qt announcements.