• translation updates: ca, cs, de, fr, hr, it, nb, nl, pl, pt_br, sk, sl, sv, uk, zh_cn
• new languages in this release: ja (Japanese), vi (Vietnamese)
• 36 bugs closed since v3.3.0 [1]
• 79 translation commits since v3.3.0
• 189 code commits since v3.3.0
• ten years since v0.1.1 was first released
• “Thank you!” to Donald Allingham, The Gramps Developers, translators, and our every day users

This is our first bug-fix release since the new feature release of 3.3.0 a few months ago.  As usual, you’ll find the various 3.3.1 packages available on SourceForge over the next few days.

Here is part of the release e-mail with information on some of the big changes available in 3.3.0:

• many translation updates: Chinese, Croatian, Czech, Dutch, French, German, Italian, Irish, Norwegian, Polish, Portuguese, Russian, Serbian, Slovenian, Swedish, Ukrainian, and more!
• new “person name” dialog and workflow with better (or new!) support for nickname, complicated multiple surnames, patronymic as surname, family nickname, and name format preferences
• gramplet bottombar and sidebar per view, with new gramplets such as details view and image metadata viewer/editor
• ability to tag objects; this is the next version of what used to be called “markers” in previous versions of Gramps
• geography view now uses osm-gps-map
• new locality field in the place editor; hierarchy is now:  Country, State, County, City, Locality, Street
• automatic check and upgrade of plugins on startup
• improved merge support of objects
• better descendant/ancestor tree reports
• undo/redo on entry fields (CTRL+Z, CTRL+SHIFT+Z)
• backup option in the exporter
• exporter based on filters with preview
• many more changes; see What’s_new

As always, you can download the latest version of Gramps from our Sourceforge page:  http://sourceforge.net/projects/gramps/files/Stable/3.3.0/

Let us know what you think of Gramps v3.3.0!

Stéphane Charette

The Gramps Developers are happy to announce a new bug fix release:

Version 3.2.6 — the “So far, so good.” bug fix release.

Highlights of fixes in this release include:

• fix memory leaks
• fix corrupted reports
• fix crash in gramplets
• fix gedcom import and export
• import speed improvements
• NarrativeWeb fixes
• prevent corrupting databases
• various other small fixes
• many translation updates

Our SourceForge download page already has the 3.2.6 source tarball and a Ubuntu 10.x .deb file available for download. As our usual packagers forward me links to their .rpm, .exe, and various other files, I will upload them to: https://sourceforge.net/projects/gramps/files/Stable/3.2.6/
There is a bug on NarrativeWeb.
Please, packagers and users should use this version, users can easily install it via Help->Plugin Manager->Install Addons and selecting to install this addon.

Best regards,
Stéphane Charette

Desperate times call for desperate measures: I sent an email to G4 asking them if there was any chance that they could make this ancient Oct. 3, 2002 episode of The Screen Savers available for viewing online again. To my delight the Webmaster and Derek Snowden (Director, New Media Editorial) were feeling generous and went to the trouble of making the Gramps segment of this video available for viewing!

I have embedded that video below in all its glory. After watching it I can appreciate where Gramps started and especially how much more advanced it is today.

Please thank the folks at G4 for sharing this little bit of Gramps history!

Curt said that we shouldn’t complain about Ancestry.com, but give them our money because whatever they do next will be even better than what they have now. No, if you have a problem with Ancestry, do not give them your money. That is the only way to evoke change.

I had many discussions with people about licensing issues and rights about the data behind the vendor’s walls. The consensus was, I think, “yeah, our license is not yet right, but go ahead and agree to it and will figure it out later.” No, I don’t think so. We need to figure this out now.

There was a discussion recently about a related topic from an international computer science organization that charges for access to on-line papers. The costs for access can be quite huge for an institution, as much as $1900 USD per year. There was some talk about rejecting the paid version and building a free version. After all, we write these academic papers, review them, edit them, select them, and bundle them. And then the organization sells them back to us? Well, the organization says “No, that’s not what we do. We sell you access and storage. You are free to take the papers out of the system and do whatever you want. It is the searching, linking, and value-added stuff that we sell.” I like that. Could we get the genealogy vendors to take the same approach?

I went to a talk on an overview of the FamilySearch API, and to one on the Semantic Web and Family Social Graph. Learned about some cool new tools for automatic web understanding, including DBPedia.org and a interesting new query language called SPARQL that I need to explore further. I went to an interesting discussion on “freeware” but the presenters had little understanding of the issues. They just knew that some programs were free, and isn’t that great? No mention of Gramps, and open source in general was conflated with freeware.

There was a party at the National Family Library, and very nice place for doing genealogy research. But the party there was designed to watch a new US show called “So who do you think you are?” (sponsored by Ancestry.com) where they research some celebrity’s past. I left, got some dinner, and started thinking about the Developer’s Challenge… a genealogy mashup of some kind.

-Doug

The opening keynote addresses from Shane Robison (HP) and Jay Verkler (FamilySearch) were only somewhat interesting, and mostly devoid of anything useful. Shane’s was a commercial for HP, and he didn’t even mention genealogy, I don’t think (and was copyright 2010—come on, we pay attention to things like that!). Next year, at least get someone who knows something about genealogy. Jay’s talk was much more on target, and I would have liked to hear more details about what FamilySearch (FS) is, and what they are doing.

Luckliy, I happened to sit next to a FS employee, and I picked his brain. According to him, FS has about 100 paid developers, and even more support staff. They are not making a product to make money, but for use by people. They get their money from the Latter Day Saints (LDS) church. I asked him if you had to be LDS to work for FS, and he said that technically, no, but everyone is. Does religion play a role at work, I asked. Yes, they have devotional time, and the religion permeates their lives. I see that all over Salt Lake City… I’ve never seen so many college kids in ties.

Walking around after the keynotes, I feel like I am in another world… I’ve never seen so many old, white people in one place before. There is literally no one of color, and there must be a couple of thousand people here. The city is somewhat like that, but this conference is even more so. There is little diversity… very few people from Europe, South America, etc. In fact, many people here seem to be from nearby. One thing is for certain: they take their genealogy very seriously around here.

Next was a special hour to unveil a Developers Challenge. The goal is to take a couple of genealogy public API’s and build a mashup—interesting combination that does something new. If you have ideas, leave me a comment below.

Ok, now for the main reason I’m here: “An Open Source Python” says the title. This was work by a computer science masters student now hired by FS. The project is Legado,  by Oliver Nina. This turned out to be a great talk for Gramps, because it ended up being half about Gramps. Oliver showed the prototype of a project where he synced a Gramps database with a FS on-line version of his tree. The idea is nice, but would take much work to make it more than just a prototype. During the talk, Oliver described how Legado works. It turns out that the base code is a Python library written by Peter Henderson, and can be found at https://github.com/familysearch-devnet/python-fs-stack. Peter will give an extended discussion on the Python library to FS on Saturday, 11am Mountain Time. Gramps would be able to authenticate against FS using either their OAuth or Basic authentication. I’m going to look at this interface over the next couple of days while I’m here.

Many people, including Oliver, asked me questions about Gramps. I think we may see some additional developers interested in using, if not contributing to, Gramps. BTW, I learned that one can get a booth at RootsTech for just $200. I would have guessed much more expensive. Something to consider, perhaps, for next year.

Next was a panel discussion with many of the major genealogy vendors in the US. This included Ancestry.com, Geni, FS, One Great Family, and a few more. It was largely disgusting watching the vendors talk about how much money they were going to get, and how they would even be willing to share little pieces of it with us developers, if we build stuff on top of their APIs. I asked a simple question: “How are users going to get their data out of your system?” Scott Mueller from Appletree.com gave a direct answer (“all of it”) but all of the other vendors were very slimy in their answers. I suspect all of the rest of them intend to try to milk as much money out of your data as they can. Even FS has some issues to work out: they have a license protecting your information once it is in their system—from you. And they also don’t want other people copying the API that they have developed. Say what? You purposely want other vendors to have to create a different API? Either I heard that wrong, or this is an insane position from FS surely guaranteed to splinter the world of genealogy on-line APIs.

I was so angry with this group that I completely missed my appointment with the Photo Detective, Maureen Taylor. I had a special photo all ready to go. Bummer.

Overheard in the vendor area: “Yes, our software runs on all operating systems: Vista, XP, and Windows 7″.  Many people here had never heard the term “open source”.

I did sit in on a talk that was made up of mostly users, and the things that they really love are surprising. I think we should look at better integrating image metadata into Gramps, for example. I went to a great talk by Jimmy Zimmerman on Document and Graph-based Databases. Document Databases are similar to BSDDB (which Gramps uses), but are much easier to use. For example, they have some very nice querying capabilities. This includes systems like CouchDB and MongoDB. Graph databases allow querying for data based on their connectivity. This includes databases like Neo4J. If you were going to develop a genealogy system in 2011, Jimmy showed us what it should look like: a graph-based system sitting on top of a document database. Interesting! I wonder if we can incorporate some of these ideas…

I have more notes, but now some food, rest, and hacking…

-Doug

Utah Skyline

There are huge mountains, and I’ll try to get some better pictures. I’ve never been to Utah before, so this was quite stunning. I’ll try to keep everyone up to date on events here as they unfold.

-Doug

UPDATE: follow me also on twitter: http://twitter.com/#!/doug_blank

For people who track the development code (trunk), you can see this experimental interface by running Gramps with the –qml flag, eg in the main code directory:

python src/gramps.py –qml

Edit: You need to install python-pyside for this to work.

You are greeted by a screen that allows selection of a family tree, and creation of a new family tree:

The difference with a normal desktop list is that in a mobile interface rows expand to see details, and allows interaction. In this case it shows the last access date and allows to rename by typing something different (enter to store it). It looks like this:

On opening a family tree, a central view is offered that allows several interactions. At least, that is the intention. For now, it only offers to open the list of all people. This list is just a simple list:

Not visible is the nice kinetic scrolling. Not very usefull yet, as you eg cannot go back to the family tree selector, but a good first try.

So, what have we learned? As a nerd it is always nice to experiment with new techniques. And this is quite a different way of doing things. My main observations:

• There are no controls yet in QML. So one has to design everything. It seems one needs some website designers as QML is much like javascript. A programmer offers functionality, and a designer makes a nice interface. It took me quite a lot of effort doing the simple layout you see here. Let’s hope experience makes it easier.
• There are not many controls, eg, if you want a checkbox, you need to create one with rectangles and images! This should improve with QML components in the future, but licensing of these is not clear yet. Eg Colibri is really nice but has a strange license, and Nokia is creating Meego controls but they are not yet be distributable (but probably will be LGPL, so usable once Meego is released).
• The experimental interface shows how Grramps code can be reused to quickly do things: encapsulate objects to show in QML, callback to update data (like the family tree name), … . So, once you succeed in creating an interface that looks nice, everything is available to make it quickly work.
• A small screen is …. wel small. There is a huge amount of functionality you might want to cram in it. Not easy to decide what is important, what to leave in, what to leave out, and how to offer the functionality without the interface becoming cluttered.

What now? Well, let’s see what others think of this experiment. Many ideas on how to go forward, but probably good to first make sure the fundaments are good: how to go back a screen, how to switch screens, how to give the central view a meaningfull layout, … . My idea to go forward would be

• build out the person view so it becomes usable. A find bottombar? Expand a row on click to show all overview? Edit data on screen or a details button for a new screen?
• factor our reusable components. Eg, a class like the base class for all windows in normal GTK
• create a gui.core where pieces of current gui can be stored that do not need the GTK component. Eg, the person list uses the nodemap of the basemodels, but loading that means loading the GTK part that is part of the same file.

It seems clear that the ‘old’ way of working, using a laptop or desktop pc with a keyboard, will not go away for the professional hobbyists needing to get work done. It is just as clear that this ‘large’ pc will be complemented with a smartphone and/or tablet.

So where does that leave Gramps? Unfortunately the phone OS makers have not chosen the PC model to create their phones, but instead have chosen for specific tools one has to use to deliver an application to the phone. In the PC world, you can use whatever you want and ship it to the users computer, in the smartphone world you need to use or Apple’s SDK, or some sort of Java (Android), or Silverlight (.Net, MS). This essentially means rewriting your application in these languages, not very attractive for Gramps as you need to enlarge the skill sets of the contributors, and cannot just reuse the things that are working great in Gramps.

There is however a fourth way I am investigating. Nokia has the N900 device on the market, and probably will release a Meego phone in the near future. These phones follow the PC model, so they allow different tools to be used in order to create an application. One of these is python, the tool used to create Gramps, so the same developers can work on it and can reuse large part of the logic as written for Gramps. (Note that if you ‘root’ an Android device, you can do this too, but probably not many people will want to do this, and, moreover, the phone makers might not allow you to do it (eg Motorola)) (also note that Bada OS from Samsung might also allow python).

So, it seems that for now our only hope of leveraging the Gramps code to quickly make a mobile app would be to aim for the Meego platform. We still need to decide on the widget toolset then however. On one hand there is Gtk-Clutter, on the other Qt. As Gramps is now using Gtk for the visual elements, Gtk-Clutter seems like the best choice, but as we have to rewrite the user interface anyway, and because Qt is the official way that Nokia sponsors,  my guess now is that it is best to aim for a Qt interface. This is just my feeling based on my experience, don’t search anything behind it.

It is hard however to choose a winning platform. Choosing the wrong technical basis means redoing things when a project is abandoned. For example, we also have to choose which python bindings to choose so as to talk with QT. There are two, PyQt and PySide. As PySide is the official Nokia sponsered bindings, it seems safe to assume they will keep it current and have it installed (or easily installable) on whatever device they might ship in the future. So my choice would be PySide.

So, if we do a try to create a Gramps Mobile Interface to use on a touch interface, it now seems our best bet is to go for core components: python, Qt and PySide. This should allow us to reuse all the logic present in Gramps, and just put it in a new jacket to show on a mobile interface. And who knows, perhaps somebody can do a tablet interface going from there?

One thing is certain, as Gramps ships as one big component at the moment, it will have to be part of Gramps. If this succeeds, we will have to split up Gramps, so that we can install separately gramps.gen, gramps.core, gramps.gui. This new component will then require gramps.gen and gramps.core, and not gramps.gui which has the GTK requirement. But those are dreams for the future!

In part II I’ll show what my first experiments with this are leading to.

Gramps, The Movie

Gramps stores all of the changes made to its source code into a repository. Recently I stumbled onto a tool for visualizing repository file changes over time, called gource. Of course, I had to visualize these changes, watch the history of Gramps, and uploaded it to YouTube.

This visualization shows all changes to Gramps between Feb 15, 2003 and Oct 6, 2010 compressed into 8 minutes. Developers zap their changes to the source code which is represented as a graph. Most recent changes take center stage, while unedited sections fade from view. Many people have contributed to Gramps in many ways over the years, and no sign of relenting.