Mad, Beautiful Ideas


About this Archive

This page is an archive of recent entries in the GNOME category.

Games is the previous category.

Hacks is the next category.

Find recent content on the main index or look in the archives to find all content.

JS Array lastIndexOf


Recent Entries

Recently in GNOME Category

GNOME Support of OOXML

Russell Ossendryver, who sits on the OpenDocument Fellowship, recently heavily criticized GNOME for supporting Microsofts Office Open XML (OOXML) format. While I agree with the basic intent of Russell’s post, that the Open Document Format is already an ISO standard and there is no need for a new standard, I feel that he does a poor job of understanding the events he’s commenting on.

There are only a few instances that I am aware of where GNOME Foundation Members, or Developers have given any indication that OOXML is a worthwhile format. Earlier this year, Miguel de Icaza posted several large posts about why he felt that OOXML was a good standard. A large part of this, was simply that he felt it was a more complete standard than ODF was. Miguel claims that ODF has 4-10 pages devoted to documenting Spreadsheet formulae and functions, while OOXML has 324. This raises an interesting point, as many people have criticized the OOXML standard heavily, due to it’s 6000+ pages, compared to ODFs trim 722. Miguel’s point is that to implement an ODF spreadsheet application based on the ODF documentation, would force a user to examine an already implemented solution. I suppose he would know.

Finally, the gnumeric team has said that it was easier to implement support for OOXML than ODF. When you look at the history of gnumeric, this really isn’t a surprise. gnumeric used to be criticized for being such a perfect Microsoft Excel clone, that they even reproduced several of the more insidious bugs in Excel. Humorous, yes. But not necessarily good. In effect, gnumeric was structured internally in a fashion very similar to Excel, which made supporting OOXML very easy for the gnumeric team.

Really, this all comes down to which is the better standard. An open standard is an open standard, regardless of who drafted it. Admittedly, I am as wary as Microsoft as most long-time Linux users, but any technology they’ve released that has been loosed upon the world as an open standard, doesn’t make me as nervous, which is why I support Mono. Again, I can’t argue with Miguel about which spec is more complete, but there are others who can. According to Rob Weir, OOXML’s forumalae descriptions are deeply flawed, such that all that description doesn’t matter since the answer won’t be correct anyhow. Plus, OOXML is nothing more than an XML-ized version of Microsoft’s old binary formats. Microsoft did nothing to clean up the format to be human-readable and editable. It’s still covered in optimizations that were made 15 years ago, but simply don’t make sense in today’s world. The file format used in Office 2007 isn’t actually the same format submitted to ECMA and ISO. I could go on.

OOXML is a poor standard, not because it comes from Microsoft, but because it doesn’t offer any of the benefits that XML should offer. It’s a binary format wrapped up in XML, where there are so many interdependencies that the only good way to modify a OOXML file programmatically is to use the Office COM objects, since editing the XML directly is almost certainly going to break something. OOXML isn’t even a step forward in Microsoft Office documents, let alone in Open Standards. Plus, ODF is better for business, since it natively supports document-wide options to ensure that calculations are done with correct precision, which is very important in accounting. Microsoft Office has a long history of rounding errors which can cause problems, and there are no signs that they’ve gotten any better with Office 2007.

While I agree with Mr. Ossendryver on the overall point that ODF is simply the better format, his criticism of GNOME for supporting .NET as well is simply foolish. No Open Source project (aside from Mono, obviously) can compare to what .NET is. Even Java is a poor comparison to .NET, as it lacks many of the features that make .NET so interesting. The ability to easily share code from different languages, and share variables between those languages. Plus, in my opinion, C# is simply a superior language to Java, though it’s existence has begun to push Java to new heights I don’t believe it aspired to before. Ultimately, Mono wasn’t about Microsoft Interoperability. It was about making development for GNOME easier, and I think it’s done that. However, interoperability with Microsoft technologies is not a bad thing for Linux as a whole.

It’s not secret that Microsoft has been pushing .NET incredibly hard since it’s inception. With .NET 2.0 and the new .NET 3.5 being released soon, developers for the Windows platform have really embraced the tehcnology. Mono provides a means to show developers that the application they developed in .NET can be made to support Linux with relative ease. Making it relatively simple for developers to target multiplete platforms with a single codebase increases our choices of applications on all platforms. In his interview on FLOSS Weekly, Ryan ‘icculus’ Gordon makes an observation based on his time at Loki Games. Targetting individual games wasn’t going to get Linux anywhere. It was in the best interest of Linux and Linux Gaming to target platforms, such as iD’s engines (which iD has always been good enough to port), and the Unreal Engine.

By making these game Engines available on many platforms, developers can choose to target multiple platforms without having to work too hard at it. While few licensed games for Unreal Engine have been released for Linux to the general public, this has evidently made a large impact on Arcade Game manufacturers, who can cut costs by using Linux and only having to license Unreal. Mono serves a similar purpose. It provides developers with an option to use a different platform, and it’s apparently become fairly popular among ASP.NET deployments.

I still feel that .NET is a good Open Standard, and a solid platform, and I’m pleased with the work that Mono team has done to develop it. While I fully support ODF, and hope it becomes the format of choice, I argue that we should fight against OOXML because it’s a substandard format, not because it was written up by Microsoft.

GTK+ and Object Oriented Programming in C - Not worthwhile?

I was reading the Monologue this morning, and a blog post from Laurent Debacker came across the wire. He was writing about the Ribbon Sharp library he’s been working on, and his own feelings about the GNOME project from a GNOME outsider. Now, personally, I don’t much care about the Ribbon support he’s been working on, as that is probably my most single hated change in Microsoft Office 2007. That may just be because of how severe a paradigm shift ribbons are compared to the classic menu view.

However, his comments about GNOME were interesting to me. Laurent admits that he is pretty new to the GNOME community, and he appears to be fairly young (though probably close in age to myself), which may well explain a lot about his views on software development. The specific comment I’m referring to this

I think that the main problem with GNOME for a new developer, is that programming in OO in C using Gtk+, is a bit like programming in COBOL.

I can definitely see where he’s coming from this comment. However, I view this primarily as a problem with the education provided by most Programming courses. Object Orientation is not a technology. It’s a paradigm.

Certainly, it is much easier to perform Object Oriented Programming in a language which was built around the paradigm (C#, Java, C++). Once the Paradigm in understood, migrating it to a traditionally procedural language such as C is trivial, and will bring about the same design benifits. If anything, being written in C is a huge benifit for GTK+/GNOME, as it’s C roots have facilitated the porting of the libraries to a vast number of platforms, and bindings have been written in a large number of languages. (To be fair, Laurent does mention the success of the bindings).

However, the largest reason GTK+, and by extension GNOME, are written in C is history. GTK+ was designed as a replacement for Motif, when the GIMP project decided they needed to migrate away from Motif to be a truly open piece of software. Motif was a C library, GIMP was a C program, C was the only obvious choice. Then, ten years ago Miguel de Icaza decides to start the GNOME project, in response to KDE using QT and QT being non-free software. At the time, Miguel didn’t view GTK+ as ideal, but it was far better than programming straight X11, and it was available. (For more on the founding of GNOME, check out Chris Dibona’s interview of Miguel on FLOSS Weekly).

So, C was the language of choice, and by now, so much of the backend is written in C that I don’t think that’s going to change. The only potential ‘disadvantage’ I can see of GNOME remaining in C, is that in order to add a widget to GNOME such that it will be available to all bindings, is to write it in C. I don’t really see this as a problem as I don’t think C is going anywhere anytime soon, and GNOME performs very well having been written in C. Plus, the alternative proposed by Laurent carries with it several distinct disadvantages.

  1. If GTK+ 3.0 were to be ported completely to .NET, it would only run on platforms where Mono was supported. Currently, that list is comparatively short.
  2. C code would still be required to bind to the underlying system APIs (X11 on Unix, Win32 on Windows).
  3. If the language isn’t .NET compatible, it can’t be bound.
  4. It would require reimplementing an enormous amount of code, for minimal return.
  5. Some people would drop GNOME altogether if this were to be done. A lot of people don’t trust Microsoft or .NET, and by extension the Mono project.

I think .NET and Mono are great technologies, and I use .NET when I can. I have extended just enough trust to Microsoft to be willing to follow and work with Mono (hopefully on, as well), but that doesn’t mean that a lot of people are willing to do the same thing. Until Microsoft can prove that they aren’t a wolf in sheep’s clothing (which many Free Software people will probably never believe), basing a platform like GNOME on a technology so encumbered by Microsoft patents (regardless of ECMA standardization and Novell agreements), is dangerous and would be seen as highly alienating to a good number of users. It’s a risk not worth taking for GNOME at this time.

In short, I see far more disadvantages to attempting to convert GTK+ away from C, than advantages. I like .NET, I love Mono, but neither they, nor any other language provide any strong incentive to porting GNOME.

First GNOME Patch Accepted

Well, I got the e-mail today, that apparently my first Patch has been accepted into the Rhythmbox Project, making me a GNOME Contributor (finally). I’m glad to finally be doing some coding in something other than web programming for projects that I use regularly anyway. Unfortunately, the maintainer that applied my patch had a tweak a few things, but it was just an error message that wasn’t very clear and an small organizational issue, so I’m pretty happy with that.

Still, it was pretty exciting to get that e-mail.

Unfortunately, the changes made by the Maintainer who did the commit have made it more difficult for me to merge my development branch for this patch into the master branch on my local git repo. Fortunately, this means that it’s an ideal opportunity to learn how to handle conflict resolution in git.

GNOME Development

I decided that I need to be doing more programming, so I’ve begun going through the GNOME Bugzilla, and submitting patches for some Bugs I’m running across. So far, I’ve submitted two patches to Rhythmbox (the GNOME iTunes-like player), and am thinking about a few more.

I’ve also used the opportunity to learn git, by linking the Rhythmbox SVN into a local git repository. Git seems pretty cool, but I haven’t really had an opportunity to look at how it handles collisions, which frankly is going to be the most interesting part of git, in my opinion. Still, it’s branching is quite interesting, and I like that I can maintain version control in my local repo without messing with the GNOME SVN.