A quick update on the gedit clang integration. Here is a screenshot of the latest visualization of errors in source code:
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).
Just a quick update of what I’m currently working on:
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.
A while ago I managed to buy an iPad. I am using/planned to use it for various things. One of those things was to be able to remotely control my music player (which is nice when sitting outside on the terrace, having a small party etc.). The ‘Remote’ application that exists to control iTunes works really well, however I don’t really use iTunes. So I thought I would have a look on how to do something similar with Rhythmbox (or Banshee for that matter). I remembered something about DLNA and uPNP and tried for some days to get this to work, but I really got nothing. I don’t know which side is to blame, but in the end I gave up trying to make it work.
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 wanted to write a little post on what it means for application developers to try to get ready for GNOME 3.0. Many people might already realize what I try to outline here, but I think it’s still good to show. This will be specifically about gedit (naturally), but I think it will apply to any applications trying to survive in the storm that is GNOME 3.0.
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:
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…
Recently I wanted to use gstreamer to add some very basic audio support to an application. I just used the playbin element to play audio files and added some logic to control volume (easy enough with playbin since you can just set it directly) and looping a sound N number of times (which is also easy enough, since you can just watch EOS on the pipeline, seek to the beginning and play again).
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.
I saw some posts on pgo recently on cycling, so I thought it would be a good occasion to do the monthly or so blog. Cycling is something very natural where I come from (which is flatland), but since it’s literally flat everywhere there is not that much to it. For instance, I used to have a bike with no gears, and you break by peddling backwards. This is not really the case where I live now (which is Switzerland, Lausanne). So, in order to get a bit into shape (and loose some kg’s) I started to do some more cycling here, mostly short trips of 2 hours max, but with quite a bit of climbing (at least for me :)) which is nice!
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!
Dear all,
I’m looking for a nice piece of software that will assist me in my recently revitalized guitar playing activities. What I would like is really just a tool for my convenience in playing along with songs that I like. Therefore I’m looking for the following features:
As you can see. It’s really not that much. In addition, the following I would consider a bonus:
Anyone knows about some open source project that has at least the 5 features listed at the top?
With the latest release (0.0.6) just out the door I think it’s about time to write a little post about one of my pet projects, gitg. I guess most people will think ‘argh, not yet another git GUI’, but hear me out :)
I was trying to understand git, but found the initial transition (as many other people) a bit hard. So, I thought what better way to learn, then to write a gui client. Born was gitg 0.0.1. The purpose of the project was to provide a GitX like application, targeted at GNOME. It had to be fast, nice looking and generally useful (as you can see in the left screenshot, it loaded the linux repository of 20.000+ commits in under a second).
 gitg showing the linux repository |
 gitg commit view |
The latest version which has just been released has quite some features already, including:
In any case, if you want to give it a spin, it’s a vailable in the latest debian and ubuntu (I don’t know about other distributions), but the version is a bit outdated. For the latest and greatest:
| Download: | ftp://ftp.gnome.org/pub/GNOME/sources/gitg/0.0/gitg-0.0.6.tar.bz2 |
| File a bug: | https://bugzilla.gnome.org/browse.cgi?product=gitg |
| Get it from git: | git://git.gnome.org/gitg |
After some more hacking we have most of the functionality ready for real collaborative editing in gedit. Here is me and Armin collaborating (me with gedit and Armin with gobby, sorry, interface in Dutch):
In contrast to my previous post, this version now properly handles its sessions, does error handling etc. The only thing that is really missing right now is undo/redo, which is tightly coupled to GtkSourceView at the moment in gedit. We would need to make the undo handling less specific to use infinote undo/redo for shared documents.
When all of this more or less works, the next step will be to use telepathy tubes to allow sharing documents directly with one or more of your contacts. The idea is that you can offer a collaboration session to your contacts. gedit will then internally run an infinote daemon, offering a virtual document store made up of the open documents in the gedit window. All the necessary components are there, so it should be fairly straightforward to do.
Just finished a big chunk of a new gedit plugin which uses the excellent infinote library (gobby, libinfinity) to do collaborative editing. Being pretty tired, I’ll keep this post short, but be sure to get an update on the plugin’s progress soon :)
Credit goes to the rocking infinote API and Armin from gobby fame, where all the hard work is done. The code plugin is currently hosted on github, but we will most likely move it to gedit-plugins once it matures. If you want to try it out, be sure to fetch the libinfinity 0.4 stable branch from git (there were a few API additions and small bug fixes to make it work with gedit).
