Josh Saddler

More hacking and progress made on Decibel; I've finished (for now) ironing out the dependencies. I dropped some USE flags in favor of the latest gst-plugins-meta, which already has the same flags. The updated ebuild is available here. I also uploaded a screenshot for the curious. (You can download the album itself here.)

I got in touch with Decibel upstream to let them know of my efforts to bring it to Gentoo, so they kindly linked back to my page on it.

Go on, try it out. So far it's only been tested on amd64 and x86. I want to hear back from folks using it on other architectures. If gtk+ and gstreamer are available for your arch, you should be able to run it.

The only thing thing Decibel doesn't do -- yet -- is display album covers. That's the only feature I want that I can think of.

It's simple, clean, and awesome, so try it. Lemme know what you think, and especially let me know if it runs on other architectures. PPC? Sparc? HPPA? Come one, come all.

Presenting a new(ish) package, never before seen in an ebuild: Decibel Audio Player.

Took me all night to write the ebuild from scratch and finish the documentation, but here it is. Report any problems with the ebuild by emailing me directly. Contact upstream if you have problems with Decibel itself.

Here are some screenshots. Go on, try it out!

I filed a bug to get Decibel into Portage, so follow along at bug 219329.

Kudos to the Decibel developers; they've created one slick app.

Well, my efforts to port Drivel to the newer gtk+ functions and away from deprecated libegg stuff aren't going well, despite my earlier hopes.

Spent a couple of hours tackling the issues mentioned in the libegg bug. Fortunately, two of them are moot: Drivel doesn't seem to use EggCellRendererKeys or EggAccelerator anymore. The EggRecent -> GtkRecent change seemed to be extremely widespread, so I instead took a stab at porting Drivel over to GtkStatusIcon, instead of the old EggTrayIcon stuff.

Not looking so good. I thought I'd switched over everything as per the documentation, but I got compile errors: libegg/eggtrayicon.c, line 79 or thereabouts. Apparently everything was being used for the first time without being declared somewhere? Oops. I went ahead and wiped the Portage tempfiles and all my work thus far. If I go back to it, I want to start fresh.

Part of the problem was that I just couldn't find any documentation on whether or not a given bit of old libegg code was present in gtk+, or what it was called. Another problem was there was libegg cruft all over the place. It's got its tentacles everywhere; I've no idea how to entirely clean it out. Can new gtk+ code be used with old, outdated libegg bits? Where's the documentation for it? Etc.

So even thought it looked like I'd correctly changed EggTrayIcon to GtkStatusIcon, moved all the egg_tray_icon_foo bits to gtk_status_icon_foo, and remembered to change *icon to *status_icon (and a few other things), it just wasn't enough. The compile process mostly seemed to choke on renamed gtk_status_foo_init lines. Maybe I should have left those as egg_whatever_init? I may never know.

It's my first real shot at trying to clean up code that isn't a markup language. Markup languages I know. Programming, not so much. It's educational all the same, I'm sure. Gosh, just think about how fun porting Drivel to GIO will be.

I still aim to continue improving Drivel for Gentoo users somehow.

Sometimes you swing, sometimes you miss.

What have I been doing lately?

Patching Drivel, that's what!

I like using Drivel. I never lose a blog entry with this thing, which is more than can be said when Planet Gentoo suddenly crashes when I'm submitting an entry. (Side note: are there any good graphical clients that work with b2evolution? I've yet to find anything in Portage.)

Even though Drivel upstream seems mostly dead, there are still patches to fix problems or add features floating around Bugzilla, so I've been grabbing them and testing, and if they check out, adding them to the ebuild I use in my local overlay.

So far, I've added patches & fixes to my ebuild that fix a memory leak, fix compiling with gtksourceview-2 (Thanks ecatmur! one fewer app that needs 1.x), update the Blogger login URL, and add tag support for LiveJournal. Upstream left a weird version in ltmain.sh; it was giving libtool version mismatch fits. Some judicious sed usage killed it. With extreme prejudice.

Anyway, Drivel's now much more usable. I haven't been through all the open bugs yet, but there's probably another patch or two that can be made presentable. One thing I discovered is that Drivel is using a few deprecated libraries and functions. It's got several deprecated uses of libegg (which has been replaced by equivalent functionality in gtk+), and it still relies on GnomeVFS.

Fortunately, the open bug for libegg has some info on porting to the appropriate gtk+ code, and there's also the guide to Migrating from GnomeVFS to GIO. I'm actually going to give it a shot. It's well documented, and it looks like it's nothing more than an long, intensive search-and-replace session. Right? Right? Guys? Guys?

Even if I fail utterly, well, it'll be fun to try it. Will follow up on this later.

In the meantime, you can get the updated Drivel ebuild and patches here. Just untar it in your ${PORTDIR_OVERLAY}/net-misc/ directory.

* * *

In other news, my new keyboard arrived in the mail a couple of days ago. It's much cleaner, slightly less resonant, and more interesting than the old keyboard. The Delete key got moved up near Backspace (what's the use in that?!?), so some judicious Xmodmap usage shoved the Insert key left, replacing Control_R, and I changed Ins to Del. I need my Del key right next to the arrowpad when working on documents.

The keyboard isn't as quiet as I'd hoped, but it's less squeaky than the old one, and it masses more, so it sponges up some of the resonance when hammering keys. Also, it's got 17 hotkeys, and every single one of them are correctly detected in Linux, no drivers needed (take that, included Windows XP driver CD!). More productivity, whoo!

Gnome's keyboard utility picked up the hotkeys and allowed me to assign them to various standard media key behaviors, but I chose to forgo that and use Xmodmap, since it works for both Gnome and Xfce. Xfce initially couldn't see the hotkeys, but it recognized them after I setup my /etc/X11/Xmodmap. Interestingly, Xfce correctly executes Xmodmap at login with no further setup needed, but Gnome doesn't. I had to go into the Sessions dialog and create an "Xmodmap" startup program entry.

This is weird, because GDM is supposed to execute any Xmodmaps found, whether in the user's home or systemwide in /etc/, and if it finds both, it's supposed to combine 'em. Poke around in /etc/X11, and you'll see that multiple files try to execute Xmodmap. However, GDM and Gnome have utterly failed here. They're weird like that sometimes.

$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
77 cd
69 ls
63 eix
46 gvim
38 cvs
36 su
27 less
26 exit
16 rm
15 grep

Yay for gvim. I'm surprised nano doesn't appear, though. Now that the meme's out of the way, on to the docs business.

For those of you on the bleeding edge, OpenRC and baselayout-2 are now ~arch. Before you even attempt to perform the update, read the OpenRC Migration Guide written by myself, Doug, and Roy. And then read it while updating. I run systems with stable keywords, so I'm not updating until the code and kinks have settled down some, and the packages are stabilized.

As part of the OpenRC documentation changes, I've replaced references to resolvconf-gentoo with openresolv, as the latter is maintained and stable for all arches. The former is dead and will be removed from Portage at some point.

Speaking of documentation, if you're interested in helping out with an up-and-coming documentation tool, take a look at Beacon, an XML editor. It's designed to be an easy way to create and edit documentation; this makes it easy for newcomers to contribute to Gentoo's GuideXML documentation. However, it does need some more work, so contact Anant if you're interested in making Beacon usable for the masses.

In hardware-related news, I just received my silent mouse from Quietmouse.com. This thing is silent. You can't hear the clicks, but it still feels like a normal mouse. No more annoying clicks during gaming or any other computer usage! The wheel is silent too at slow to medium scrolling speeds; it has a hushed whispery noise character during rapid scrolling. Faint, but not unpleasant. It's perfect if you're a silent computing enthusiast like me. The mouse works in Linux; no special configuration needed. Works well in gaming too; it's got a nice high scanning rate. It doesn't randomly freak out the way my old Dynex mouse does.

I've also got a new keyboard on the way from NCIX. My current one's not remotely quiet anymore, and it's pretty discolored after 3 years of use. Cheap silver plastic, go figure. I'm hoping the new one is much more quiet; it took awhile to find an identical layout to my current keyboard. The home/page/del keys are right where I want them.

Quiet keyboards are few and far between, so if the replacement keyboard doesn't work out, well, it's only $7. I wouldn't mind moving to the new slim Apple keyboards; I've heard they're decently quiet, as well as being rather sexy. Rather pricey, though, at $50.

I'd take cheaper and quieter over sexy and expensive, if it comes down to it. Must have scissor-key action, and it should preferably have a laptop-style layout. Any suggestions?

Another day, another release. Another handbook written.

I'm so happy I finished writing those things. Once 2008.0 final is released, the only change I know I'll have to make at this point is changing the release name from 2008.0_beta1 to 2008.0, and as others have mentioned, that change is easy to make. Keys in the TOC allow me to make conditional evaluations in each handbook. So in the XML source, if I write:

<p>
Stage3 tarballs can be downloaded from <keyval id="release-dir"/>
</p>

This will replace release-dir with the location of the release, as fetched from the corresponding key. So depending on the handbook you're reading, you'll see something like:

Stage3 tarballs can be downloaded from releases/amd64/2008.0_beta1/stages/

Simple, but oh-so-maintainable. I don't just use keys in the handbook TOC, but I also can add conditional evaluations that pull in paragraphs, sections, subsections, code blocks, you name it. These can also be from external files, too. That's one of the things I've been doing for this release -- finding duplicate content for all arches, and moving that text into a separate external file.

One example is the text that explains block devices. Each arch used to have similar text, sometimes slightly (or significantly!) different. I unified all arches -- put them on the same page, so to speak -- by creating an external include. I first pitched the includes proposal back in March 2007, and it's finally coming to fruition with the 2008.0 release.

By using the following tidbit:

<section>
<title>Introduction to Block Devices</title>

<subsection>
<include href="../hb-install-blockdevices.xml"/>
</subsection>

<subsection>
<title>Partitions</title>

I can drop the contents of hb-install-blockdevices.xml into place, providing the same descriptive text. If it ever needs changing, rather than having to change 16 handbooks, I can change just one, and all 16 will use it. This example is taken from a file in /handbook/2008.0/, so it refers to the included file one level up, in /handbook/. The included content doesn't even have to be in the same directory as the file using it!

I'll be implementing even more of these kinds of changes in the future. They increase maintainability, increase uniformity, and, more importantly, preserve my sanity when editing handbooks. And if I stay sane, I don't retire.