Matt Jones' Blog

Note: Before you read this, know that I like Network Manager. I’m using it as an example, because I liked it enough to want to hack on it. I don’t want to piss anyone off that works on it. This is just my biased opinion and experience with it.

I’ve been researching problems in the current desktop paradigm for a few years now. I even carry a list of said problems around in my pocket. Throughout the years there have been a few problems that have driven me mad. I have seen them reflected in so many dying projects. I literally have dreams about them, where I’m at a podium in front of millions of developers, trying to beat them in the head with the most critical problems.

By far, the most critical problem is: “The barrier to entry for contributing to other projects is too large. If you want to contribute to someone else’s project, you have to spend hours or days reading their code, and trying to find out where everything is and how the ‘program flow’ works.”

For example, recently I had a few hours and decided to spend them looking at the code for Network Manager, to see how I could add support for EVDO laptop cards (I was using a Verizon pc5740). I decided on two goals for that sitting: first, to figure out how NM uses HAL to get information on networking hardware. And second, to figure out if HAL worked with EVDO cards. I downloaded the NM source code and started looking in the src directory. I had the immediate observations:

1. Where is the start of the program?
2. It looks like this is actually a daemon and an applet, possibly more
3. Most everything, header files, source files, and make files are dumped into one directory
4. I remember why I haven’t used C or C++ in a few years, on my own projects
5. Has anyone on this project even heard of Model View Controller?
6. Why the hell do Gnome developers still use C?

Those are some dirty thoughts. I continued to dig. I found main and started reading. Still not knowing if what I was looking at was some sort of service or the Network Manager Applet. Next I noticed the naming convention used. It seems that they are using the naming convention of giving everything a prefix such as “nm_” to simulate name spaces. There is no context of where the function or variable comes from. Because the directory and file structure does not reflect the namespace, I had to search through many headers to find out where functions and variables were coming from.

Once I finished main, I decided to just open a bunch of the other source files, and look at their code. The problem I encountered was that there was no context to where this piece of code would fit into the program flow. In order to determine that, I would have to go back to main, and trace the entire flow of the program. I had no desire to do that, so I moved on.

Next I decided to just look at the Models, because they would have to be networking hardware. I could then find out how the other hardware was accessed and then see if an EVDO card could be hooked up the same way. But of course that didn’t turn out. There was zero separation of data, logic, and user interface. If they had used Model, View, Controller, this would have been much easier.

So a few hours had passed, and I was about half way through my four hour block. I decided to look at one of the small examples to see how this program could be easily used in a few lines of code. There were no examples.

I used beagle to look for the dbus and hal calls to try and find the “magic” of how the program worked. But as usual, almost every function used dbus and hal. It was nearly impossible for me to figure our the “flow” of how either dbus or hal were used.

Ding. Time was up. It had been four hours. I had made zero progress. I was pissed. Pissed at how Gnome worked under the covers. And pissed at myself for not understanding the inner workings of someone else’s mind. I closed all the gedit tabs and deleted the Network Manager source code.

Now, what were the problems I encountered?:

1. It was very hard to track the program flow
2. There was little context to any of the code,
3. Code namespaces and class names were not reflected in the file and directory names
4. There were no example programs to help me get started
5. It was difficult to find main
6. There was no separation of Model, View, and Controller
7. There was little separation of layers of abstraction with dbus and hal code everywhere
8. The limitations of the C language were hampering my progress. IE: No unit tests, no namespaces, cryptic make files, and evil header files

Now we could have solved those problems by changing a few things:

1. Make it easy to track program flow, by using Model View Controller, and having the file hierarchy reflect the code namespaces
2. Use a programming language that supports unit tests, object orientation, and importing code rather than header files
3. Have a few example programs that show how to do very simple stuff. The more trivial, the better
4. Sticking to Model View Controller would have also solved the abstraction problems, as the dbus and hal stuff would naturally gravitate into Models
5. Having a unit test friendly language would have made it easy for newcomers to know if they screwed anything up

Will any of these changes be addressed in Gnome? I don’t think so. Things may get a little better with Vala becoming popular. Despite that, any Gnome developer reading this will probably think I am an idiot, that just needs to learn the ropes. Which is exactly the problem. The way things work is the barrier to entry. I keep harping on Gnome, but KDE has the same problems (It is astonishing how similar KObject and QT is to GObject and Gtk once you spend some time with them).

To answer my question, I can’t contribute to many Gnome projects in 2 to 4 hours because of the way things are developed, and the way the code is organized.