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, how large the fonts look. 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.
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.
Xfce and Choice
Since my last entry, a several important things happened. A number of users and developers chose to engage in a flamewar on the mailing lists. A few developers chose to leave. Many chose to just ignore the problems and focus on their work. Meanwhile, the council has chosen to start doing something about it. Since that last entry ("It's not about choice"), many things have happened. Well, we're Gentoo. We're flexible. We choose when to do things and when to do nothing. We'll adapt, and hopefully we'll weather the storm.
This weekend I chose (there's that word again) to update my Xfce Guide for 4.4, which is now being stabilized. Kudos to the arch teams and the xfce team; you guys rock!
You'll find new package suggestions, new descriptions, tips, links, and even a chapter on migrating from 4.2 to 4.4.
Now, you can choose (that was the last one, I promise) to do many things, but I hope you'll choose (okay, maybe not; I'm such a tease) to read the updated guide and try out Xfce 4.4 yourself.
And now, I choose to go to bed, since the PST to PDT change means the clock just struck 3AM.
Edit: Who's this joker over here? Who chose to write up that kind of wackiness?!?
Xfce goodness
I added my new Xfce Configuration Guide to our documentation repository tonight. I hope it'll get some of you to try out the wonderful creamy goodness that is Xfce.
http://www.gentoo.org/doc/en/xfce-config.xml
* It might take an hour or two to show up; the mirrors have to finish syncing first.
A new year means new things
...And part of those new things include:
Time for a status update from my last post!
I finished editing flameeyes' autoepatch documents, just before he sent in his retirement announcement (it's still a ways off, though), and before all his troubles with the stupid BSD-4 licence.
Added random bits and fixes to several docs, including a blurb about branding to the Gnome Guide, prompted this forum topic.
Only the first few items on my TODO list have changed from my previous post:
1) VDR guide updates and autoepatch: Done. Massively overhauled the provided patch (Englishification!), and finished Diego's stuff thus far.
2) Other assigned bugs: Much more progress. I got vivo to send in some patches for some ancient mysql docs bugs just before his retirement, so I closed those old bugs. Love closing old bugs! I've thought of a few more things to do on the pcmciautils migration guide, so I'll get those in and email brix for feedback.
3) Ebuilds: Got some help from Diego on this in exchange for the autoepatch docs. Some progress.
5) SwifT's alternative handbook: added some more tidbits. Ended up using some material I recently added for...
X) Forgot to add this to the last post, but one thing I suddenly decided to do a few days ago was write an Xfce Guide similar to the Gnome/KDE/Fluxbox guides already available. Something randomly clicked in my mind: we've a huge hole in the docs! I love and use Xfce (4.4-rc2, even) on my laptop! I should write something! Originally I'd meant to have it done over the next few months, to coincide with an upstream release, but...
So it took me all day today (since I was sidetracked for a good 7 hours), but I finally cranked out an Xfce Configuration Guide. It's the first all-new standalone guide I've written in awhile. It's much longer than what you'd expect for a guide on a lightweight desktop, because my approach was threefold.
First, I wanted to show how to install & configure a basic, minimal Xfce, and second, I wanted to show how to go beyond that and create a powerful, full-featured desktop environment that still adheres to the Xfce principles: fast, lightweight, configurable, and modular. Finally, I wanted to write a forward-thinking guide. Xfce-4.4 will hit final release sometime in the coming few months, and eventually the stable Portage tree. Therefore, I tried to write it in a way that's immediately accessible and practical to those who will be installing 4.2 (currently stable), as well as requiring minimal rewriting once 4.4 and all its huge changes hit Portage. To that end, I think I've succeeded. I'm hoping that this will be a real resource to all the folks that come to the forums asking "which one?" and "what should I run on this old hardware?"
I did quite a bit of research these subjects, examining not only the applications used on my (quite underpowered) old laptop, but also what the forumites were suggesting. Alas, many of the threads were quite old (2005), and most packages were no longer available -- a good example would be any gtk-1 apps, such as webbrowsers and email clients -- or too heavyweight to warrant consideration. Firefox and firefox-bin are the heaviest packages by far recommended in the guide, and even they run nicely on 128MB memory, a slow hard disk, and abysmal system I/O.
On a final note, my ISP has been completely sucking tonight. Internet availability has been terribly spotty. It's making it impossible to shop online for a headset for Skype. I got my first taste of Skype a few days ago, though it was only listening in to a few of my fellow devs; I had to use IRC to talk. That was pretty cumbersome, but now I feel the pull of Skype...must use it! It's so much more fun to hang out with the guys in #-dev via VoIP.
xfce eyecandy
All right, I finally did it. I went for the eyecandy. I've never set up any thing having to do with composite, transparency, etc., but I figured that since as long as I'm living on the p.masked Xfce edge anyway, I might as well use its built-in compositor. And...it's interesting. I don't particularly like how the panel automatically gets translucent whenever the mouse isn't on it, and it's actually distracting when I have a terminal superimposed on both Firefox and another terminal...I was surprised that the backgrounded Firefox itself becomes clear enough to see the other terminal underneath it.
And yet people dig this stuff? Or maybe they just dig the effects of more nifty compositing window managers like compiz. Anyway, I don't know if I'll stick with it or not. I'm pleased to say that after a little tweaking, it's a minimal resource hit even for my ancient integrated nVidia GeForce2 Go chip. (One of the very first dedicated mobile GPUs, a whole 16MB memory.)
Interestingly, I seem to be running only semi-hardware-accelerated, as I call it. running "glxinfo" gives a segfault, as it can't find the GLX extension to load, despite the visual results. Problem is, I can't enable "AllowGLXWithComposite", as that results in random hard lockups, which is the fault of being forced to use nvidia-legacy-drivers. These older 7xxx drivers are known to have such bugs, but the newer 8xxx drivers don't support my vintage 2001 hardware. Ah, well. At least adding "RenderAccel" to xorg.conf lets me run this stuff with very little noticeable slowdown. I suspect that I am getting hardware accel; it's just confused.
I think I'll bring along this composited laptop to SCALE and show off the wonders of unstable Xfce and the latest eyecandy. Which reminds me, now I need to see about getting all the effects of compiz, but without using that WM or unmerging yet more masked packages. I want to see what else this old graphics hardware is capable of.