Hands on with ebuilds: Abiword 2.7
Note: this post was originally written a few weeks ago, shortly after the Siag Office experiment. Since the draft was written, an Abiword bug has been opened with a different ebuild. Guess I was too slow about finishing up my draft and publishing it. Ah, well. Now you can at least track the progress of the latest Abiword.
After the lengthy but fun entry on working with Siag Office, I've got s'more goodies. It's time to remove more Gnome packages, as I want to have as close to a pure Xfce desktop as possible. Abiword has always been my default word processor, but it has always been burdened with Gnome libraries and other dependencies. The 2.7 development series changes that, removing the need for many Gnome packages.
After reading a comment, I decided to hack up an ebuild for Abiword 2.7.1, the latest developmental release. This is not a stable release; the changes made to the 2.7 series will eventually become the stable 2.8 series. As upstream warns, don't run developmental releases on production servers.
The first step was to copy the latest ebuild, 2.6.8, to my local overlay in /usr/local/portage and renaming it to 2.7.1. The next step was to determine what's changed since 2.6.8.
I took a look through Abiword's ViewVC to see for myself whether or not the pesky Gnome dependencies have been removed or made optional. Seems they have.
I also discovered that there are several totally unnecessary dependencies present in our current ebuilds. Moreover, several configure switches have been renamed from --enable to --with. This means changing the $(use_enable) bits to $(use_with). Also, some switch options have been renamed or removed; there's no more gnomeui or symbol switches, and the printing switch was renamed to print. These were all simple, quick changes to make in the 2.7.1 ebuild. Removing a line here, deleting 3 letters there. Basic stuff.
Another change was getting rid of the xml and expat configure switches, since they're no longer used. While Abiword does use expat, it's already pulled in by libgsf, so we're safe there. Even the internal Abiword documentation notes this in the various configure files, which is why they don't have explicit configure switches any longer.
The longer changes involved studying configure.in to see what it says are the new optional dependencies and adding those as new USE flags within the ebuild. goffice is now optional, and requires an updated version (0.6). So I added an "office" flag to IUSE at the top of the ebuild, and a line to the pkg_setup function:
$(use_with office goffice)
This USE flag can always be renamed later. The important thing is getting the initial functionality in place. It's very easy to add new flags into the Abiword ebuild; it really just requires copying and adjusting the existing USE info.
Once the critical dependencies and versions were sorted out, it was time to update the internals of the ebuild itself.
One of the things that tends to happen when you have a package in the tree for a long time is that cruft from old ebuild versions tends to linger around for a few years. In this case, the ebuild has a few EAPI-1 tidbits like SLOT dependencies, but it also has a lot of leftover baggage from the pre-EAPI days. Part of that includes redundant numbering. There were a lot of specific minimum versions that are completely unnecessary, as the minimum version hasn't existed for a long, long time. So I went through the ebuild and stripped out all the unnecessary versions, leaving just the category/packagename.
Only one package now needs a specific minimum version, gtk+-2.14. Once gtk+-2.12 is removed, then the dependency can be simplified to a SLOT dependency on gtk+:2, to avoid pulling in gtk+-1.x. I did the same SLOT update for the new required version of goffice and for glib-2. All part of the process of updating to the good stuff present in the EAPIs.
With the EAPI-2 update, it's possible to include USE dependencies in ebuilds. This means that you can get rid of hacks like built_with_use, which require a dependency of Abiword (such as Pango) to have been built with the X flag. The whole function to abort the merge if Pango was not built with USE="X" took 4 lines:
if ! built_with_use --missing true x11-libs/pango X; then
eerror "You must rebuild x11-libs/pango with USE='X'"
die "You must rebuild x11-libs/pango with USE='X'"
fi
With EAPI-2, I was able to update the ebuild to this RDEPEND:
x11-libs/pango[X]
Pretty slick, huh?
The next step was to try a test-compile. Run emerge abiword and watch the results.
Hmm, the merge aborts right at the very end. Turns out that the sed scripts carried over from the 2.6.8 ebuild aren't working: they die because the files they worked with no longer exist. Time to figure out where that .desktop file and other stuff have gone.
The first sed script is looking to change some install directories in a nonexistent Makefile. A quick grep through the Makefiles shows that the old change is no longer necessary; nothing has the old incorrect path. This sed script can be commented out.
The second sed script wants to alter the lines in the .desktop file Abiword installs. However, Portage can't find the file to sed, so it aborts the merge. Turns out that Abiword wants to install the file to /usr/share/abiword-2.7/applications/abiword.desktop. That is a nonstandard location, so no wonder Portage can't find it. If it installs here, Abiword won't show up in your desktop menu. The trick is to get Abiword to install its .desktop file to the right location.
Let's review what's happened so far:
1. Create a copy of the latest ebuild to work on.
2. Visit the upstream homepage and changelogs.
3. View the various configure files to determine new dependencies, versions, unnecessary dependencies, optional dependencies, renamed arguments, and the like.
4. Go to work on the ebuild!
a) Hammer out the raw dependency changes.
b) Fix up the USE flags and related functions.
c) Fix up version and SLOT stuff.
5. Give it a test run.
a) Since a couple of minor errors were found, revisit the ebuild. Fix sed scripts.
b) Test it again.
Now Abiword is compiling, installing, and running. The next step is to tidy up the ebuild. This means putting the dependencies and USE flags back into alphabetical order, removing extraneous whitespace, fixing typos present in the original 2.6.8 ebuild, and deleting any unnecessary comments. There's also the small matter of getting the .desktop file to install to the right location . . . call it homework. 
The final step (for me) is to upload the ebuild where you can view it. This ebuild is a working template for the 2.8 releases. I plan to keep tracking it, keeping up with the changes. No more forced Gnome dependencies! Yay!
Of course, I was only able to remove two packages: goffice and libgnomeprintui. Something is still pulling in libgnomecups, libgnomeprint, gnome-keyring, gnome-vfs, and several others. The next thing I'll investigate is all the gtk+ Bluetooth apps lying around. I won't rest in my quest to have a totally lightweight, Gnome-free, Xfce laptop.
* * *
This is a follow-up to my Siag Office experiment:
I've discovered that some of Siag's peripheral programs run in spite of the font errors. xedplus, tsiag, gvu, and xfiler all run. They still display the same font errors in the console output, but at least the application itself works. Though I'm not sure that xfiler is working correctly. It pops up a file browser window, but I can't click on an item to open it. I can select it with the mouse, but to open it I have to hit Enter. Annoying. But at least it does go to that folder, or open the document/picture in the appropriate Siag utility.
I still can't get the word processor or spreadsheet working, and those form the core of Siag Office. Any tips?
Hands on with ebuilds: resurrecting Siag Office
I was poking through the contents of my world file and USE flags the other day, trying to trim down the number of Gnome dependencies present on my Xfce laptop. Abiword is the application that requires all the Gnome stuff. If only it didn't need deprecated libraries like libgnomeprint, the rest of the Gnome desktop wouldn't get pulled in.
So, I started looking around at alternative word processors and office suites. There's always OpenOffice, but I don't really like using something as slow and bloated as OOo even at the best of times. There are some other office packages available, but they're for Qt/KDE. Or they're made of something really icky, like Java. 
And then I found it: Siag Office. This office suite dates back a number of years. It used to be present in Gentoo, actually, but was removed five years ago.
I took a look at the upstream homepage; it still seems to be sporadically developed. Last release was in 2006. I poked around in the documentation, INSTALL, READMEs, and whatnot in the upstream CVS to get a better feel for what's required. Siag mostly relies on little-used X libraries, including old-school Athena widgets and their derivatives. It also has its own expanded widget kit, Mowitz. Siag ain't pretty, though at least it looks better than Motif-based apps. Most importantly, it's reputed to be very fast, needing very few dependencies.
The Portage CVS attic contained outdated ebuilds; the latest Siag release is 3.6.1, and the latest Mowitz release is .3.1. I used the outdated ebuilds as a foundation for creating my own ebuilds. And that's when the trouble, I mean fun, really began.
For starters, the old ebuilds had a lot of cruft leftover from the pre-modular X days. Stuff like virtual/x11, deprecated configure/make functions, unnecessary USE flags . . . even some bad configure switches from when the code did odd things, like --host=${CHOST}. These obvious mistakes required fixing. Then I checked the Getting Siag page to get more of an idea of the current dependencies.
Siag-3.6.1 has build dependencies on gmp, Mowitz, tcl, libXpm, and libXaw. It has optional runtime dependencies for Python, ccmath, and netpbm. The dependency on libXaw may be interchangeable with other Athena widget-compatible libraries. I sent an email upstream to verify this, as comments in the source code give the impression that while Xaw can be used, so can XawM (a variant created by the Siag folks), Xaw3d, and possibly even neXtaw. In my email, I asked specifically about neXtaw, as Mowitz relies on neXtaw. I figure it's best to just use one widget set if possible to give a more unified appearance. Perhaps neXtaw can be used as a drop-in replacement?
Anyway, once the dependencies were updated for the Siag ebuild, it was time to redo the configure/install section. This is actually still a work in progress; I haven't taken the time to really nail down the optional dependencies, add final USE flags, etc. I've been trying to get working ebuilds, not perfect ebuilds. Not yet.
Once the Siag ebuild was working, I moved on to the Mowitz ebuild. This required many of the same fixes that Siag did. The biggest headache, though, was trying to get the Xaw dependency hammered out.
The old version used to be able to use a number of Xaw varieties, same as Siag. However, the latest version seemed to have narrowed it down to either Xaw3d or neXtaw, default is neXtaw. The configure switch --with-xaw3d= should allow for either one, right? The source code comments in the INSTALL file say the same thing. Unfortunately, it doesn't hold up in reality. If neXtaw is not installed, the configure phase will fail, saying it can't find the Xaw implementation (aka neXtaw). I spent an hour throwing Xaw3d and Xaw name/path variants at it before giving in. How ironic that the --with-xaw3d= switch can't actually use Xaw3d. So I let it just run with the default neXtaw, updating the ebuild for this build dependency. Worked just fine. Good thing that neXtaw was never taken out of the Portage tree! The neXtaw ebuild, at least, is up to date.
In my email to the upstream maintainer, I mentioned that the configure and/or documentation is incorrect. Hopefully I'll get a response, but it has been a few years since the code was touched upstream.
Now that I'd hammered out the dependencies for Siag and its two required dependencies (Mowitz and neXtaw), it was time to merge the package. The sourcecode for Siag itself is only abou 1.5MB. That's right, a whole integrated office suite, with word processor, spreadsheet, animation app, file manager, text editor, and previewer . . . less than 2MB. That's quite an accomplishment! Only took a few minutes to compile.
I discovered that Siag is so old that it seems to predate the common .desktop files used to display an application in your program menu, or at least upstream hasn't bundled any. I'll have to write up my own .desktop entries and add in the accompanying installation function into the ebuilds. So I had to use the command line to launch 'em. That's when the biggest issue hit: Siag won't run.
None of the binaries installed can actually run; I have hit upon a rather famous error that dates back to 1998 or so, and has popped up here and there in the intervening decade:
$ siag
Warning: Cannot convert string "-*-helvetica-medium-r-*-*-12-*-*-*-*-*-iso8859-*" to type FontStruct
Warning: Missing charsets in String to FontSet conversion
Panic: can't load any fonts!
I'm not entirely positive what causes this; Google searching has widely disparate bug reports. It's probably something to do with the way pre-modular X did font handling. Siag seems to want to do stuff in certain ways that the old monolithic X did. It may be able to compile against more modern libraries, but whatever it wants to do is too old-school. There's probably some leftover cruft hardcoded somewhere. I just haven't found what, yet.
At least I can see the errors when running the main applications like siag and pw. The animation app, egon, won't even show that much. Just as in the linux.com review, egon simply would not run:
$ egon
Segmentation fault
I'm unable to perform any further diagnosis. I don't have any debug libraries or applications installed on the laptop, and at this point I'm not going to waste any more time on just this one application.
I'll still try to get the rest of Siag running -- there are a few solutions for the runtime font failure, but none of them have worked for me so far. I have not yet given up; I'm still trying to find ways to slim down my laptop, get rid of Gnome dependencies, and lighten up my Xfce environment.
I've put my work-in-progress ebuilds in my devspace. Once again, I should remind you that the Siag ebuild in particular is not yet finished. It'll do the most important things--compile and install Siag--but it's not finished. If you're looking to cut your teeth on some simple ebuild tasks, you're welcome to spend some time in our Gentoo Development Manual and send me a patch. Working with ebuilds really isn't intimidating the way it may appear at first. Mostly, the work just requires time to sort through issues as they turn up. Time, not arcane knowledge of the most secretive inner workings of code.
Also, if you've got any potential solutions to the font startup failure, I'd love to hear from you! This is the last remaining barrier that I know of to getting Siag working. Well, that and setting up Siag to print, as it doesn't have a graphical interface. Instead, Siag needs you to tell it the proper CUPS commandline stuff. Which, again, is just a bit more time and reading the manpage for lpr. Time and reading. That's most of the process. Time, effort, and persistence.
I'm hoping it'll pay off for Siag Office.
Desktops, etc.
Man, it's been awhile since I blogged. I meant to keep putting up a monthly Xfce desktop, share some tips, talk about the latest Gentoo work, etc. And then real life got in the way.
Laptop
I killed yet another piece of hardware when updating my Thinkpad R61i on Friday. I've been sick this whole week, so I had some free time. The laptop hadn't been updated since early February, so there were 176 packages, including the big move to GCC 4.3, which necessitated a system rebuild. Unfortunately, I left the battery in while the system was on AC power for the compiling work. I guess the heat must have built up too much, because the battery got fried. Got the dreaded "battery light flashes amber rapidly" error. So now I only have the extended-life battery, which is heavier and bulkier.
Add that to the list of hardware that compiling Gentoo has killed over the years. The list includes another battery, an external power brick, an internal PSU, two motherboards, two RAM sticks, one RAM slot, two hard drives, and a fan. I'm really on a roll, here.
I still can't find a replacement battery for less than $90, even on eBay, so I may hold off. What I did do was order two more gigs of RAM, to bring the total up to 4GB. Only cost $40 at Amazon, free shipping. Why the RAM? While updating, I ran into the dreaded OOM-killer! The GCC 4.3 compile uses more than the 2GB available and it aborted the merge. This was with nothing else running, too. So be warned: if GCC dies when you move to 4.3, back off on your MAKEOPTS. I had to adjust mine from -j3 to -j2 while compiling GCC and glibc.
Also, while I was updating my whole system, I decided to move the rest of my X/kernel stack to ~arch, as I wanted the new Intel KMS/GEM/UXA hotness. This necessitated using ~arch xf86-video-intel and Mesa, as well as ~arch gentoo-sources, as 2.6.29 has some needed code not present in 2.6.28. I discovered that while this part of the graphical stack was just fine for KMS and fast graphical login, xorg-server-1.5.3 resulted in hard lockups as soon as I opened any windows. I had to grab xorg-server-1.6, libXfont, and randrproto from the X11 overlay in order to get a usable environment. It works great! No more lockups.
So, how much of an improvement is the new stack over what was available in February? I'll let the following numbers speak for themselves. These are the median-high numbers recorded. For the old stack, the numbers varied from 48FPS to 59FPS. For the new stack, from 489FPS to 504FPS. Sync to vblank and vsync have never been enabled.
xorg-server-1.5.3-r1, libdrm-2.4.4, xf86-video-intel-2.6.1, mesa-7.3, gentoo-sources-2.6.27-r8
$ glxgears Failed to initialize GEM. Falling back to classic. 292 frames in 5.0 seconds = 58.272 FPS
xorg-server-1.6, libdrm-2.4.6, xf86-video-intel-2.6.3-r1, mesa-7.4, gentoo-sources-2.6.29-r1
$ glxgears 2516 frames in 5.0 seconds = 503.174 FPS
Now, the usual caveat about glxgears not being a good benchmarking tool applies here. However, it is useful for relative comparison from one version to the next. And as you can see, it's an order of magnitude better. I notice that stuff is drawn much smoother; there's less flickering especially when shifting Terminal windows around. And I haven't hardly begun to tweak my system for best UXA performance. KMS is nice and smooth; it happens pretty quick in the boot process. No more flickering, just fast loading of SLiM and then Xfce.
My xorg.conf is pretty minimal; the only changes I've specified for the Intel driver section are these:
Option "FramebufferCompression" "false" Option "AccelMethod" "UXA" Option "Tiling" "false" Option "EnablePageFlip" "true"
There are probably some other things I should add for maximum performance, so I'll have to spend several more days hunting for 'em. But out-of-the-box, I'm extremely impressed with the current X stack.
Now all I need is smooth full-screen Flash video performance . . .
Xfce 4.6
The other thing I put on the laptop was Xfce 4.6.1. Decided that as long as my core graphics stack is part ~arch, it wouldn't hurt to try out the latest and greatest Xfce hotness. Now that some outstanding bugs were fixed from 4.6.0 (including a remote security bug, and an icons issue), I thought it'd be worth it. It's pretty slick. The desktop environment is initialized a bit faster than even a fully tweaked 4.4.3.
About the only outstanding issue I have with it is that there is no graphical menu editor. At first, I couldn't get a satisfactory menu even editing the XML file by hand; it was just too different from the old one. So my menu was cluttered with useless toplevel entries, such as Web Browser, File Manager, and so on. Fortunately, Mike pointed me to the solution, so now all offending stuff has been cleared out. Right now my menu works just fine, so I only really need a graphical menu editor for convenience's sake.
I really like 4.6 a lot. The artwork packaged with it is outstanding; I'm using one of the stock backgrounds because it's just that sexy.
Xfce 4.6 is a smash hit, so well done, guys. Very well done. And there's even more good stuff planned for the future. There's a great interview on Planet Xfce with one of the core developers. He discusses some of the exciting stuff coming down the pipe for Thunar, so make sure to read it.
Gentoo
I've been rather quiet on the Gentoo front for the last three months, because life in the outside world has a way of unexpectedly intruding on me. I've been on devaway since February while I try to get stuff into some semblance of order. Sadly, however, I've had to do much more documentation work than I originally scheduled, which keeps cutting into my plans for other areas. I've made a bunch of bugfixes and commits over the last couple of weeks especially. One of the most visible changes is in the Get Gentoo page, putting the automated weekly builds at the top. The handbooks will be updated, too, but they require a tremendous overhaul, so I'll need all the resources of my fellow GDP members to accomplish that. If I can get 'em, that is.
One of the other things I like to do is find some interesting little-known application, determine its usefulness, then hack up an ebuild for it. It's really good practice, actually.
Out of all the applications I've written and updated ebuilds for, the only one that's got me stumped is WordGrinder. I've been in contact with WordGrinder's upstream author, who's a really helpful guy, but I still can't get the ebuild working. While compiling and installing by hand works great, something happens during the compile phase as run by Portage where it violates the sandbox, killing the merge.
Plus, given the pmfile used by the package, it doesn't really respect a user's CFLAGS/CHOST and related configuration. That has to be altered somehow, so I've been trying to work out a similar solution to the one used by our dev-lang/lua ebuilds. No real luck there, but it's not my first priority. What I really want to do is have the merge workin' with Portage. So it's an interesting, informative, occasionally frustrating learning process.
Anyway, take a look at all the stuff in there. I recently reorganized the ebuilds by category/package, instead of dumping everything into a single directory. Some of these have since moved into Portage sometime after I wrote the ebuild for 'em, and some (like Songbird and WordGrinder) are works in progress. I've run into quite a few nifty apps; places like GnomeFiles are excellent resources. Most of the stuff in here I discovered on GnomeFiles, and a lot of the packages on the website are simple enough that it's just a few minutes' work to hack up an ebuild.
Minimal word processors
I've just discovered two very interesting minimal word processors. They're designed by writers, for writers. They aim to get out of the way and let you just write, with no distractions.
PyRoom
First is PyRoom, which relies only on pygtk. It's really quite minimal and not distracting in the slightest, and easily themeable. I like it a lot. I created an ebuild, available here. Thank goodness for distutils!
WordGrinder
Second is WordGrinder, an even more minimal application that's entirely console-based. Unfortunately, it uses some weird freaky build system called PrimeMover, and it's scary. I asked one of my fellow developers who maintains the Lua package about it, but he's never heard of it. There aren't any eclasses for dealing with any Lua build system.
According to WordGrinder's Readme, the PrimeMover setup should be pretty simple. However, take a look at the pmfile itself. Man, that's ugly. It looks like three hours of judicious sed usage within the ebuild. I can't see any other way to alter it to something sanely installable to /usr.
If anyone has any tips, I'm all ears. I've got a skeleton ebuild for WordGrinder available in my repository, but it really needs fleshing out. So, who's willing to help?
Hardware: graphics shuffle redux
In other news, I had a really fun time getting my ATI X1950 Pro to work (again) with a silent aftermarket cooler (AC Accelero v1 rev2) and the latest bleeding-edge radeon, mesa, and libdrm packages. The hardware mods were fun, but the software . . . well, that's a long story for next time.
Desktop
Oh yes, and this month's Xfce desktop. Token uncluttered version here. All those artists in that Thunar window are amazing. You should be listening to them right now.
icons: Meliae-dust (needed something reddish)
gtk+: Rezlooks L & D
xfwm4: Rezlooks-gtk (yes, it is confusingly named)
background: The Empire (from pixelgirlpresents)
Benchmarks: gtk+ engines
Here are some fast and dirty benchmarks of various gtk+ engines installed on my system, using app-benchmarks/gtkperf-0.40.
Notes on the hardware:
CPU: Athlon 64 X2 4600+
Graphics: nVidia 7600GT, DVI 1440x900 @ 60Hz
RAM: 4GB DDR2-667
Mobo: ASUS M3N78-VM
Notes on the testing environment:
OS: Gentoo Linux (duh)
Kernel: Linux 2.6.27-gentoo-r2 #3 SMP PREEMPT x86_64
nvidia-drivers: 177.82
CFLAGS: -march=athlon64 -O2 -msse3 -fomit-frame-pointer
DE: Xfce 4.4.3
- Xfwm4 with Composite enabled, effects: drop shadows & transparency
- Open applications: 1 instance each of www-client/mozilla-firefox, app-editors/gvim, xfce-extra/terminal
- Cairo: 1.6.4, compiled with glitz support. Not all engines use Cairo, but those that do should benefit from a small speed increase.
The gtk+ engines are all available in Portage. If you're not on Gentoo, look in your distribution's repositories or check here. Custom themes are noted with *. These are personal themes I've made, nothing more than simple color modifications of an existing freely available theme. No additional images are used, so rendering time should not be affected.
All tests were conducted 3 times, using a Test Round setting of 100. I picked the best score of the 3, as I was looking for best-case usage conditions. The results are ranked in order from fastest to slowest.
Engine: Mist
Theme: Mist
GtkEntry - time: 0.01
GtkComboBox - time: 0.53
GtkComboBoxEntry - time: 0.47
GtkSpinButton - time: 0.09
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.13
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.24
GtkTextView - Add text - time: 0.28
GtkTextView - Scroll - time: 0.13
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.16
---
Total time: 3.07
Engine: Xfce
Theme: Xfce
GtkEntry - time: 0.03
GtkComboBox - time: 1.12
GtkComboBoxEntry - time: 0.50
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.04
GtkToggleButton - time: 0.14
GtkCheckButton - time: 0.07
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.27
GtkTextView - Scroll - time: 0.17
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.16
---
Total time: 3.56
Engine: Rezlooks
Theme: Blue Ink*
GtkEntry - time: 0.07
GtkComboBox - time: 0.95
GtkComboBoxEntry - time: 0.65
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.28
GtkCheckButton - time: 0.28
GtkRadioButton - time: 0.39
GtkTextView - Add text - time: 0.34
GtkTextView - Scroll - time: 0.15
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 4.31
Engine: Industrial
Theme: Industrial
GtkEntry - time: 0.08
GtkComboBox - time: 1.52
GtkComboBoxEntry - time: 1.04
GtkSpinButton - time: 0.12
GtkProgressBar - time: 0.05
GtkToggleButton - time: 0.59
GtkCheckButton - time: 0.35
GtkRadioButton - time: 0.39
GtkTextView - Add text - time: 0.39
GtkTextView - Scroll - time: 0.21
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.28
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 5.86
Engine: Glider
Theme: Glider
GtkEntry - time: 0.04
GtkComboBox - time: 1.93
GtkComboBoxEntry - time: 1.62
GtkSpinButton - time: 0.42
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.25
GtkCheckButton - time: 0.19
GtkRadioButton - time: 0.32
GtkTextView - Add text - time: 0.37
GtkTextView - Scroll - time: 0.29
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 6.59
Engine: Pixmap
Theme: Elegant Autumn*
GtkEntry - time: 0.09
GtkComboBox - time: 1.64
GtkComboBoxEntry - time: 1.34
GtkSpinButton - time: 0.24
GtkProgressBar - time: 0.17
GtkToggleButton - time: 0.52
GtkCheckButton - time: 0.48
GtkRadioButton - time: 0.89
GtkTextView - Add text - time: 0.69
GtkTextView - Scroll - time: 0.22
GtkDrawingArea - Lines - time: 0.26
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.28
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 7.37
Engine: Clearlooks
Theme: Glossy
GtkEntry - time: 0.08
GtkComboBox - time: 1.93
GtkComboBoxEntry - time: 1.45
GtkSpinButton - time: 0.40
GtkProgressBar - time: 0.29
GtkToggleButton - time: 0.61
GtkCheckButton - time: 0.50
GtkRadioButton - time: 0.59
GtkTextView - Add text - time: 0.41
GtkTextView - Scroll - time: 0.32
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.18
---
Total time: 7.68
Engine: Candido
Theme: Graphite Light
GtkEntry - time: 0.08
GtkComboBox - time: 2.10
GtkComboBoxEntry - time: 1.86
GtkSpinButton - time: 0.17
GtkProgressBar - time: 0.26
GtkToggleButton - time: 0.63
GtkCheckButton - time: 0.53
GtkRadioButton - time: 0.60
GtkTextView - Add text - time: 0.48
GtkTextView - Scroll - time: 0.25
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 8.05
Engine: Aurora
Theme: Aurora
GtkEntry - time: 0.47
GtkComboBox - time: 3.78
GtkComboBoxEntry - time: 3.50
GtkSpinButton - time: 0.96
GtkProgressBar - time: 0.31
GtkToggleButton - time: 1.53
GtkCheckButton - time: 1.29
GtkRadioButton - time: 1.66
GtkTextView - Add text - time: 0.58
GtkTextView - Scroll - time: 0.46
GtkDrawingArea - Lines - time: 0.31
GtkDrawingArea - Circles - time: 0.38
GtkDrawingArea - Text - time: 0.32
GtkDrawingArea - Pixbufs - time: 0.19
---
Total time: 15.73
As you can see, the older engines are generally the fastest, with the more modern Rezlooks engine coming in close behind. Though they're generally not as attractive, the old Mist and Xfce engines turn in very respectable rendering times. The Pixmap engine actually doesn't score too well, coming in at the lower middle of the pack. This is despite many reports I found via Google that suggest it's one of the best-performing engines out there. Not so much; it's about average.
But by far the worst performing engine is Aurora. Now, to be fair, Aurora does many graphical tricks the other engines do not. It came along some time after old engines like Pixmap, Industrial, Mist, and Glider. It features animated scrollbars, gauges, and many possible styles of dropdowns and arrows. In short, it's fully loaded. Yet it also doesn't seem to be optimized; at 15.73 seconds, it's almost twice as slow as the nearest contender, Candido.
The results for the Aurora engine were so dismal that I re-ran gtkperf another 3 rounds, thinking something was amiss. Every result turned in times between 15 and 16 seconds. Clearly, Aurora isn't the engine to use if you're on old hardware.
Conclusion:
Remember, these are down and dirty benchmarks. Cherry-picking the best time out of 3 runs may not be the most fair way of measurement, but since no single result varied more than 2 seconds either way, it can be considered pretty well representative of the engine's overall capabilities.
If you're on less capable hardware, the Mist and Xfce engines will go far. If you want something prettier, stick with Rezlooks. I have several screenshots of Rezlooks-based environments in my devspace. It's quite flexible, and it's still in the top three fastest engines, despite including goodies like subtly animated progress bars and gauges.
But even on my fairly powerful workstation, newer engines like Candido and Aurora were noticeably slower, suggesting they might not be a good fit for older hardware. Clearlooks and Pixmap are middle-of-the-road choices; neither has much of an advantage. It comes down to which engine you think has prettier themes.
Me? I stick with Rezlooks. And occasionally Clearlooks (the Glossy theme makes for a good wintry desktop foundation), and very occasionally I'll find a decent Pixmap theme that's worth modding for my system. Otherwise, it's Rezlooks all the way.
A very minimal desktop
I discovered a really nifty trick the other day, one that makes for a pleasant work environment and that fills the need for a launch area of some kind. It basically eliminates the need for iDesk, too.
While you may be aware that Xfce can draw the usual home, trash, and volume folders directly on the desktop, it can also do things with the icons on the desktop. Like . . . use them as application launchers.
Open up a browser, and drag a .desktop entry from /usr/share/applications onto the desktop. Presto, there's your application launcher. Much larger than the usual miniscule panel icon sizes, too. The downside is that you can't drag items directly from your Xfce menu, but as long as you know where they come from, you can add any launcher you want. A bit of tinkering results in the following:
Who needs a panel, when the desktop launchers, right-click desktop menu, and keyboard commands work just fine? Unless you really need one, of course. It's almost like the ever-popular spartan Openbox + iDesk combination. Xfce distilled to its finest essence. Thank goodness for flexibility.
More docs, apps, and tweaks
Over a month since my last entry. Anyway.
The Work
I've been busy churning out the August issue of the Gentoo Monthly Newsletter, as well as a GMN Howto. This is a guide that details the process for creating the GMN, from start to finish. Over the last couple of months, it's gone from a simple 15-line cheat sheet to something a lot more useful for future GMN staff and any interested contributors.
A fair amount of documentation updates for the GDP, too. I was curiously unmotivated most of the month of August, though that's in part because of my health; I spent the first bit of it in the emergency room trying to figure out why my insides were coming apart. Still no idea.
And I've updated my devspace. Lots of changes. Lots of new stuff added and rearranged; I expect I broke some old links, but oh well. All that stuff in misc/ really needed organization.
I also poked aballier to get the new version of Decibel into the tree. Oh yeah. Upgrade to 0.11; it adds album cover art, among other things.
The Apps and the Machine
I've also been hacking up various ebuilds for packages not yet in the tree, such as tint2. This is all for my laptop, which I'm trying to slim down even more. Been removing various applications and making it much more of a minimal Xfce environment. Plus, I like pseudo-transparency. Apps like stalonetray, tint2 (ebuild available here), netwmpager, dzen2, and conky are all curiously appealing. I'm trying to find lightweight, useful, complementary apps to Xfce, in my perpetual quest to create the perfect Xfce environment.
I discovered many of these applications by reading urukrama's blog and kmandla's blog. Both are excellent sources of information on small, light apps, and setting up clean, minimal, functional environments. Quite tasty; be sure to give 'em a read. Especially urukrama's Openbox guide. It's loaded with configuration info, application tips, and much more.
The Environment
I've replaced most of my Xfce panel with stalonetray, conky, and a couple of instances of tint. I just installed dzen, and will be investigating it as a possible replacement for conky. Dzen, however, seems to need a lot of initial time-consuming configuration. And it doesn't seem to do transparency. And it doesn't look like it can even do useful fonts like Verdana.
What I'd really like to do is get rid of all but the start button on the panel, but first I need to find an icon launcher bar that does pseudo-transparency. Why not real transparency? Because compositing with the Intel X3100 graphics chip doesn't seem to be too friendly on my battery life. Actually, I'd be happy if tint had launcher capability now; I hear it's going to be in a future release. I'll just use it when that time comes.
Here's my current desktop: 1 and 2. I've managed to find a nice-looking level of transparency regardless of light or dark background, so everything's fairly clear. Too bad conky can't provide transparency and shade, similar to everything else. That left-hand panel will be going shortly; all I really need are the launchers and the start menu button. Must find a way to slim it down; it takes up too much space. Plus I don't care for vertical panel arrangements.
Since folks are always curious about what's what in any given screenshot:
Left to right: Xfce panel, stalonetray, tint, conky, and tint (just date/time). The wicd applet is anchored in the tray, and a few terminals and gtk+ apps are open in tint.
Background: (1) Liquid Crystal, (2) VSE Grass Flow.
Screen: 14.1", resolution of 1280x800. I notice that when viewing it on my 19" 1440x900 desktop monitor, the fonts look extra-large. Well, they're much smaller on the laptop. The laptop resolution is so high that I have to enlarge things considerably; my eyes aren't what they used to be.
Drivel and Keyboard
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. Fortunately, Xfce saves the day yet again.
SCALE, ebuilds, burning apps, and gtk
SCALE
It's been a coupla weeks now since SCALE 6x, so it's about time for an after-action report.
My wife and I arrived Friday night after suffering a two-hour delay because of heavy traffic. The 405 was the worst. LA traffic always gives me nightmares.
Saturday morning came far too early, but at least we were already registered. We got there the same time as omp, who'd brought a Windows-using friend along as a booth slave--er, volunteer.
Our booth setup included a giant Gentoo poster, omp's desktop rig, and one (occasionally both) of my laptops, displaying Xfce. It was more popular than the extremely minimal openbox desktop, so HAH! We gave out lots of bribes--snacks--and even more LiveCDs. It's too bad we didn't have flyers, business cards, shirts, or other Gentoo swag this year. Lots of folks were asking for them. At least we gave out snacks'n'luv.
Wireless internet sucked throughout the weekend. Apparently it was the same for everyone. Spotty, minuscule bandwidth, and nameservers couldn't be reached. Made it hard to demo things that needed internet access, such as emerging packages, looking up our homepage, or highlighting documentation.
One of our users, calculus, was around much of the time to help out; was nice to see him at SCALE again this year. And wormo made an incognito appearance, too. To all the users and everyone else who stopped by and asked questions, gave feedback, or just chatted -- thank you. You're terrific. I'm always excited to meet a Gentoo user in person. It's like "Really? you use Gentoo? No way!" We were possibly the least-known distro there (tied with Foresight and Damn Small Linux?), certainly the least commercial one. The other distros were all heavyweights: Ubuntu, Red Hat, Suse, Fedora, etc.
Still, we had lots of traffic. Several people wanted to know what's up with Gentoo in regards to our recent legal status issues, so I provided the news in-person, and that seemed to go over well. Curiously, none of the enterprise-level folks were much interested in our legal status. They pretty much all said the same thing: "We're not worried. All the technical development is still there; nothing's changing." It was only the individual users who had all kinds of worries and needed the explanation. The corporate sector wasn't worried at all: "As long as it's still being developed."
There are plenty of pictures of our booth around the 'net in reviews and photo sites; you just have to look for 'em.
I had a blast at SCALE. I plan to attend next year, too.
ebuilds
Lately I've been poking random ebuilds from the tree, posting updates to Bugzilla, creating new local ebuilds, asking for keywords/stabling, and so on. It's a lot of fun. A fair amount of edgy experimentation, but that's what my new laptop is for. Things like wicd that I'd like to see in the tree, or the latest version of brasero.
burning apps
Speaking of burning software . . . brasero seems to be the only actively developed gtk+-based application. Everything else hasn't had a release in years. Xfburn, gnomebaker, graveman, xcdroast....you name it. That's not good news. Brasero is a good choice for my Gnome desktop workstation, but I wouldn't even think of putting Gnome on my laptop, which is a pure Xfce machine. And yet I hate the idea of putting K3B on my laptop even more, because of the ugly, ugly Qt and kdelibs dependencies.
I went ahead and installed brasero on my laptop anyway, since it's gtk+, and it can work with DVDs. None of the other apps I mentioned support 'em. That added 33 huge Gnome deps, including (ugh) nautilus. The irony? K3B only wanted 18 total packages. Still, it's uglier. That's what counts, right?
So thinking about this sad state of affairs for gtk+-based burning apps got me thinking . . . what would it take to create a new one? Something fast, with minimal dependencies, and gtk-based.
gtk
I've skimmed the gtk tutorial and the reference manual before, but only as a passing curiosity. Today I really took a shot at figuring 'em out. This is where I ran into the cliff known as "C programming."
I'm not a programmer. I can do markup languages, I can do some bash, some javascript, little things like that. But I've never been trained in OOP. Or any kind of programming, except some BASIC in elementary school and college. My degree is in theatre, not computer science!
Still, I'm determined to make what headway I can with these gtk+ guides. I've started to see what does what, and why. And some of the necessary parts of an app. Now I need to find out how to get that button press to do something, like . . . burn a CD. Copy a disc. Save an iso. And so on. For that, I've been poking at the source code for Xfburn, libburn, and brasero. This is all still just a bit over my head, but I'm trying, at least.
I've already partly answered my own question of "Why aren't there more up-to-date gtk+ burning apps available?" because I created a sample task list.
Writing a graphical app is a huge undertaking. What burning backend will be used? cdrtools, cdrkit, libburn/libisofs, dvd+rwtools are all possibilities. Same goes for the media types used in writing audio discs. The app has to handle notification (possibly via dbus), disc drive status/detection, set/get write speed, and a dozen other critical tasks. Oh, and it needs to be translatable (those pesky .po files that take up space), and it really should make use of autotools. What other libraries will it use? Will any of its features be optional compile-time switches? Got to add those too. Where will the project be hosted? What VCS? And so on.
Lots of stuff to do. No wonder brasero's the only active gtk+ burning app. And that's too bad, too. It has a ton of dependencies that folks using Xfce or just a WM don't care to install. I'd like to see the huge gap between "brasero" and "nothing" filled by a low-dependency, fast, capable application. I just don't think I'm up to the task of creating it all by myself. 
Thinkpad Configuration, part 2
Right, I'm almost done setting up the Thinkpad.
The keyboard is still taking some getting used to -- I hate having the Fn at the far left, where the Ctrl key should be, and I hate not having the Del/Home/End keys vertically aligned with the right edge of the keyboard. I also keep forgetting I have a working middle mouse button for Firefox. Too used to having to Ctrl-click tabs on the Toshiba. And . . . I love the scroll function on the synaptics touchpad. Love it. The pad itself I don't use much; I'm too used to trackpointers. Plus it's too easy to turn a drag motion into a sudden click. I do like the IBM trackpoint more than my Toshiba; the IBM one is more accurate and has a nicer surface.
Fingerprint use: for the time being, I've uninstalled fprint, and installed thinkfinger instead. Why the switch? Because thinkfinger works out-of-the-box with SLiM, and pam_fprint doesn't work with it at all. If it worked with SLiM, I'd switch back. Also, thinkfinger's enrollment seems to work better. I'm getting far fewer rejected scans. I'd like to file a feature request bug with fprint upstream to get SLiM supported, but its bugtracker mails aren't getting through to my devmail. dsd, you reading this?
I still haven't bothered playing with hdaps yet or finding out why it thinks my disk is unsupported. While on the subject of disks, it occurs to me that I really should have created a /usr/portage partition and formatted it as ReiserFS. ext3 is just too slow for Portage ops.
I at least solved my networking issues by adding a couple of required modules and undoing parallel startup. I also fixed a typo in conf.d/net. I don't plan on using NetworkManager any time soon, as it requires lots of Gnome dependencies. For now, I added a second network block to wpa_supplicant.conf:
network={
key_mgmt=NONE
priority=-9999999
}
I haven't tested it yet, but I think this should work for unsecured public access points. Actually, I think this was probably in wpa_supplicant.conf before I deleted everything and added my own config.
My desktop and development environment are just about complete; got my keys imported and my firewall setup and everything. Still haven't setup my system for Bluetooth or audio production yet. Or games.
As promised, I've made my working kernel config available. For all you Intel X3100 users, this may be of use in setting up uvesafb. Also, if you've got an IPW3945 ABG network card, this may be useful if you're using the in-kernel iwl driver. I've enabled the appropriate statistics options to use powerTOP, which is a very nice way to monitor power usage. I get about 2.8 hours doing basic wireless internet, docs work, etc. with my screen almost at full brightness. Not bad. I think I waited too long to get an Ultrabay battery; SCALE 6x is less than a week away!
Speaking of SCALE, I'm going. So I should probably get tickets & registration for me and my wife, yeah? Oh, and a hotel reservation. My new laptop has been such a distraction.
I've discovered a really unusual bug/behavior. I removed alsasound from the boot runlevel, in case I'm running on battery. Now, unless you blacklist them, your sound modules will still get loaded regardless, taking that much more power (even with aggressive soundcard power management enabled.) So what I had been doing was starting and stopping the ALSA initscript once my desktop was loaded. Here's the bug:
Starting and stopping ALSA this way actually kills all GTK theming in Xfce. The decorations revert to GTK defaults, the window colors go to their GTK defaults, the panel becomes ugly, you name it. All I have to do to re-apply the default (pretty) Xfce GTK theme is open one of Xfce's configuration utilities. Any of them. Isn't that bizarre? I have no idea why the hell that happens. Every time I stop ALSA. It's a minor nuisance, I guess.
On thinkpad_acpi and hotkeys:
It's a known bug that the brightness hotkeys don't work, but echoing values directly to /proc does. There won't be a fix for this any time soon, either. I've been in contact with upstream, submitting reports to their database, etc. Still have to go through and test the rest of my hardware (Bluetooth, etc.) and submit another report, but the outlook is not favorable for hotkeys. I still need to find a good program that will recognize the Fn-Home/Fn-End key command for brightness adjustments. xbacklight works, but I need keybinds to call it. Xfce has a built in keybind program, but it can't see Fn key combos. I'll have to find a sane xbindkeys setup (or similar app); there's probably something on ThinkWiki or the Gentoo Forums.
Signing off for now . . . maybe I'll see ya'll at SCALE? Come on by the Gentoo booth! Devs, users, groupies, etc. are all welcome.