Present Perfect

 Just spent an hour trying to figure out why Ctrl-] in my gnome-terminal zooms the window instead of sending a telnet escape character. I was connected with a xen console and wanted to detach so I could reattach from home later.

I still don't have it figured out, and I'm still not sure it's gnome-terminal, GNOME itself, or something else.

xev correctly lists the key being pressed as rightbracket. Zoom mode is bound to Ctrl-+, which on my current US keyboard is shared with the = key. So, in gnome-terminal, Ctrl-] behaves the same as Ctrl-=

In Firefox, Ctrl-] does not zoom, and Ctrl-= does zoom.

Now, when I remap gnome-terminal's Zoom out to Ctrl-= (and not Ctrl-+, which while on the same key is a different symbol), then Ctrl-] *does* work as expected. Confused yet ?

This can only be a special casing in gnome-terminal afaict. Anyone know for sure before I start digging through gnome-terminal code again ?

As an aside, I can apparently use Ctrl-5 instead... This is according to the Xen wiki and that seems to work for me.

I will save my complaints about Xen for some other day :)

UPDATE:  People have commnented on the GTK+ "bug" at the heart of this.  Yes, I have two layouts defined: an English one, and a Spanish one.  This is because I switched keyboards last week.  No, none of them are Dvorak.  I find the bug report baffling - an argument is being made in favour of Hebrew/Russian/... languages but nobody seems to explain exactly what the problem is.  I have no idea what a Russian keyboard looks like and why it is impossible to type certain things on it.

 Just spent an hour trying to figure out why Ctrl-] in my gnome-terminal zooms the window instead of sending a telnet escape character. I was connected with a xen console...

My venerable T40 (which has small pieces of plastic coming off of it at an alarming rate) was having a few keyboard issues lately.  Some of the keys' lettering has worn off, which is not that big of a deal.  But some keys don't actually work all of the time, causing me to type a lot of errors.  And sometimes on boot some keys just aren't working.  Given that these keys often include h and m, two letters that are part of my login name, this is a little annoying.

A while ago I ordered a new keyboard on EBay, and foolishly decided to have it delivered to Peter's house in Belgium, because I was going to spend ten days there over Christmas.  Of course, it is probably no surprise to anyone that the delivery with US Postal Mail took a lot longer than the 7 planned days, and it arrived long after I had left Belgium again.

This weekend I finally went past Peter's to go and collect it.  I was going to wait until I was back in BCN to install it, but this weekend my laptop failed to have working m and h keys six reboots in a row, so I decided to install it straight away.  And it's definitely an improvement.

Living here in Barcelona I have come to realize even more than before that the layout differences between French/Belgian and US are range from understandable to completely silly.  Exchanging Q/W for A/Z makes no sense to me at all.  Putting the numbers to be used with shift is only very vaguely understandable, and mostly annoying just because it is different.  The Spanish one is not that much better, but at least it has Q and W right.  For programming, both are frustrating (having to use alt for square brackets and parentheses).

So I have decided some time ago that for me personally, the One True Keyboard from now on will be US/International.  So that's the keyboard I ordered for my laptop, and when I was in the States I also got a wireless keyboard with this layout.

Funnily enough, while I'm a good typist and I manage just fine switching between French and English/Spanish, having my laptop in English and the desktop in Spanish is breaking my muscle memory.  The most baffling difference: ( and ) are above 9 and 0 on the English one, and above 8 and 9 on the Spanish one..  I hope someone up there is enjoying this.

So tomorrow I will bring my English one to work and from that point on I hope to have US/International rock my world.

(Apparently I am not alone thinking the keyboard situation is silly - Julien, my boss, apparently also always uses US, even though he remains a real French man).

My venerable T40 (which has small pieces of plastic coming off of it at an alarming rate) was having a few keyboard issues lately.  Some of the keys' lettering has...

We sometimes get some mails on why a plug-in from our webshop doesn't work. The number one reason is the person in question has glibc 2.3.

Some people think we are cruel unjust people for building against glibc 2.4. I just wanted to take a moment to explain the reality so you can decide for yourself how cruel we really are.

Since it's Christian doing builds and me setting up the infrastructure for him to do builds in, we do the builds on Fedora systems. We are both Fedora users. In our office we are pretty much alone; the majority uses Ubuntu. We use Fedora on our platform, and I've developed a build tool over the years that makes it very easy to build in a clean chroot to make sure no unwanted dependencies creep into the build.

We build in a Fedora Core 5 chroot because it was the first one to ship with GStreamer 0.10. It just so happens that FC5 was the first Fedora release to ship with glibc 2.4. At the time where we decided what glibc we wanted to support, we took a look at the major distributions out there, checked if they had glibc 2.4, and decided that they did. I think Ubuntu's Dapper was still on 2.3, but there's Edgy and Feisty now, so that sounded good to us. When it came to Debian, we somehow assumed that their next release would not be obsolete at the time of release by shipping glibc 2.3.

Well, seems we were wrong. Etch has not been released yet, and already it has been decided that it will not ship with glibc 2.4. It is no wonder that Debian lost so many users to Ubuntu (Incidentally, is it a coincidence that "Etch" is very similar to "Edgy" ?)

Personally we wouldn't want to make our webshop even more confusing by listing what glibc a plugin is built against, and building against both glibc's. Building in FC4 could possibly be less than ideal - some of the features that GStreamer plug-ins can support (like QoS, reverse playback, ...) are decided at compile-time based on the presence of headers, and I'm not sure we will still bother about building GStreamer on FC4 for much longer, because in practice it's all just extra work for Christian and me.

Are we evil that we don't take more hours out of our day to build on glibc 2.3 ? You bet, we are cold heartless bastards. But in reality 90% of the people on glibc 2.3 are users that have an upgrade path to a more recent version of their distro; the other people are future Debian Etch users. I'm sure the Etch releasers have convinced themselves of the usefulness of not releasing with a glibc 2.4 that is more than 15 months old, and instead opt for an even older series, even before they actually release. But I am starting to wonder more and more who the people are that are waiting for a release like this.
Realistically speaking, it is possible that we may add glibc 2.3 plugins in the future if we see that more than just Debian is affected. We are not against taking your money for giving you a service that works. But the hours in our day are just as scarce as they are in yours. I just wanted to explain this to people that want to know, to take away your incentive to complain about a nameless faceless Company being Evil to you.

We sometimes get some mails on why a plug-in from our webshop doesn't work. The number one reason is the person in question has glibc 2.3. Some people think we...

... is when for the first time in a month you manage to go home before 9 so you can go to the supermarket and buy stuff like bread and fruit and they're all out of the stuff you wanted.

... is when you are looking for GStreamer bugs and you run longrunning pipelines to minimize the guesstimation errors, and suddenly the runtime goes from 2 minutes to 20 minutes because you added audioresample (which is still doing about two function calls for each sample it processes)

... is when you are trying to put everything aside at work to nail a bug and get back on with your actual work life, and getting the wind knocked out of your sails by the negativity of the person you're fixing the bug for.

... is when for the first time in a month you manage to go home before 9 so you can go to the supermarket and buy stuff like bread and...

Found a nice WTF in some external code. As part of some deal we received some proprietary code for a proprietary codec format. I obviously cannot divulge with, or share the actual code. I can paraphrase though.

I was running a simple encoding test and the test segfaulted. GDB showed me that it segfaulted on a line that looks a little like this:

somepointer[-1] = 0; //assuming some extra memery is there to consume

(somepointer was renamed to protect the guilty party).

Looking higher up in the function, somepointer is being assigned as this:

guint16* somepointer = someencoder->coefpointer;

And coefpointer is just a pointer stored inside the encoder structure to some data somewhere.

So, what happens if coefpointer is pointing to the first guint16 inside the memory structure ? My guess is the assumption being made in the comment ends up wrong.

The rest of the code doesn't actually write to the "-1" location, except at the very end, where it does

someencoder->coefpointer[-1] = out

(with out being a counter of coefficients written).

This same operation is repeated all over the code, poking 0's in random memory locations. I'm surprised this doesn't trigger more often.

Found a nice WTF in some external code. As part of some deal we received some proprietary code for a proprietary codec format. I obviously cannot divulge with, or share...