Tag Archives: Gnome

www.gnome.org

Liam at one year, standing

Liam is now one year old. The months have passed quickly but the progress is obvious. He can now stand easily though he only bothers when distracted by something shiny. He walks sometimes holding our hand and I’m sure that any moment now he’ll stop needing to hold on. Even without walking he gets around incredibly quickly, indulging his need to take things out of their proper place, take them apart, and then jam them all back together again.

Peek-a-boo and pretending to be chased are his other main interests.

For the last six months, I’ve been working part-time, spending two and a half days at work and two and a half days at home taking care of Liam, with not much time in between for other things. I am very lucky to spend so much time with him – if really helps you create a strong bond.

Hopefully in March there will be a place for him in a Kinderkrippe/Kindergarten for a few hours a day. He’ll need that to get enough time with other kids, and it will take some stress off my work routine, though I’m unlikely to be working totally full-time for the forseeable future.

Documenting Telepathy: Examples

I’m gradually working on documenting Telepathy, the IM/real-time-communications toolkit, though I am currently still exploring the API rather than writing text, and I am only using occasional hours here and there for even that. The delay is more due to me than Telepathy. With the help of the Telepathy developers, I have  completed some simple telepathy-glib examples, giving me a feel for the API. I can now start to write up some of the text.

Telepathy actually works and is full featured, and has many people working on it. That makes it very useful to many people.

But to be honest, the API feels frustrating so far and I think you’ll see what I mean when you look at those examples. I’ll continue trying to document it so people at least know what to do, even if what they have to do doesn’t seem very nice.

Apart from the many little annoyances, I think the API suffers greatly from extreme use of asynchronicity, instead of fighting to protect application developers from that. I think that’s partly due to the choice of D-Bus for the implementation, instead of just using a C library, forcing every method call to be asynchronous. There’s also a tendency for high-level actions to consist of  multiple small (asynchronous) low-level steps, though that’s partly due to the awkwardness of simulating an object-orientated class hierarchy in a D-Bus API where even (the equivalent of) a cast is asynchronous, and a consequence of needing to discover interfaces at runtime, due to inconsistent interface coverage by the various plugins (connection managers). There’s also a tendency to expose the (naturally asynchronous) client-server network behavior of the protocols directly in the API instead of combining and hiding multiple network back and forth behind simpler API, though the new TpContact class does a lot of work in the background.

However,  I have not yet explored the whole API and don’t yet have a full sense of the common ways that the API is used, so my judgement could conceivably be wrong. I also suspect that it could be much worse.

Meeting the new Openismus Trainees

I was at the Berlin office on Friday meeting our trainer (Daniel Elstner) and two new trainees: David King and Michael Hasselmann (not Mathias). They should all blog more, at least when they start in January.

I am very positive about these guys. I stressed how we want them to develop good habits based on empathic consideration for the users and developers who will use their code and real understanding of the languages and APIs they use. We want to build excellent developers who are an example to others. Character and communication was a major issue when choosing these trainees via email and they show that in person.

This is an important step for the company. It makes it easier to predict when we will have new developers available and helps us to merge those developers into a cohesive culture. It also means that we’ll have more full-time people to help out with unexpected extra work. I’m proud that we’ve stuck to our 35 (productive) hours-per-week rule instead of pushing our people to be stressed and unproductive, and now that will be easier.

The Berlin office is coming to life too, with 5 people there. Overall we’ll now have 11 employees (3 part-time), which feels substantial to me.

Scanner for Linux?

Can anyone recommend a fairly recent model of scanner that is absolutely sure to work with Ubuntu Linux. I guess that means that it will work with the “XSane Image Scanner”, from inside Gimp, and with the gnomescan project’s “flegita” GUI. By recent I mean widely available to buy now.

I have too many paper-only documents so I want to back them up electronically.

As usual, the information about supported hardware out there is rather vague, with wildly differing interpretations of “works ouf of the box”. If you need to compile a driver or edit a text configuration file then it didn’t work out of the box.

Update: I don’t really want to buy an all-in-one device just to get a scanner. I already have a printer.

Trainees Chosen

The response to my call for Openismus trainees was excellent. I have now selected two trainees who will start in January 2009 and I really wish we could afford to take a couple more. I’ll announce the names soon. Furthermore, Daniel Elstner will return to Openismus to train them in the Berlin office, starting in December.

I think I’ve replied to everyone personally. If I’ve missed anyone, please do email me again so I can give you a more specific response.

projects.gnome.org

With Olav’s help, I have now moved both www.gnome.org/projects/ and developer.gnome.org/projects/ to projects.gnome.org, with the old URLs redirecting. That sub-domain existed before, but I don’t think anyone was using it. It’s still in the old gnomeweb-wml svn module, but it’s separated into its own subdomain directory. Tell me if anything still seems to be broken.

We did this so that:

  • developer.gnome.org can become even more irrelevant so nobody will notice when we kill it one day.
  • The huge amount of content in the projects pages will not block implementation of any new system for www.gnome.org, such as a CMS. In comparison, the rest of www.gnome.org is a very small amount of content.

Gramps for Geneology

My father has become slightly obsessed with tracking his family tree. He’s done lots of research going back around six generations. He uses a Windows application (called “Generations”, I think, but I’m not sure now), which is very awkward, though he manages.

When his grandson Liam arrived, he wanted to put Liam’s family tree in his system too. Germans tend to have quite good family records, backed up by Church archives, so we had some data.

I exported the result as a GEDCOM file and was really pleased at how well the open source GRAMPS application imported this file on Ubuntu Linux. For some reason I didn’t have high expectations, but this application is obviously well maintained.

And Gramps seems to be a better application anyway. It has a more sensible UI even though it is as feature-packed as these applications needs to be. Gramps also creates more compact ancestor graphs, so you don’t need to tape so many pages together. But it could still theoretically squeeze more on to the page at a readable size. This might already be possible but it’s hard to achieve with the awkward printing options.

Openismus wants trainees

It has always been difficult to find GNOME developers to employ. So for a while I have wanted to grow some new developers of our own. Now that the Berlin office is established we are ready to start by hiring some junior developers.

If you are smart and enthusiastic but you lack experience then we can provide the opportunity. You would work mostly on existing open source projects instead of customer projects, just to get experience with C, C++, GTK+ and Qt. Our developers would provide technical guidance and encourage you to work and communicate in a structured way, creating software that’s actually usable and useful.

This is also a great opportunity to move to Berlin – a wonderful city for young people.

developer.gnome.org cleaned up

Every now and then I try to do some more clean up of developer.gnome.org, aiming to move any good content to

  • library.gnome.org, as docbook in a source code module, so it can be kept up to date by the relevant people, and translated, or
  • library.gnome.org, as an external link to some other website, or
  • live.gnome.org, if many non-developers will want to change it often.

It has taken a long time, with lots of emailing, searching, hacking, incredibly quick library.gnome.org help from Frederic Peters, and advice from Shaun McCance, but I have finally reached the point that the main developer.gnome.org page is now just a link to the library.gnome.org developer section and two links to some archived stuff.

There is still stuff in the projects directory, which is only really used by the Usability and Accessibility projects. I don’t think that summary page was ever linked from anywhere. I’d like these to be moved to a new projects.gnome.org subdomain, combining with the www.gnome.org/projects/ stuff that seems to have lots more content. Actually projects.gnome.org exists already, as a bad (no stylesheet) version of the www.gnome.org/projects summary page. Moving all this projects/ stuff into a new svn module would make future changes to www.gnome.org easier.

Then we could kill developer.gnome.org completely. I don’t think anyone has any other plans for it. I don’t even think the archive of old content has any real value, but maybe we could move that to dgo_archive.gnome.org or such suchlike.

Glom 1.8

I have released Glom 1.8, with many new features and bug fixes. We have not yet fully completed some of the new features, and the refactoring may have introduced regressions that we must fix in 1.8.x releases, but we need to get it all out into the world and move on to Glom 1.10, including porting to libgda-4.0.

We have probably missed the schedule for getting Glom 1.8 into Ubuntu Intrepid so I’ll create some PPA packages when Intrepid is released.

Useful new stuff in Glom 1.8:

Network sharing

As you can see in the new initial dialog, you can now choose to open a Glom system from the network, if a colleague is already running it. This is much easier than getting access to the actual .glom file on a shared network drive.

This uses the new libepc (Easy Publish and Consume) library, developed by Mathias Hasselmann, using avahi and libsoup. There’s a chance we might use telepathy in the future.

Armin implemented the new dialog, and I implemented the load-from-network code using libepc.

Import

You can now import CSV (comma-separated) data in to the current table. The assistant helps you to choose the field mapping, showing you sample data for the first few rows.

Johannes implemented this.

Drag and drop layout

You can now drag items from the toolbar (hidden by default) onto the details layout, and you can drag items within the layout. The automatic layout reflows as you do this.

Yes, we know that the dotted lines are particularly ugly, but I don’t yet know of a better way to show the limits of the columned boxes and items, which may be inside each other. Mockups would be welcome.

Johannes implemented this. It was a huge job and he’s probably glad to be doing some other things now. This uses the EggToolPallette toolbar, developed by Mathias and Jan Arne, that we hope to get into GTK+ eventually.

Print Layout

This is very primitive right now, but you get the idea. Unlike the on-screen layout, this uses precise positioning. That allows you, for instance, to print in the correct places on a pre-printed form.

Most importantly, we need to add some way for fields (particularly lists of related records) to flow into each other, maybe using allowing them to be special objects in text blocks.

I implemented this, if you can call it implemented. I used goocanvas (via the goocanvasmm C++ bindings). I also rewrote the Relationships Overview using goocanvasmm. It also uses the EggToolPallete. I guess we should move it to the left to be consistent with the regular layout toolbar.

Windows Installer

Armin built Glom and its dependencies (apart from Avahi) on Windows and created an experimental installer.

Armin and Johannes also updated Glom’s client-only Maemo build.

What’s next

We need to finish the print layout and drag-and-drop features, and port to libgda-4.0.

I also want add a platform-specific alternative layout option, so one .glom file can have large layouts for regular PCs and small layouts for Maemo, for instance. I’ll probably get around to doing that for 1.10. On Maemo, I also want us to use the new UI elements in Maemo 5, if the Maemo SDK is released.