I don’t know about you, but printing 2 large blocks of solid black, for 22 pages, doesn’t sound like a wise investment of toner. But ah! Why don’t I just crop off the excess part of each page so that just the scanned-in text is visible, and print that out? This has to be easy, right?

Unfortunately it wasn’t as easy as I’d hoped (most of the picture editors that can even handle PDFs can’t print out each layer as a separate page, and there’s no way I’m doing the exact same operation 22 times). ImageMagick looked like the thing I needed, even if it would take some trial-and-error to figure out exactly how much to crop off.

Turned out it only took a couple of runs to figure out exactly how much I could get away with cropping. But I had a worse problem than having to do trial runs: The output looked horrible.

I tried reading the man page, going to the website, and the rest, and couldn’t figure out what to do. Using the -density option seemed to be the right idea, but alas I couldn’t get it to work.

I troubleshot further, even getting to the point of running gs manually to see if Ghostview or ImageMagick was the problem (turned out it was myself, I guess). Eventually I realized that Ghostview was rendering the initial image to ImageMagick at a low resolution (72 DPI) but viewing the source in Okular, it was obvious that much better was possible (I’d estimate 200 DPI although I ended up using 300). So if I could figure out how to get ImageMagick to pass the right DPI to Ghostview I should have the problem fixed.

More directed Google searching revealed I’d had the right flag the whole time, -density. I just had it in the wrong spot. Something like this is right: convert -density 300x300 input.pdf -crop ... output.pdf. Instead I’d been using convert input.pdf -density 300x300 -crop ... output.pdf.

I figured I’d put my experience out there in the great Internet Memory Machine in case others have similar troubles.

The attributes of some of the older systems like the NES and Super NES made it fairly easy to capture their music-producing software, since those systems used separate co-processors to handle music effects. NES music would be stored in the NSF format, and SNES music was handled with the SPC format (named after the audio chip used, the Sony SPC700). There were (and still are) specialized plugins on many systems to play these formats (they emulated only the music chip, not the rest of the system).

I’ve been involved on the periphery of some of these things for the past couple of years. (For instance I had written a KFileMetaInfo plugin for KDE 3, and had helped Chris Lee with adding playback support to GStreamer.

One problem with the previous GStreamer solution (which I’ll call gst-spc) is that the underlying playback library, libopenspc, is written in x86 assembly, and has some crash bugs associated with it as well. As well the code has long been orphaned. I’m not really any good at writing emulation code and although I could learn, it would take far too much time for me to do anything useful.

Luckily for me the state of the art has advanced and last year I was pointed to a library called game-music-emu. This library included a very good SPC emulator written in C++, which had been merged into some popular SNES emulators already. Unfortunately it didn’t really have a great build system (using it involved simply copying it into your existing program) so my initial proposal to port GStreamer to use game-music-emu by simply including the source files with GStreamer was rejected. The GStreamer devs preferred to have an external library which could be used (or not) and I couldn’t blame them since in general good OSS projects avoid copying or forking external code.

So I contacted the game-music-emu author (Blargg) asking about the possibility of adding support for building a library, and ended up with commit access and an invitation to do it myself. Hmm.

So I did, and awhile ago I had made a release of “libgme” 0.5.5, working with Blargg has he got free time. My subsequent patch to GStreamer was accepted and since gst-plugins-bad-0.10.14 it has been possible to use libgme to playback many emulated music file types (not just SNES, but others as well).

With that solved I left the issue, but I recently came back to it since I figured out that even after upgrading to gst-plugins-bad-0.10.17 the other day, that gstreamer playback was not using libgme, but the older libopenspc.

At first I thought it was simply my fault, as I’d still had gst-spc installed from years and years ago. Removing gst-spc and libopenspc (just to be double-sure) left me with no SPC playback features. Running gst-inspect confirmed I did not have any gme decoder. WTF.

I then again thought it was my fault because I had installed libgme to /usr/local instead of /usr. So I dutifully wrapped up libgme in an ebuild and installed it. And still nothing. WTF.

I dug into the Gentoo ebuild for gst-plugins-bad and it seems that for whatever reason not all possible plugins are installed. It seems the new installation method is supposed to be that each individual plugin is supposed to have its own ebuild (i.e. gst-plugins-gme), like how Gentoo has split out other packages like KDE into individual ebuilds. Fair enough.

I write another ebuild, and finally hit paydirt:

The Qt example music player playing SPC files

Obviously this does require that you are using the GStreamer backend for Phonon to have this work, otherwise you can just try it in some other GStreamer-using application. (I’d show it in JuK but I’d have to add SPC support to Taglib first)

If you’re interested in the ebuilds I used you can use this Portage overlay, (SHA-512 sum c0ff9aa5413b0c0b14f7c52d5b3ee887edc4e7bf47182e58c21e9c340d8ff7e9). The overlay may or may not work for you, and I don’t even know if overlays are still the “hip” way to do things in Gentoo, but It Works For Me. ;)

With that said, saying that you do not like desktop effects is not a good reason to avoid KDE 4. I happen to like desktop effects but I’m not using them, even though I’m in a KDE 4 desktop (due to a stupid problem somewhere in the driver toolchain). In fact I know for a fact, given that I recently tested it, that KDE 4 works just fine even in a Composite-less X11. So I forget what propaganda technique it is (straw man argument?) but in short that reason has absolutely nothing to do with KDE 4.

Really your whole rant could have been more concisely expressed without a single reason (as after all, you should be able to use whatever desktop environment you want) and you wouldn’t have people nitpicking your exact reasons that way. ;)

Specifically you may find the following entries by Miguel de Icaza relevant:

• iPad support for MonoTouch!
• iPad – Inspirational Hardware

I guess the iPad support for MonoTouch is OK if you’re into that sort of thing. It’s not as if I’d expect them to forego it given the past track record ;) But it does seem to me that as AMAZING as the iPad might be, that it would be better for consumers to have an open platform that anyone can extend instead of a closed platform that requires being part of a developer program to make your own additions. It would really pain me to think that in the future it might actually be required for people to get the permission of some mega-corp just to install a new program on hardware they’ve purchased.

What’s even funnier (in my opinion) is how Miguel goes on and on about how cool the iPad is because it will force people into one particular input mechanism (multi-touch) and how neat it is to coerce developers into developing for multi-touch. I mean shit, multi-touch is cool, I get it, I like it even, but we’re happy about removing other perfectly good input options?

Look at Nintendo, even when they added motion control to Wii and started hyping it up, they still allowed for other standard input controls (such as in Super Smash Bros. Brawl, which can be controlled using Wii remote, Gamecube controller, or even a Classic Controller). Of course Apple does allow for a physical hardware keyboard with the iPad I guess, not that it changes the crux of Miguel’s point.

However, if you read the article critically a couple of times and apply a couple of blur filters to the hyperbole (“tyranny of the mouse and keyboard”? seriously?) then the rest of his points do make sense. It really is easier to develop for a single platform, and there really is research to be done in this space. (Perhaps ironically, a hacker displayed initial multi-touch support in Eye of Gnome in the article just below Miguel’s squee-fest).

What concerns me is that the kinds of applications that do perform better with a keyboard or mouse might get left by the wayside. I’ve played Bejeweled with a mouse and on the iPhone, and it was much easier with a mouse (and a similar game called Tetris Attack was much easier still with a controller). And that’s just one example. The point should be that the universe is expanding, but it seems to me that Miguel is simply moving wholesale to the next cool “One More Thing…”.

In all fairness it does seem that I’m not the only one interested in the ramifications to Free Software and software freedom (which sounds kind of Three Musketeer-ish in retrospect).

While I’m trolling, it just feels weird to me to have a Windows 7 screenshot as the major feature addition to a new presumably-GNOME-related software release. Don’t get me wrong, I don’t personally think there’s any reason not to port software to Windows platforms (and indeed, there’s a nice KDE platform on Windows now), but it does seem… disconcerting, I guess? I do agree that the idea of Jump Lists is nice though, probably wouldn’t require much more than some additions to the Desktop File Entry spec to make happen in XDG-ish Free desktops either, no?

As my final act of trolling (this post is already 624 words long by now!) I’d like to point out that if you act quickly, you can catch Stormy Peters’s GNOME Foundation goals for 2010 before it scrolls off the Planet GNOME frontpage. The summary seems very manager-speakish to me. I find the “thought leader” term immensely amusing, as it is one of the few MBA kind of terms that have not been co-opted by Naval leadership (I’ve seen a full O-6 Captain refer to sailors as “his customers” and about puked… but that’s a different story). I had in fact not heard of thought leader (except for 1984) until this post.

Beyond that there’s a lot of goals relating to ensuring corporate participation is acceptable, ensuring there is a marketing plan that involves “the community in close cooperation with our partners”, a goal to measure the benefit to the bottom line, ensure the GNOME Foundation is the place where GNOME-related companies collaborate, etc. On the other hand, one of the last sub-goals is to “Promote free software by being a model example of a free software project” (capitalization is hers, not mine).

Now again, at first glance it seems weird to me to see a document on the front page of a major Free Software project’s blog aggregator pasted with so many terms relating to working with companies for this and that. I mean, sure KDE works with companies, but not like this (my humble opinion, not necessarily shared by anyone else in KDE). But if you think about it critically then it’s apparent that at the end Free Software is not going to “save the day” just working from the great untamed wild of the uncorporate. Servers need paid for, the most motivated hackers will still need to eat and pay for Internet/computers, and the vast majority of people buy systems and software (if only the support package), so if Free Software is going to make massive inroads, it will be with the help of quite a few companies.

I’m still not sure I like the specific set of goals (and specifically the awful MBA jargon) but you can’t blame the GNOME Foundation for putting down in words what they’re going to be doing one way or another anyways.

A Konversation developer, argonel, noticed the issue the other day and got in touch with me, so I had him strace the output of the (successful) manual run and the (unsuccessful) kdesvn-build run. It wasn’t initially super helpful although it clarified what was going on (the gitorious.org end of the connect was closed on their end for some reason).

That was the conclusion of that, but then I get an email the next day from argonel saying that he’d done more digging, and that it was a known issue which could be worked around by adding the -v flag to git, which forces progress output to be displayed even if the output is redirected. (The issue has something to do with kdesvn-build redirecting the git output, if you run the git command manually but redirect its stdout to a file then you’ll see the clone fail after about 30 seconds as well).

This progress output makes the logged output look really bad, however, so the workaround I ended up implementing in kdesvn-build is to show the progress output on the terminal and redirect the rest (you may actually prefer this as it’s possible to see the progress of the checkout now).

In short, the Great kdesvn-build Git Clone Bug should be fixed. Please test the trunk version of kdesvn-build for me to make sure I got it though!

Specifically:

• Fix multiple subdir log filename breakage
• Make global set-envs apply to every module (regression)
• Generate log/latest/build-status again
• Allow source-dir to be changed per module

In other good news, the documentation styling improvements I was pondering a couple weeks ago were added in time to make 4.4. Speaking of documentation, Burkhard Lück noticed that the /trunk documentation for kdesvn-build was significantly out-of-date compared to the kdesvn-build.kde.org ones (since I did not commit during the freeze), and got the updated docs imported. (And he might be able to backport them for 4.4.1 as well)

Finally if you’re as big a fan of the man and info kioslaves as I am you may have noticed that URLs of the form man:foo (or info:foo, etc.) don’t work in KRunner in the release candidate or betas (bug 221371). I think I have a fix for that which I’ll try to get in before the 4.4 tagging, but if that doesn’t happen then you can workaround by using man:/foo or info:/foo URLs until then.

The year was shaping up extravagantly 12 months ago. We were expecting our second baby soon. My ship had just come off a spectacular (for SSBNs) patrol, and had won the squadron Battle “E” and even the Omaha Trophy. I was due to rotate to a nice shore duty soon.

In my volunteer efforts, KDE 4.2 was shaping up to be a fantastic release of the KDE Plasma Desktop and associated platform software. I was even going to get to visit my family in the upcoming 2009 summer and reconnect with a lot of people I hadn’t had a chance to see in awhile.

As it stands though, 2009 has been a massive heartbreak. Good riddance to a horrible year. Here’s hoping 2010 can’t get any worse.

Changelog is basically this:

1. Documentation is improved.
2. The script itself is less craptacular.

Happy Holidays, Merry Christmas, etc. etc. I’ll be on duty tomorrow :-(

I’ve been going over the kdesvn-build documentation recently since there were several major changes to kdesvn-build in version 1.10 which I didn’t bother to document.

I’d only scratched the surface of the changes when I got fed up with the output that you get by default with our documentation generators (which is not meant as offense, just the way it is).

So, I took a detour and tried to duplicate my output-finessing feats that I had earlier performed on kio_man, kio_info, and kio_perldoc.

To see what I’m talking about first, consider the following:

• Open up KHelpCenter and look at one of the installed documentation pages. (The specific one doesn’t matter, I’m just referring to styling).
• Now look at the output of running meinproc4 with the kde-web.xsl XSLT stylesheet. (meinproc4 is the tool that KDE uses to convert the DocBook XML source to the output HTML). The kde-chunk-online.xsl output is similar. Remember that logo? :)
• The docs.kde.org output is looking a bit better, but still out of date.
• Finally, the kdesvn-build website has my current results at this time.

Now I am neither an artist nor a web designer but I do think that the output is starting to look better. (The content itself is still mostly out of date but I’ve at least updated the command line options and configuration options tables).

So now my question is, is this something I should work on trying to integrate back (at least for KHelpCenter stylesheets, since that output looks broken to me in the header)? I think our “spit and polish” on our user-interfacing documentation could go a lot way toward making the documentation more pleasant to use. And better yet we are outputting specifically for one of the most advanced HTML engines in the world so there’s no reason for us not to use every useful feature if it makes the output nicer, no?

Oh, I changed the git checkout/update procedure a week or so ago in trunk, if you’re not testing it I would appreciate it if you could test so I can do the next release this upcoming week without me being the only one to use it. ;)

But this last one was so bad that it nearly should have resulted in news coverage, a Federal disaster area being declared, cleanup crews in the HAZMAT suits, etc. YUCK.

Token KDE reference for pk.o: I’m working on improving kdesvn-build docs, more on that later.