Improvements

With respect to the previous release (apart from having all the 3.2 goodness), the integration with OS X has been improved. For example, we now ship binaries for Tiger, Leopard and Snow Leopard, integrated native apple spell checking, fixed issues with translations and fixed various issues with keybindings and the global menu (which annoyed a lot of people in 2.32 using different keyboard layouts).

After installing gedit and launching it, you should see something like the following:

Integration

As you can see, we have spent some effort (just as previously) to integrate gedit in OS X natively. Most of this effort is not spent by gedit, but by a small group of people doing amazing work on the quartz backend of gtk+ and on mac application integration (yes, that’s you John Ralls). I really want to thank everyone spending a lot of effort to integrate gtk+ (quartz backend) and GNOME applications (mac integration) into OS X. Without these guys a gedit port for OS X would simply not exist.

Build process

Whereas gedit for OS X was previously built by me in mixed environment of jhbuild and custom checkouts with various patches (pushed into github), this time I decided to handle things more properly and integrate the whole build process in the gedit tree as a jhbuild moduleset and accompanying patches. This also solves the issue with the previous binary for which we did not strictly adhere to the GPL, in the sense that it was almost impossible to recreate the binaries from source. This time, you can simply follow the instructions in the osx/README file and everything should be built for you the same way I built it on my machine. This meant I started basicly from scratch, which is also why it took quite some time to get everything working as expected.

Porting applications

I think that gedit is a great application showing how you can port an application using a lot of GNOME/freedesktop technologies to another platform (hopefully we will have a 3.2 for windows soon too, poke nacho ). gedit uses dbus, libpeas (gobject-introspection), plugins (C and python), printing and more. All of this works (or at least should work ) on OS X, and we are getting more native with each release. If you are interested in porting your application to OS X, please feel free to have a look on how we do it for gedit.

Bugs

I expected a series of bugs and releases for gedit 3.2.6. On the one hand a lot of software has seen a lot of development, none of which were tested on platforms like OS X (or windows). On the other hand, I’m still expecting some issues resulting from building binaries on one machine for different distributions. For example, the first release was quite a disaster, crashing on launch due to some issues with iconv and a set of hard coded paths (which worked on my machine, but obviously not on others ). Anyway, I would like to invite anyone running OS X to try and install gedit 3.2.6 and report any issues in gnome bugzilla!

Don’t expect it to be very stable. It should work, but it is currently still somewhat prone to crash. Since it is written in vala (thus C) this unfortunately means that it will crash gedit as well. So use on your own risk . For those running fedora 16, packages will be available soon.

I will try to work on this on and off if I find the time, feel free to pitch in though!

Note: This is a rant…

gedit clang plugin

You can checkout the code on github for now: https://github.com/jessevdk/gedit-code-assistance. If you want to try it out, install the gedit-devel (>= 3), llvm and llvm-devel (>= 2.8) packages and compile the plugin (see the README for more information).

That’s right, that’s clang integrated in gedit (with the very nice libclang). For now only error reporting is implemented but libclang will also gives us the AST (allowing fancy stuff like static analysis, referencing, symbol browsing, etc.). In addition, there will be auto completion in the near future.

You can’t test this, you can’t find the code yet anywhere, this is just to tease you.

Then I thought it might work just as well through a webinterface, why not. I looked for a suitable plugin for rhythmbox, but unfortunately most of the 3rd party plugins are not ported yet to 3.0. Since I thought it would be fun and a nice opportunity to employ some of that shiny, new and hip css3/javascript/jquery/ajax/websocket, I made a plugin for RB to do just what I want.

It features all the basic things that I want from a remote control. It will show you a list of playlists/sources, followed by a list of artists (for the selected source) and finally a list of songs for the selected artists sorted by album. You get the basic controls to play/pause, skip songs, repeat/shuffle and control volume. In addition, you can also set the current selection as the current playlist. Finally you can also simply queue some songs (those blackish boxes at the bottom of the screenshot) which will be played as soon as the current song ends playing (this is all just rhythmbox functionality exposed and nothing new).

There are some fancy (useful) animations in the UI and in general I kind of like the look of it. I wouldn’t call myself a “designer”, so if anyone wants to jump in and improve some css, please feel free. The plugin is hosted on github:

http://github.com/jessevdk/telemote

Note: You can save your breath preaching about how Apple is evil etc, I’ve heard it all before…

I have been developing for gedit since around 2006 (this is 2.14). I would not say I’m the most active developer at all times, but the fact is that gedit is almost solely being developed by volunteers (we see little to none contributions from financed developers). This is of course true for many open source projects. gedit seems like a simple enough little application, but it’s still quite extensive.

Our normal development cycles are relatively uneventful. We introduce a small set of new features, fix some bugs, etc. We also always try to ensure that current HEAD of development is “stable”. This means that I have always used current HEAD in a production environment, that’s right, production! This means it gets a lot of testing, because it is the application I work with most every day. We are not usually early adopters of new technologies, which helps this level of stability.

This changed with GNOME 3.0. We decided we would try to adopt to the changes as early as possible, so that in the end we actually have gedit ready to be shipped. This meant however, amongst other things, the following:

• A lot of work to port from “old” technologies (gconf – gsettings, pygtk – pygi)
• Half of the time I’m just trying to get jhbuild to work again
• gedit is continuously broken due to API changes or broken dependencies
• No real testing because it’s unusable in a production environment
• Regressions are almost inevitable
• No real change for end users!

Now, I of course understand also the advantages of trying to get this to work, but it has been largely demotivating for our little team. To illustrate a bit the impact of this, I had git crunch some numbers on our development cycles.

On this plot you can see the sum of all added and removed lines (excluding translations) over all commits in a particular development cycle. As you can see, we have seen a significant increase of activity in this cycle. Of course, not all of this can be attributed to GNOME 3.0, but there is an undeniable effect. If we zoom in to the last two development cycles, we can see who the person is that we really need to thank:

That’s right, Ignacio is clearly our hero! Anyway, I just want to point out that this cycle has been particularly hard for application developers, especially those that try to adopt early so that they are actually ready by the time GNOME 3.0 lands. And then to think, for the end user, there will be basicly no change at all…

P.S. Note that if you apply a simple COCOMO to this (you take an “organic” type of project, for 80 KLOC (which is probably an overestimation, but still)), you get some 20 months of volunteered work done by a team of 12 for this cycle… wow…

There was however one thing that I wanted to implement that left me a bit puzzled. I wanted to control the volume of each channel of an audio file independently. The why is not really important. My first thought was to use the “volume” element. It implements the GstMixer interface, which supposedly could be used to control independently the volume of each of the channels. Easy enough, right? Wrong… Even though the volume element implements the mixer interface, it does not actually implement the part where you can control the volume of each of the audio channels. If you look at the mixer track, you just see one channel.

So what can you do? It turns out that what you need to do is to take your audio, deinterleave the multichannel audio into single multiple mono channels. Then to put a volume element of each of those mono channels and finally to interleave those channels again. Even though this is maybe still relatively simple, it took me quite some time to figure it out. Anyway, here is the pipeline that would do this:

gst-launch-0.10 -v filesrc location=audio.wav name=src ! decodebin ! deinterleave keep-positions=true name=d interleave name=i ! autoaudiosink d.src0 ! queue ! volume volume=0.5 ! i.sink1 d.src1 ! queue ! volume volume=1 ! i.sink2

This would play the file “audio.wav” with the left channel at 0.5 and the right channel at 1. Note that I had to put keep-positions to true on the deinterleave element (although I don’t know exactly why, it seems to have something to do with the pulsesink element: #657457.

Since I’m a gstreamer newbie, please let me know if there is something I misunderstood about all of this, or if there is a better way to do what I want.

Today I decided I was up for something more, so I went from Lausanne to Geneva and back, which totals at around 120 to 130 km (give or take, the route on the map is not exactly how I went and I didn’t track GPS and also don’t have a km counter) in 6 hours. I must admit that the last 30 or so kilometers where pretty hard on me (since I’m really just a beginner) and I also did it with a mountain bike (I’ll hopefully have a racing bike soon). Anyway, my legs are burning quite nicely. More cycling!

View Larger Map