Modern Software Experience




GRAMPS is an acronym for Genealogical Research and Analysis Management Programming System. Well, I strongly suspect that this large and off-puttingly impressive name is actually an reverse acronym for GRAMPS, but no matter.


Many genealogist have heard of GRAMPS, few use it. One reason for that is GRAMPS’ limited availability. GRAMPS was developed for UNIX-like operating systems such as BSD and Linux. The GRAMPS home page suggests that there are MacOS and Windows versions, but that is misleading at best.


If you follow the installation link, you first get a warning that the Windows installer is experimental, and may be a less than most recent version. If you follow the Windows installer link anyway, the GRAMPS team admits that there are no developers committed to Windows, and basically admit that GRAMPS so unreliable that you should only use it on a copy of your data and never recommend it to your friends. That should be enough to turn away almost everyone, but if you are masochistic enough to persevere and install it anyway, you may enjoy the installation challenge. Installation is just a matter of installing five packages with stuff GRAMPS uses, rebooting and finally installing GRAMPS itself.

Not only is having to install multiple packages a major annoyance to say the least, having to reboot to install an application is a violation of Windows guidelines. They do provide an vague explanation for the need to reboot; apparently, things will not be installed correctly if you do not reboot. In fact, the whole procedure is so problematic that the same page admits that you may well see several errors even after rebooting, that can only be solved by reinstalling - and rebooting again.

Thus, GRAMPS manages to make a terrible impression even before you download it. So bad, that you will probably decided to forgo trying it. If you still bother to finish reading the Windows installation page, you will find out that you really need to install seven instead of five packages. To get relationship graphs, you need to install Graphviz first, and GRAMPS does not support PDF output until you install GhostScript.

And oh, if you try to download packages by following the links on that page, you may find that some of these links do not lead to an installation package, but a timeout error. Check your download directory to make sure you really got the file, and not some HTML error message instead.


The situation for MacOS users is not much better. That page starts out by mentioning that there are two installation packages available, but one is very old. Well, then, I’ll pick the other one. That version is provided by MacPorts, a project that aims to make things simpler for the Mac user interested in open source software. Instructions for installing are ostensibly on the "Installing from Source Code on Mac OS X" page. Never mind that installing from source is not exactly user-friendly. When you follow the link, you get a warning that you have to log in to edit pages. Luckily, below that warning is a link that goes back to the page itself, but when you follow it, you get the same warning again. The curious Mac user does not get instructions on installing, but an endless loop instead.

BSD and Linux

The situation on BSD and Linux isn’t so good in the first place. One big problem is that the original UNIX is a command-line system. Windowing is bolted on top of it, not entirely unlike the early 16-bit Windows ran on top of MS-DOS. The practical problem is choice (as, few remember, it was for MS-DOS users back then). There are various window managers and desktop environments to choose from. The Window Managers for X web site provides a nice overview. The two most popular desktop environments are GNOME and KDE. GRAMPS was written for GNOME and even KDE users, although running BSD or Linux, will have to suffer some issues and limitations.

misleading claim

The welcome section at the top of the GRAMPS home page states that "GRAMPS currently runs on Linux and Windows". When you enthusiastically decide to download and install the Windows software, you are first warned that the installer is experimental and then that GRAMPS is not designed for Windows and that GRAMPS itself, not just the installer, is experimental. GRAMPS may subtly compromise your data, and you should not use for your main database, but only toy with GRAMPS on copies of your data.

Thus, two clicks deep, the GRAMPS project effectively disowns GRAMPS for Windows, while the welcome section at the top of home page claims that GRAMPS runs on Windows.

The GRAMPS project should either qualify their Window claim in their welcome section, perhaps not even mention Windows, or start living up to the claim.

easy install for PC

There is no easy install for Windows. but there is an easy install for PCs. Right now, the easiest way to try GRAMPS on your PC is to download the Linux Genealogy Desktop CD. The current version is the Linux Genealogy Desktop CD 3.0. It is a bootable Linux CD with not just GRAMPS, but several Linux genealogy applications pre-installed. It is Ubuntu Linux 7.1 with GRAMPS 2.2.7, GeneWeb 4.10 and Lifelines 3.0.50. It is a live CD, so you can boot from CD without needing to install anything. Note that the Linux Genealogy Desktop CD version 3 does not contain GRAMP version 3.

easy install for Windows

master install

One thing the GRAMP project could do to improve the current install nightmare is create one complete package, to make sure you have the right combination of versions, with a master install package to guide the installation process. That would not be ideal, but still much better than the current mess, where the GRAMPS project carelessly dumps a weird set of requirements on the unsuspecting Windows user.

single install

An improvement over that idea is to not just manage the installs for the different packages from a master install, but actually perform the installs. It may require some cooperation with the developers of these packages, to make sure it is all done exactly as it should be done, but it would make the best installation experience for the user. Done right, it could perhaps grow into a project of its own, some kind of easy to use Windows installation package for commonly used libraries.

why so complex

Simply put, the GRAMP Windows install is so wrong because the GRAMPS development approach is so right. The developers did not try to reinvent the wheel, but made good use of libraries. Most of these libraries are pre-installed on Linux, but on Windows, you need to install these first. Each of these libraries has its own installation procedure.

The other thing they did right was focus on one platform. They decided to make a great application for BSD and Linux instead of a mediocre one for every platform imaginable.

Windows and MacOS

That they later decided to make a Windows and MacOS variant anyway is a bit puzzling. After all, as soon as you make a Windows or MacOS variant, you will be judged by their high user interface standards and the quality of the competition for these platforms. Competition such as RootsMagic, Legacy Family Tree, Reunion, and MacFamilyTree. To compete, GRAMPS should not just have a comparable set of features and ease of use, but also respect the platforms conventions as well as these native applications do.

As it is now, the Windows and MacOS variant set users up for a needlessly complex, unsupported and ultimately simply disappointing experience. How can that do the GRAMPS project any good?
Perhaps they thought is that attracting Windows and Mac users increases market share, gets more people interested in the project, and thus brings in more developers, who would help to further improve the project, and so on, in an ever-continuing vicious circle of increasing GRAMPS goodness.

Alas, to start meeting the expectations of Windows and MacOS users, and get that vicious circle of goodness going, the project would to attract need Windows and MacOS developers, and there’s the rub; that's practically impossible. Few Windows or MacOS developers know Python, and few Python developers know Windows or MacOS.


scripting language

GRAMPS is written in Python.
Python is widely considered to be a scripting language, and that typically implies that it is easy to learn and use, but interpreted, and therefore slow and memory-inefficient. Scripting languages are ideal for writing small throwaway programs in. They are best suited to jobs where ease and thus speed of programming matter more than the quality or speed of the program. Great for prototyping, not so great for production.

Common wisdom is that writing a serious application in a scripting language is just wrong. Yet GRAMPS is written in Python. Did the GRAMPS developers make a wrong choice, or is the common wisdom wrong?


Sometime in the early 1990s, I had a reason to look at the Python source code, itself written in C++, and was not positively impressed by the quality of the code, but Python has come a long way since those early days. It attracted many developers, has gone through several major releases and is available on multiple platforms - not only Windows, MacOS, BSD and Linux, but Palm and Nokia handhelds as well. There has been a Java variant for some time and there is a Microsoft .NET variant.

programming language

Python has so grown much, that it seems almost wrong to still call it a scripting language. Actually, the truth is that even the early Python was not designed as a scripting language, but as something in between a scripting language and a programming language.

To simply call Python an interpreted language has not been right for some time. The reference implementation compiles to byte-code for its own virtual machine, the Python VM. The Java variant generates byte-code for the Java Virtual Machine (JVM), an the Microsoft .NET variant generates Common Intermediate Language (CIL) for Common Language Runtime (CLR) of Microsoft .NET. There even is a Python compiler.

The Python Software Foundation is working on Python version 3.0, which will break compatibility with some current Python features to improve the Python language. Changes to the programming language are sure to impact a large Python project such as GRAMPS. They cannot just switch to version 3.0, but need to make sure everything will still work when they do. It is an occasion to tighten the coding guidelines, review all the current code and create a few more tests for the test suite.


IronPython is a Python implementation for Microsoft .NET. It is fairly, but not entirely compatible with the Python reference implementation. Perhaps it is closer to Python 3.0, you’d need to ask a Python specialist, but I do know that the IronPython intends to support Python 3.0.


IronPython is Python for Microsoft .NET, but Mono is .NET for Linux, and IronPython works with Mono. There is even a ready-made distribution for use with Mono, the IronPython Community Edition. That mouthful is officially abbreviated to IPCE, but the project is commonly referred to as FePy - you need to remember your high-school chemistry to get the joke.
FePy has not only been adapted to work better with Mono, it also includes a substantial portion of the CPython standard library. That makes FePy more attractive to Python developers with code that uses that library a lot. Whether you want to move to using the .NET libraries or not, this certainly makes it easier to move to .NET, or just give Python on .NET a try.


IronPython was created by Jim Hugunin, who had previously created Jython, Python for the Java Virtual Machine. Microsoft became interested in his project, he joined Microsoft, and that led to Microsoft improving the .NET CLR to provide better support for so-called dynamic languages like Python.


The IronPython Team has always paid attention to performance. PyStone, the standard Python benchmark, shows that IronPython is up to 1.8 times as fast as CPython, the reference implementation. The quality of the optimising Visual Studio C++ compiler may be a small factor contributing towards this result. The improvements made to the .NET CLR to support Python better are another. Then again, other benchmarks show IronPython to be slower, so this is not the strongest argument in favour of IronPython. The various benchmark claims found all over the net are often mentioned in the Python newsgroup.

.NET framework

Moving a Python application into the .NET framework by way of IronPython is an attractive option for developers because it gives them access to the .NET Framework library, lots of ready-made code for performing common tasks, for example dealing with XML files, as well as a whole industry of third-party libraries, including many state-of-the art user-interface controls. There is even a free IronPython Studio based on Visual Studio.

mix and match

The .NET system makes it easy to mix and match languages. That not only makes it possible to write some performance-critical code in C++ instead of Python, it also allows developers to provide a language-independent interface to their applications.

It is currently possibly to extend GRAMPS by writing your own report, but to do so, you have to learn Python first. If GRAMSP were running on .NET, GRAMP could allow you to use the programming language you already know.

risks and benefits

Porting GRAMPS to IronPython or Python 3.0 does not offer any direct benefit to the user. In fact, if the GRAMPS team decides to do this, development of new features will probably be on hold for a while. However, a good hard look at the current code, combined with the creation of more tests for the test suite should lead to better code overall.

Done right, the immediately practical result of that should be improved stability and performance. However, any move to a new platform is a test of the developer’s ability to adapt to the new platform. When it is not done right, the result can easily be an application that seems to reduce your multi-gigahertz Pentium PC to the pitiful performance of an IBM PC XT.
That is what happened with WinFamily when they choose to use Microsoft .NET for WinFamily 7; my GEDCOM test benchmark showed WinFamily 6 to be 330 times as fast as WinFamily 7. And when decided to move to Microsoft .NET for Family Tree Maker 2008, the result was, cough, not the most stable application I have had the pleasure to work with.

From a programmer’s perspective, the move to a widely supported modern platform is its own reward, as it opens up the possibilities of that platform. It provides a strong foundation to build new features on, but the move itself is not without risks.


Switching to Python for .NET is not the most obvious step for the GRAMPS project. It begets them more platform independence, access to lots of libraries and the flexibility to use other languages, but not without the risk that GRAMPS ends up being as embarrassingly undesirable as WinFamily 7 or Family Tree Maker 2008.

no hard switch

However, the GRAMPS project does not need to make a hard switch from one platform to another. They can start playing with a new platform while continuing to produce code for the current one. They can continue to produce a Python VM (PVM) variant of GRAMPS, while making sure their code works with FePy as well. Simply put, tightening their coding standard a bit to address the differences between the two Python dialects will allow them to create both a PVM and .NET CLR variant, and to continue to do so from that point forward.

not all or nothing

Starting with Python for .NET need not be an do-everything or do-nothing approach. It is possible to go forward in manageable steps; first get it to work on FePy, then get it to work with IronPython on Windows, then evaluate and consider what the next step should be - if any. Perhaps there should not be a next step at all; having portable code means your options are open, not that you are obliged to take any particular option.

no magic

None of the GRAMPS problems that Windows users currently experience, such as the need to install eight packages ( five plus one, and then another two), and the un-Windows-like user interface would be solved by merely making sure the code is portable.
But once GRAMPS is a Python for .NET project, it will attract not just Python and UNIX programming talent, but .NET and Windows programming talent as well. Those developers should start making the difference between a program that merely runs on Windows if you are willing to go through the installation experience from hell, and one that is actually attractive to Windows users.


2008-06-26 Linux Genealogy Desktop CD 4.0

The Linux Genealogy Desktop CD 4.0 is based on Ubuntu 8.04 and includes GRAMPS 3.01.


related articles