I was interviewed by the SCALE Public Relations team; you can see the video here.

Gentoo@SCALE

I'd say we had the most diverse assortment of machines at any booth -- something like 10 different machines on 5 architectures. Certainly we had a bunch of developers; we haven't had a showing like this since SCALE 5x.

Everyone loves event pictures, so here's the Gentoo team:

Left to right: vapier, nightmorph, antarus, nerdboy, wormo, omp, halcy0n, solar
Not pictured: blackace (he took the picture)

And now, the hardware running Gentoo! On the table, from left to right:

1. Beagleboard running E17 on the huge monitor
2. Hammer/Nail board by Tin Can Tools (in the clear orange-capped tube)
3. Blackfin development board (hooked up to the middle keyboard, and with a touchscreen running Doom)
4. deployed Blackfin module (that 2-inch square to the left of the wireless mouse)
5. my Core2 Thinkpad running KDE4
6. a mini-notebook
7. OLPC XO (green/white, on top)
8. PowerPC Walnut board (in the K'Nex case). Barely visible behind it is the laptop that's tied in via serial port.

There were a few other Gentoo-powered laptops, subnotebooks, and smartphones demoed throughout the conference, but not all of 'em are visible in this picture.

I mostly demoed KDE 4.3 on my laptop, since the desktop effects and eye candy proved to be a good draw, especially the "falling snowflakes" animation. Man, I love that thing! It's a built-in KWin effect, so there's nothing special to install. Now all I want is a "falling raindrops" effect on my desktop, without resorting to Compiz.

I did occasionally switch the laptop to Xfce when I wanted to save power, or just to showcase Gentoo's flexibility. I got a good draw not when showing a standard Gentoo wallpaper, but when I showed off a desktop rather like this (clean version here). There were a buncha little kids that stopped by and oohed and ahhed over that for a bit.

Sessions@SCALE

The talks were rather disappointing this year. Several of my fellow devs stated that they "just plain sucked." Basically, none of us attended because of the talks. There just weren't any powerful draws. I was only vaguely interested in attending a couple of sessions, the ones on startup-up/embedded improvements and building a featherweight desktop. Didn't actually get to see those, as the timing and draw was just kinda "meh."

Instead, I found myself at the Mindstorms talk, which was very lackluster. I expected to see lots of toys in action, and videos, and whatnot. The speaker wasn't at all engaging, and the single Lego robot was impossible to see, and it wasn't working correctly for the entire presentation. I stopped by another session or two, but nothing grabbed my interest. I spent most of my time on the show floor, helping in the booth or wandering the floor. Speaking of which . ..

KDE@SCALE

I stopped by the KDE booth to see the newest 4.4 and 4.5 stuff being demoed, and I also tried to help one of the devs figure out the build dependencies for one of the latest libraries. Man, source building on Ubuntu sucks. There's some really, really nifty Plasma desktop stuff going on for small screens. The newspaper-like activity flow is something I wouldn't mind using day-to-day on my workstation.

Another neat bit of 4.4/4.5 is the ability to switch your Plasma desktop widgets while still keeping your applications open in front of you. It's sort of the opposite of workspace switchers, where each application group is on a separate virtual workspace, while the desktop remains fixed. I never bother with more than one workspace, but I do like the idea of switching the widgets behind whatever it is I'm working on.

The 4.4 improvements and upcoming 4.5 features are definitely enough to keep me interested in KDE, so I'll leave it on my laptop and look forward to the day 4.4 is stabilized in Gentoo.

Elsewhere@SCALE

The Gnome and XBMC booths were just across the alley from our booth, but I didn't get a chance to check out either. The Gnome guys blasted pounding techno music the whole conference, which gave all of us--even the ones without hangovers--good-sized headaches. The XBMC folks were running some pretty impressive demos on their Zotac MAG, but unfortunately I didn't get a chance to go over and chat with 'em.

In the last few days, I've decided to put together a living room HTPC built around an Acer Aspire Revo and XBMC Live, and it woulda been good to see the thing properly demoed a couple of weeks ago. Still, from what I saw from the Gentoo booth, XBMC is one heck of an awesome app.

Our booth was fairly well trafficked, but overall it felt like attendance (and interest in Gentoo) was down from previous years. Take that with a huge grain of salt, though -- while I felt like SCALE was more sparsely attended and the talks sucked, the actual numbers tell a different story. The event organizers say attendance was up more than 10% and there were more standing-room-only talks than ever before. So make of that what you will -- but I might not go back next year if it's going to be anything like my experience this year. There need to be more sessions that are relevant to my interests.

One of the high points of SCALE was meeting the folks interested in Gentoo, and definitely talking with our existing users, like the ever-loyal calculus from IRC. Thanks for coming by, folks!

From Transifex v8.0 featutes

As far as the appliance goes, the most important thing to know is that I dropped MySQL and replaced it with Postgresql, so if you’re thinking of updating an existing deployment, you’ll have to backup your data and handle the restoration process. If you’re installing for the first time, choose from the following image types:

• Installable ISO (x86)
• Installable ISO (x86_64)
• VMware (x86)
• VMware (x86_64)
• Amazon EC2 Small (ami-af8669c6)
• Amazon EC2 Large (ami-b7a54ade)

The appliance is pre-configured with 2 unique users: editor and guest (with passwords editor and guest respectively) and several projects for you to play!  To keep it up to date, log in to the web based administrative interface by connecting to your appliances url using https and adding port 8003 at the end. Then, login as admin (the initial password is password but you’ll be prompted to change it during the initial wizard). I can proudly say that the Transifex Appliance has been downloaded several hundred times in the last 2 months and is currently being used by several companies and projects that are either test driving Transifex or decided to host their own instance like the Xfce project for their translations!

As always the development branch of the appliance will follow the development code line of Transifex and provide a playground for anyone who wants to help out the project, such as the tasks created ahead of the upcoming Google Summer of Code. Download the appliance today and see why projects such as Meego, LXDE, Xfce, Fedora, and many more chose Transifex to manage their translations!

1. Check if the application is invisible and show it,
2. Otherwise check if the window is inactive and present it,
3. Otherwise hide it.

/* Show the window */
if (!(GTK_WIDGET_VISIBLE(window))) {
    gtk_widget_show(window);
}
/* Present the window */
else if (!gtk_window_is_active(GTK_WINDOW(window))) {
    gtk_window_present(GTK_WINDOW(window));
}
/* Hide the window */
else {
    int winx, winy;
    gtk_window_get_position(GTK_WINDOW(window), &winx, &winy);
    gtk_widget_hide(window);
    gtk_window_move(GTK_WINDOW(window), winx, winy);
}

xfce4-xkb-plugin currently has 38 open bugs on the Xfce bugzilla, 4 of them have a patch in bugzilla. This plugin to switch between different keyboard layouts has a lot of users, so you'll make a lot of happy users if you start working on this! Xfce needs you!

SCALE 8x is just around the corner! I and something like 8 or 9 other devs will be there -- it'll be our biggest showing since SCALE 5x a few years ago. Several folks coming from the Bay Area or flying in from across the state. I'll drive up Friday sometime to help setup the booth, and maybe try to get my Beagleboard working a bit better in time for the show on Saturday.

Git

Since my last post, I've opened up a couple of public repos at GitHub: one for my fork of LogJam, and one for my overlay, overnight. (Clever, yeah?)

The LogJam fork is to create a sane base for Gentoo and other distributions to get an up-to-date version of LogJam without having to maintain a huge patchbase. I was delving into the Fedora patchset; they had a few dozen they maintain for their RPMs. Once I'd finished updating my fork, submitting an upstream pull request was as easy as clicking a button and adding a short note. Awesome!

GitHub does nifty graphs about which sources have ties to other projects, as well as commit history charts. The downside is that since there's lots of javascript and Flash powering the site, responsiveness can suck.

So, why choose GitHub? For all the reasons so far, plus the fact that there are a lot of Gentoo projects on there already, including other overlays. And LogJam upstream's already on there, which really makes it easy to interact via the web interface.

Now, I should mention that I'm not married to GitHub or anything. In fact, I've registered an account at Gitorious, too, just in case I switch. Or if I want to have separate/mirrored projects at both websites.

I'm even thinking of git hosting some of my other personal projects, like night-sources. You know, stuff that needs organization. However . . . the problem I have with GitHub is that binary file hosting SUCKS. Lemme say that again: it's terrible. Really bad. There's no such thing as a static, canonical file name for a given archive, like you'd expect from SourceForge or Gna! or similar. Instead a small commit hash is appended to every file name, which is just ugly.

Let's say that I have a kernel patchset (labeled only by a version number) that I distribute in an ebuild's SRC_URI. I can't just call it ${PV}.tar.bz2; it has to be something like ${PV}-36x746avF.tar.bz2. The maintenance for each subsequent ebuild version goes up, because you have to change SRC_URI every single time, which takes away the flexibility of using variables in the first place!

Now, I understand that with GitHub, supposedly the hashname increases security, as you'll always know which commit it's from. Same for which branch, etc. However, it's also unnecessary, because the version number is right there in the file name. It'd be nice if you could always get individual tarballs the way you're used to:

2.6.22.tar.bz2
2.6.23.tar.bz2
2.6.24.tar.bz2

. . . instead, you'll get a bunch of random crap, appended to a really/long/tree/master/ URI.

So GitHub, if not git itself, is not ideally suited for binary packages, be it tarballs, image files, PDFs, etc. Lots of stuff cluttering up the path, and I have no clue if it can actually be removed. None of the support conversations I read on GitHub had a fix, either.

So I'm still looking for a good alternative. I may just have to keep everything in my devspace. As much as I'd like better organization of, say, night-sources (like the genpatches team has), I don't want to deal with those kinds of weird versioning issues.

Docs

In spite of CIA being down for some time and losing lots of commits, I've done a fair amount of docs work in recent days.

Yesterday I spent awhile bringing the Printing Howto up-to-date for HPLIP, as well as fixing all the kernel config and usergroup info. There are also a buncha updates I made to the Openbox Guide; all patches were supplied by Nate. (Thanks!)

The Localization Guide also some some luv; I pruned the old section on using localedef with the real way to generate locales, localegen. This stuff was already in our other documents, including the handbooks, but somehow I just missed this one.

The Portage handbook received some updates for automatic block resolution, as well as using examples for packages that are still in the tree. Not all the commits I make are huge rewrites; some of them are small but really helpful. The Gnome Guide, for example, lacked explicit instructions to follow the Xorg setup doc before installing Gnome.

Now, it is possible to install Gentoo and then immediately go right to installing Gnome. However, you may end up with a few misconfigured or missing bits along the way. New users would probably not know what to do next, so by adding this short note about required configuration, hopefully some of those pitfalls can be avoided.

Xfce

Almost forgot this month's Xfce desktop! I found a really neat wallpaper, and started looking for some gtk" themes with similar colors, to save me the trouble of creating one myself.

I decided to redo my desktop in a general Elegant Brit theme. I also decided to try out the Cairo Dock ebuilds. (These were originally from the desktop-effects overlay, but I brought 'em up-to-date and submitted a pull request to the maintainers. Git makes collaboration easy!)

I later unmerged Cairo-Dock, as I found it to be very unstable and buggy. Even now, DBUS and DBUS-apps still aren't working correctly, as not all of them can use the notification area anymore. Lame!

icons: Area o.43
gtk+: Elegant Brit (Pixmap and Mist engines)
xfwm4: Rezlooks-gtk (yes, it is confusingly named)
background: night launch

I rolled my own icons for Cairo-Dock, using a mix of Brit-inspired stuff from gnome-look.

The uncluttered version that shows off the wallpaper:

I cropped it from the original at APOD. That was the last planned night launch of the Space Shuttle before it's retired at the end of the year. Neat!

* * *

See at at SCALE, on Saturday!

No, it's not about the Beagle. That's still a big ol' pile o' poop.

First is that I was digging around in the X11 overlay, and I found out what I was missing to make xf86-video-ati and KMS work on recent kernels: x11-drivers/radeon-ucode. There are a few extra steps for getting the firmware into your kernel config, but it doesn't take long.

So now I'm finally able to use vanilla-sources 2.6.33_rc7. I'd been stuck on vanilla 2.6.32 -- no additional point releases, just .32. Every other .32 release had major regressions that prevented booting.

Running .33 makes me happy. I get the newest goodies (no more need for staging drivers) and Urban Terror still runs great. KMS is even a teensy bit faster, too.

However, then I went back to using stuff from the staging drivers tree: I decided to try out Nouveau tonight. Once again, I used the ebuilds from the X11 overlay, and recompiled my kernel. To my surprise, things mostly work! In fact, I'm writing this blog post from within Xfce, running on Nouveau + KMS.

Turns out that Nouveau doesn't really work on Geforce 8200/8300 cards, and possibly not on any IGP with shared memory. This is a known bug -- in fact, I tried out Nouveau hoping to add some current testing results.

While KMS works okay (a little slower than radeon), and I can get into X just fine, performance is pretty slow once I get there. Xfwm4's compositor is enabled, but that's not a source of trouble. As I stated on the bug, it's better than the proprietary nvidia-drivers, but definitely laggy. No hardware acceleration at all.

I jumped on to #nouveau to see what caused my cryptic error messages. It's not the firmware loading that's the problem, the problem is that the acceleration code has yet to be written for my IGP.

This just confirms what I've suspected ever since I purchased my motherboard in October 2008: it's chipset is absolutely good-for-nothing. My system is unbearably stutter-slow when using the proprietary nvidia-drivers, which means desktop usage is out, to say nothing of games or VDPAU decoding for movies. And the nv driver still doesn't work at all, and it wouldn't have any kind of hardware accel anyway. The last hope, Nouveau, is sorely lacking, so I'll just have to cross my fingers that some kind of support arrives before the 'board is replaced.

I guess it's back to my RadeonHD 4550: 3D and 2D are accelerated etc. Could still use power management code, and GL output or some other hardware decode logic for movies, but I've no real complaints. Those are all coming, fo' sho'.

I'm interested in getting an AMD chipset-based motherboard, but every benchmark I've ever seen shows poor USB, SATA/AHCI, ethernet, and other peripheral performance compared to an nVidia chipset. That's disheartening; I'd really like to go all-AMD. As long as there's a 4000-series IGP on the board, I could even ditch the low-end 4550 I currently use and save some power and heat. There don't seem to be many decent cheap options for microATX AMD motherboards these days.

Besides, aside from the nVidia IGP issues, I've no real complaints about my current mobo. You win some, you lose some.

We are looking for new persons to help us to take care of the Xfce web site. We need a web developer/designer to handle the technical details and someone to improve/update the contents (can be the same person).

Our web site runs a home made PHP based CMS (with no online interface) which we would like to keep (improvements and bug fixes are welcome of course) for the time being. Though, its contents needs some love: some pages are strongly outdated, the style could be refreshed, some pages still use tables for layout, etc. We also need to find a solution for localization: the current system requires the user to translate raw PHP pages and often leads to errors when going live, up to the point that we are considering dropping translations. This will highly depend on the people who get involved in the web site.

The web developer position requires a good PHP, HTML and CSS knowledge to be able to handle the different aspects of the web site. A good command of English to update/rework the different pages and make the web site easier to use, this also requires to follow the Xfce development to update the web site accordingly. Of course, this work can be done as a team if several persons step in. This is a good opportunity to start contributing to the Xfce project and this work will be appreciated by a lot of Xfce users.

Please contact me if you are interested. Thank you in advance!

I recently started to contribute more to the Xfce core, particularly Xfce4 Session and Xfce4 Settings (I'll try to blog more about that later), which leaves me very little time for Xfce4 Screenshooter. I would like to find someone to take over the maintenance of this projet, if you feel motivated please contact me (jeromeg@xfce.org or jeromeg in #xfce on freenode). Obviously, some basic knowledge of English (to communicate with the rest of the Xfce team and to develop the UI) and knowing C is required. If you are not used to the gtk/glib API, I'm ready to do some mentoring during a transitional phase. Anyway, I would be happy to explain the current code organization, the main issues, the weak areas, etc. This is a good opportunity to join a nice community which needs more contributors to keep rocking!

**Edit**: Bruno Ramos kindly volunteered for this! \o/ For other people interested in contributing, I'll post in the next few days on a few Xfce goodies which need a new maintainer. Please also remember that patches for bugs opened in the bugzilla are a great way to start contributing. Do not hesitate to join #xfce on freenode if you have any questions.

Changelog

• The XMLRPC-C dependency has been replaced by libsoup.
• Gtk 2.14 is now required to compile.
• Switch to a non-recursive Makefile.am. This reduces the build time and centralizes the build information.

New features

• Scrolling the panel plugin button changes the area to be captured.
• When compositing is on, use a nice partially transparent rubber-banding, still needs some polishing.
• F1 opens the help page.
• Automatically fill the title and comment fields in the ZimageZ upload information dialog.
• Make enter validate the upload in the ZimageZ upload information dialog.
• Use the XDG image directory as the default directory for saving screenshots. If it does not exist, fall back to $HOME.
• Major interface rethinking. This new interface is based on a suggestion by Yves-Alexis Pérez. The former main dialog is split into two dialogs: one for selecting the region to be captured and the delay, while the second one displays a preview of the screenshot and lists the available actions. The main application shows the first dialog, then the second one. If one of the region CLI options is given, the screenshot is taken accordingly and the second dialog is displayed. The panel plugin uses the first dialog as a configuration dialog. When you click the plugin, the screenshot is taken and the second dialog is shown.
• Allow drag and dropping of the preview to other applications in order to paste the screenshot (Mike Massonnet).

Bugs fixed

• UTF-8 characters in user name or password caused a login failure.
• Fix all warnings triggered by running autogen.sh.
• Fix the ZimageZ upload when behind a proxy.
• Fix copying of links in the ZimageZ upload finished dialog.
• Fix 100% CPU usage when selecting a region in a non composited environment (spotted by Gauvain Pocentek).
• When capturing a window with rounded corners, don't capture the background of the window but make the screenshot transparent instead.
• Make sure the save folder in the panel plugin preferences is valid.
• Don't show the copy to clipboard option in the application if no clipboard manager is running as the screenshot won't be preserved after closing the application anyway in that case.
• Allow xfce4-screenshooter -r to be used as a command for a keybinding.
• Allow silent build.
• Fix most pre-build warnings.
• Escape screenshots path when opening them with an application.
• Plug some leaks in the application and in the panel plugin.
• Do not accept conflicting CLI options. Warn the user when he uses CLI options which are not coherent.
• Correctly save preferences, even if the rc file does not exist (Mike Massonnet).
• One second is now the minimal delay when using the interactive mode. This caused the screenshooter dialog to be partially displayed on the screenshot in some cases.

• A lot of updated translations for the application, the panel plugin and the documentation. Thanks to the Xfce translation team!

Screenshots can be found on the homepage.

You may well remember last year’s chaos with the 4.6 release date. We’re trying our best not to repeat that and if it should happen again, we’ll at least keep you posted about the issues as good as we can.

So, what’s the deal with 4.8?

One thing that hasn’t changed much is that our development team is very small. A hobby project of this size requires a certain amount of time to be invested by each individual developer. Time not everyone has as much has he would like to dedicate to Xfce.

Today, Brian announced his absence for the coming months due to his new job, leaving 2-3 of our core components (xfdesktop, xfconf and xfce4-session) more or less unmaintained (aside from bugfixes). The good news is that Jérôme (who has recently started to improve xfce4-settings and port xfce4-session to libxfce4ui) and Daniel (the maintainer of the thunar-shares-plugin) have offered their help with xfdesktop and xfce4-session.

Brian is not the only one having little time at hand though. I’m preparing myself for my final university exams, so ideally I’d be sticking my nose into lecture notes all day long. I still have the time to write mails like this but there hasn’t been much activity around thunar and related projects lately.

Again, I’m really happy to see people volunteering to help because that’s what we need right now. There’s a lot left to do before we can release 4.8. Let me get to that now.

As some of might have heard, thunar was ported to GIO this summer. Through GVfs, GIO brings new features such as SMB, SFTP, FTP browsing which some people use one a daily basis already. Now, GVfs has turned out to be problematic for us for various reasons. At first it shipped a HAL-based volume monitor with a hard-coded dependency on gnome-mount. Today it ships a volume monitor based on gnome-disk-utility (uses DeviceKit-disks itself) which proves to be inconsistent and somewhat incompatible to the HAL mounting code in exo.

The result: thunar-volman (not part of the core but important for thunar nonetheless) and xfdesktop will have to be ported to udev (the mounting being done with GIO, ideally). I’ve started working on this but this is far from being finished.

Question to the other developers: Didn’t xfce4-session use HAL for logging out and stuff? We might have to look into replacing those portions of code with something based on ConsoleKit, I guess?

HAL/udev is not the only issue however. With Xfce 4.8 we’ll be replacing libxfcegui4 with a new library called libxfce4ui. Not all core applications (again, xfdesktop being one of them, I think) have been ported to it yet. In most cases, this is no big deal and probably could be resolved within a few days though.

Then we have garcon, the much improved menu library that is supposed to replace libxfce4menu. At the time of writing the only feature it is lacking that is crucial for 4.8 is file system monitoring. We’ll probably implement basic monitoring like we had in libxfce4menu. Work on this hasn’t started yet.

Also, xfdesktop needs to be ported not only from ThunarVFS/HAL to GIO/udev but also from libxfce4menu to garcon.

So, as you can see there is quite a lot of work ahead of us. Taking into account the little free time some of us have these days, we’ve decided to postpone the 4.8 release until June 12th instead of April 12th. The entire release phase in our schedule has been moved by two months in time, as you can see on the official schedule wiki page:

 http://wiki.xfce.org/releng/4.8/schedule

To be honest, I wouldn’t consider this new date fixed either. It all depends on how much we can do until the feature freeze on April 1st. I’m optimistic that meeting the deadlines is possible though.

For all of you who can’t wait until June, try out our development releases which are announced on http://identi.ca/xfce. I have at least something good to share: For a few weeks now I’ve been running Fedora 12 with a mixture of Xfce 4.6 packages and development package from the upcoming 4.8 series and the new components have proven to be very stable already.

I’m especially happy about the new panel which works almost flawlessly (except for a few dual head issues) and not only supports real transparency and more comfortable launcher creation based on garcon, but is also compatible to panel plugins written for Xfce 4.6. (Good work, Nick!)

So, I guess this is it. A mixture of good and bad. I hope nobody is too disappointed. As always, we’re doing the best we can.

Cheers!

From Transifex v8.0 featutes

Now, mind you this is still very alpha code but that is probably a good thing since you can play with it and give your feedback on how to improve it. As always, you can get this in an easy to consume format by using the Transifex Appliance Developer edition… or you can join the Xfce translators who are already enjoying Transifex latest code!

From Transifex v8.0 featutes

I’ve been contributing with translations for the Brazilian Portuguese language for quite some time now, and have been a strong supporter for the Transifex project as well, so I was thrilled to learn they were “working together”! But there is a second reason why I’m mentioning this on my blog:

Turns out that Nick Schermer, maintainer for http://translations.xfce.org, is using my Transifex appliance too!!! Moreover, he chose to use the appliance built from the development branch to get the very latest bits being committed to the development branch of Transifex. It has been a win-win-win (yes, 3 times!) relationship so far for all parties involved, for:

• Xfce gets a ready to run, batteries included, Transifex appliance with all the latest and coolest features without having to build things by hand.
• Transifex gets tons of excellent feedback for this version still in development and work out all the kinks before the next release.
• My appliance has also enjoyed of tons of excellent feedback and is now more robust and ready for consumption.

From Transifex v8.0 featutes

Some of the cool features that you can expect from the next version of Transifex (and that the over 200 registered Xfce translators are already enjoying) are:

• Better support for Lotte, the online translations editor, and the removal of the 100-strings limitation;
• Automatic translation suggestions within Lotte;
• Support for translation teams;
• New timeline history for tracking contributors, teams, and projects activities;
• Top Translators “hit list” for your bragging rights

From Transifex v8.0 featutes

The Transifex Appliance (developer image) has been updated almost on a daily basis, so those out there already using it can keep it updated using the web based appliance management tool or running conary updateall. As always, you can expect a stable release the very same day that Transifex releases the upcoming 0.8 version! I’d love to hear from all of you appliance users out there. Just drop me a line or a comment here and I’ll do my best to improve your experience.

That's a tall order, as I'm used to the way my gtk+ applications look, feel, and behave in Xfce. Trying to learn something that may do things completely differently can be very frustrating. Heck, it can be annoying even when 98% of the time the app does just what you want it to. That last 2% can push you over the edge.

Part of learning the ropes with KDE4 is finding which application does what. Yes, I could just keep using all my existing gtk+ applications with little or no difference in look'n'feel, thanks to QtCurve. But that would deprive me of the chance to try out the many, many other apps available in the FOSS world. I'd miss out on all the fun if I focused on applications written for just one toolkit. This post examines the differences between certain gtk+ and Qt programs.

Obviously, these are my subjective experiences. Everyone has their own preferences. Using and writing about all these different applications has really helped me take a look at what exactly I like to see in an application. What I expect it to do out-of-the-box, and what kind of tweaks it offers so that I can tailor it to my needs. Actually, reviewing Qt apps has helped me in my search for gtk+ equivalents, too. I've been spending more time examining user interfaces on their own merits, instead of discarding apps from consideration based solely on their widget toolkit.

The applications listed here all work equally well in Xfce and KDE, so if it operates in one environment, it operates in the other. If it fails in one, it fails in the other. It's a fairly level playing field, except that I'm coming from an Xfce background, which means I'm just not used to how some things are done on the "other side of the tracks." I've tried to keep that in mind as I jump from app to app.

Multimedia

For audio playback, in Xfce I use Decibel. Its playlist support isn't all that great, and it can't do additions by genre (or suggest/smart-add tracks) but overall it's fast and easy to use. I've tried other gtk+ apps like Rhythmbox and Exaile, but while I like the ideas behind them, their user interfaces are just a bit too busy to be useful. Players like Listen or Songbird are also too complicated (and dependency-bloated).

I need some kind of happy medium between the sparse simplicity of Decibel and the clutter that is Rhythmbox, Banshee, Exaile, et al. Bluemindo, Consonance, and some of the MPD front-ends come close, but don't quite make the connection for me.

Speaking of MPD: while it has many, many front-ends, I totally dislike the whole client-server model. I don't stream anything over the network, so setting up a server on a single box, with all the weird configuration that entails, is just too much. Plus MPD still can't play audio CDs, so I don't bother with anything that uses it, whether gtk+ or Qt.

Elsewhere in the player spectrum, there's XMMS and its derivatives. I used Audacious for a long time until it quit working a few years ago, then moved to Decibel and haven't looked back. However, as much as it's a pain to add tracks in the Winamp lookalikes, I can use them fairly quickly and find where everything's located, since I used Winamp for years back in my Windows days.

It's hard for me to find a player that feels usable on a day-to-day basis. Both when I just quickly want to throw some tracks in the queue and when I want to spend some time arranging a playlist. Those are the two big tests of a player's usefulness. There are lots of KDE/Qt media players available, so I've started sampling them.

JuK: Meh. I don't like the UI. None of the modes are intuitive, even after days of playing with it. That left sidebar is killing me. Totally unhelpful.

Amarok: Yup, the heavyweight. The program that's gone through polarizing changes to its UI and features in the 1.x/2.x release series. Can't say I care for it -- it was far too complicated. Felt like it took the worst UI design aspects of Listen, Songbird, Banshee, and slapped 'em together. Plus it was slow. I don't have a large collection of music on my laptop; less than ten albums. The library is tiny, but Amarok is always pig-slow to startup and search through my files. Plus Amarok required many libraries that take a long time to compile. Not worth it. Akarok just isn't right for me.

QMMP: This is familiar to an old winamp/xmms/audacious user, but very dated. I don't like the idea of skins anymore. I want applications to smoothly integrate with my desktop theme -- using native widgets, whether gtk+ or Qt. There's no "default to native Qt widgets" setting, unfortunately. But it plays media as expected. There's a wealth of built-in plugins that offer everything I need for playback and information display. Just like the good ol' days of Winamp, XMMS, and Audacious.

QMMP is the player I'll stick with for the time being, as I can't find anything with a UI that's not too simple or too complex. What I'd like is a Qt app with a couple of configurable panes and album cover support -- something like Decibel or Consonance, but capable of more than just adding music by album or artist.

Kmix: an applet for volume control. It has the quick functionality that I'm accustomed to in Xfce4's volume control, in that I can hover over the applet and scroll the mousewheel to change volume without needing to click. Very handy. However, the icon and "sound wave" meter are so tiny it's very hard to tell the volume has been changed without clicking to check the level. When opening Kmix as a standalone application, it's the most confusing frontend I've ever seen to alsamixer. Seriously, its UI is crap, even after adjusting the display options to minimize the clutter.

That screenshot in the above link represents a best-case scenario, and even that's totally unintuitive. The icons also don't always make sense -- take that first one at the top of the "Master" control. It's a mini slider switch. Looks like it should do something, right? Yeah, just keep grabbing at it, then realizing that it won't actually do something. I could go on, but I'll stop there. There are some icons I just have to ignore.

Fortunately, my needs are simple; I don't need many displayed controls. I don't even use the laptop's builtin microphone, and only rarely use headphones. "Master" and "PCM" are the only things I really care about.

On the positive side, sometime after installing Kmix (so it's possibly related) I now have an on-screen volume indicator when I use my laptop volume buttons! The last time I saw this was in an ancient version of Ubuntu, so it's quite a treat to have the buttons actually work and get integrated into my desktop. Love it!

Now I just need a working on-screen display for my LCD brightness level. I do get a popup, but it doesn't always move the level meter when I adjust brightness, in KDE and Xfce. At least I'm halfway there: things appear on the screen when I push buttons. Good start.

Utilities

Ark. In Xfce, I use Xarchiver to work with tarballs, zipfiles, etc. I've also played with Squeeze in the past, but found it rather unstable. Back in my Gnome days I used the ubiquitous file roller. There are a few different gtk+ archive managers I've used, and generally liked their UIs.

Ark seems to be the standard (possibly only) Qt archive manager in Portage. Sadly, it would not work: it said it did not have the necessary permissions to create archives in my own home folder! This was a show-stopper, so after a few half-hearted debugging attemps I unmerged it and went back to Xarchiver. Under KDE, Xarchiver sorts the archive in reverse, with files at the top and folders at the end, but this is a minor change to expected functionality. It still does everything else it's supposed to.

Plasma-emergelog: a plasmoid I found on the official KDE overlay. Prints emerge.log output from the last few merges; can be pretty useful. It's even written by a fellow Gentoo developer.

Dolphin: as filemanagers go, this one is okay. Once I disabled some of the hover mojo, enabled double-click activation, and added an "Up" arrow, it works like any other FM I've used. That is, with one key exception: the unending annoyance that is the location bar! I like having an editable location; it's much faster for me to type the location than it is to keep clicking backwards and forwards though the filesystem. However, the location bar doesn't seem to be persistent. Every time I open a new Dolphin window, I always have to click View -> Navigation Bar -> Editable location. My setting is never permanently saved. Is this a bug or a feature? It's driving me crazy!

The search bar is interesting, but useless. I intend to remove resource and space-sucking hogs like Nepomuk, Strigi, and anything else that uses the "semantic desktop." Maybe one of these days the semantic desktop will matter, and our tools for using it will improve, but for me, that day is a long way off.

I can't find one good desktop search framework for any environment, KDE, Xfce, or Gnome. Beagle, tracker, Strigi, you name it. In my experience they're just too slow and bloated.

Konsole: an acceptable terminal, though I may be going back to Xfce Terminal soon. Konsole does everything I need it to except make use of middle-click functionality. I can't middle click a URL to have it open up in a new Firefox tab, for example. This is something I do constantly -- whenever I run an eix query, I usually open up the application's homepage, which just needs a middle click in Xfce Terminal. It's a two step process in Konsole; I first have to right-click the URL, then choose "Open Link." I miss the middle-click so much I'll probably go back to Terminal. Now that my gtk+ widgets all look like native Qt apps, it's not like I'd notice a difference. The color schemes are the same, the fonts, are the same, they can both do tabs . . .

Networking

Kbluetooth: Bluetooth manager for KDE. In Xfce, I use Blueman, which gets the job done. It mostly has a unified user interface. But I can't actually browse my phone in a filemanager, since Thunar lacks support for that. Even using Gigolo isn't enough -- I'd have to install various FUSE packages to get support for opening the obex:/// location from Blueman, or use Nautilus. Neither are acceptable.

I can't browse my phone using Kbluetooth, either. I can send and receive pictures, but sending (from the phone) requires a laborious, slow process of selecting each file and stepping through several menus. Sending items to the phone from the laptop is much faster, as I can use the normal file picker.

Also, I couldn't get a unified preference/usage window to popup for Kbluetooth. I had to do lots of right clicking on the panel applet, and every setting requires a new window. Rather annoying.

One other annoyance was the fact that every time I wanted to receive a file from my phone, Kbluetooth opened KWallet. Can't it just read my PIN from secure location in the filesystem? I think that's what Blueman does, maybe someplace in /etc/, just like wicd and wpa_supplicant do for WLAN passwords.

I still need a good Bluetooth client that lets me browse my phone directly in a file manager of some kind.

WiFi: turns out that by reemerging solid with +wicd, it enables support for wicd, which I already have installed. I haven't seen how this works, though. Wicd was already listed in the program autostart menu; I just had to change the command so that it launches the tray applet and doesn't just run the background daemon.

Regardless of any special Solid integration, however that works, since wicd operates normally, it may remove
the need to install some other network connection manager. I'm quite comfortable with wicd, and it'd be nice if I didn't have to setup a new configuration for a new app every time I switch desktop environments.

Writing

Kblogger: client that supports multiple blogging APIs, including LiveJournal support. I found this client in the kde overlay. However, it doesn't actually work with LJ. It can't add post tags, nor can it retrieve existing tags. Trying to do so kills the application. Very buggy. I gave up and unmerged it.

Blokkal: another multi-blogging client with LiveJournal support. Does everything I want it to for LiveJournal. Minor annoyance: I can't just type my LiveJournal password into Blokkal, but instead have to first enter the password for KWallet. But that's probably a more secure method of storing it locally, right? Still, it's an extra step that I don't have to take when using gtk+ clients like Drivel or LogJam.

Office

The next big writing application to find is a word processor: something that's fast, easy-to-use, and doesn't require hours of downloading and compiling. KWord seems to be the most well-known office application, but the reviews I've read so far indicate that it tends to run a bit slow, though not as bad as OpenOffice. That's a positive sign, so I'll give KWord a shot.

On the lighter side, FocusWriter seems to be a Qt clone of PyRoom, which is a free gtk+ version of WriteRoom for the Mac. I wrote an ebuild for PyRoom a year ago; it's been one of my very favorite and most useful applications. I do need a distraction-free writing environment, so I'm glad to see that there's an equivalent application for KDE/Qt.

Other office software I need to investigate: spreadsheets, finance trackers, and email clients.

And another thing . . .

I notice that it can take a long time for newly installed applications to show up in the Kicker menu, or to disappear after I've uninstalled them. Why is that? Is something not scanning /usr/share/applications when it needs to? I usually have to logout if I want to see the menu updated.

Until now, volume management (monitoring and mounting) in Xfce was done through HAL, the hardware abstraction layer that is currently being deprecated and dropped by major distributions. The functionality previously provided by HAL has been moved into udev, udisks (formerly known as DeviceKit-disks) and upower (formerly known as DeviceKit-power).

Volume management is transparently supported by GIO, meaning that applications don’t have to worry about the backend implementation. It should, in theory, not matter whether HAL is used or udev/udisks. Unsurprisingly, in reality, things are not that trivial, mainly for two reasons:

1. Due to its focus on file management, GIO only supports monitoring and detecting storage devices (DVD drives, USB sticks etc.). There is no way to be notified when e.g. a digital camera or a portable media player is plugged in. This is critical for the functionality of thunar-volman which until now supported everything from cameras, media players, blank CDs/DVDs, audio CDs, PDAs and printers to input devices like keyboards, mice and tablets.
2. Mounting volumes with udisks seems to be somewhat incompatible with HAL. I tried to mount volumes with thunar-volman and exo-mount (both implemented on top of HAL) and was for the root password upon unmounting in Thunar (using GIO and gnome-disk-utility/DeviceKit-disks). It seems like volumes mounted with HAL are assumed to be mounted by a different than the current user and thus, require root privileges to be unmounted.

HAL being deprecated and somewhat incompatible with udisks, what are the consequences for Xfce, and for thunar and thunar-volman in particular?

Let us, for a moment, assume Xfce 4.8 and thunar 1.0 were released as they are today, with thunar using GIO (and udisks instead of HAL in all major Linux distributions) and the rest (like thunar-volman and exo-mount) depending on HAL. As mentioned before, exo-mount and thunar wouldn’t work together in multi-user setups. Thunar would no longer detect cameras, PDAs, audio CDs, blank disks, mice, keyboards, tablets, media players and thunar-volman would end up being completely useless, as it is not detecting devices by itself. I think it is safe to say that this is not what we want.

In the following, I will focus on how to deal with thunar-volman. The rest of Xfce faces a similar roadmap, however. With regards to thunar-volman, there are (at least) three sane options:

1. Drop thunar-volman and only support auto-mounting storage devices from now on, directly implemented in thunar. What is very obvious about this solution is that a lot of possibly useful functionality is lost.
2. Port thunar-volman to (g)udev/udisks/GIO and make it a standalone daemon so that thunar no longer has to spawn it when new devices are plugged in. The advantage of this approach is that thunar only needs to depend on GIO and doesn’t have to implement the device detection part.
3. Port thunar-volman to (g)udev/udisks/GIO as described above and make thunar depend on (g)udev for device detection. Spawn thunar-volman when devices are added/removed. The advantage over the previous approach is that thunar-volman doesn’t have to run permanently as a daemon. The additional thunar dependency on (g)udev could be seen as a disadvantage but on the other hand, it basically replaces another (HAL).

Now, everyone knows that programmers are lazy people. So, in the hope of being able to save some work, I started a survey on the usage of thunar-volman. The idea was to find out which of its features are used most and whether there are some that nobody really cares about. Here are the results:

=======================================================================================
                                                        Feature   #Users   Percentage 
---------------------------------------------------------------------------------------
                        Mount removable drives when hot-plugged       86        92.5%
                            Mount removable media when inserted       83        89.2%
                           Browse removable media when inserted       69        74.2%
             Cameras: Import digital photographs when connected       31        33.3%
                          Play video CDs and DVDs when inserted       31        33.3%
                                   Play audio CDs when inserted       30        32.3%
                 Burn a CD or DVD when a blank disc is inserted       21        22.6%
        Portable Media Players: Play music files when connected       11        11.8%
                      Auto-run programs on new drives and media        7         7.5%
        Automatically run a program when a printer is connected        7         7.5%
                        Auto-open files on new drives and media        6         6.5%
                               Sync Palm devices when connected        5         5.4%
  Automatically run a program when an USB keyboard is connected        3         3.2%
     Automatically run a program when an USB mouse is connected        3         3.2%
         Automatically run a program when a tabled is connected        2         2.2%
                          Sync Pocket PC devices when connected        2         2.2%
=======================================================================================
                Thunar Volume Manager Usage Survey with 93 participants

According to the results of this survey, auto-mounting and browsing of removable drives and media have highest priority among the 93 participating thunar-volman users. This more or less covers the functionality we could cover with GIO alone (plus automatically running a program when new drives and media are inserted). However, a third of the users also use thunar-volman for importing photographs from digital cameras and for playing video and audio CDs as well as DVDs automatically. Almost a 25 percent of all users use thunar-volman to start their favorite burning software when a blank CD or DVD is inserted. Slightly more than 10 percent want thunar-volman to start playing music on portable media players when they are plugged in. Printers and Palms are also somewhat relevant.

This survey confirms my expectations that handling storage devices alone is not enough even though they clearly are the most important use case for thunar-volman. Our users seem to like the flexibility of thunar-volman and make use of it. This disqualifies option 1 and leaves us with options 2 and 3. I’m inclined to avoid another daemon and go for number 3.

In preparation for porting thunar and thunar-volman to udev/udisks/GIO, I’ve created a wiki page to collect information about how we can reliably distinguish the different device types based on udev properties: http://wiki.xfce.org/dev/thunar-volman-udev. If you have blue-ray disks, video CDs, a digital camera, a Pocket PC, a Palm, a USB printer or a graphics tablet, you could make me very happy if you inserted them or plugged them in and sent me the output of udevadm info --export-db to my Xfce email address together with a short hint what devices you’ve plugged in. Alternatively, you can paste/upload the output somewhere on the internet and comment on this blog post, and thereby help making future versions of Xfce better.

Cheers!

It's been several days since I installed KDE 4.

I've been using it off and on, experimenting with Arora and Dolphin. I'm just starting to sample the applications available for Qt/KDE.

Blokkal: an extendable blogging client for KDE4

One thing I did discover earlier tonight was a blogging client called Blokkal. This client caught my eye because it supports the LiveJournal protocol, which makes it one of about three (?) actively developed LJ clients on the internet. The others were all discontinued years ago, and their ebuilds have been removed from Portage. Sure, the source code is still available, but it's tough to integrate features such as tags, userpic management, and various other LJ service improvements. Or they come with heavy Gnome dependencies, as in the case of BloGTK and Drivel. (Yeah, I still think in terms of "how much will this weight down my Xfce desktop.)

So finding out that there's a native client that supports LJ was quite a treat. Blokkal also supports many other blog APIs, but I don't use 'em, so the only draw is the LJ integration.

Writing the ebuild

My next step was to write an ebuild for Blokkal, since a quick check of the Portage archives didn't turn up any ebuilds. Thus I began my plunge into the source code of the app and reading the stated requirements on the homepage.

Blokkal has a CMake-based build system, and it lists kdelibs, KDE PIM libraries, and the Phonon library as its requirements.

The first step of writing the ebuild was to get the basic header stuff (HOMEPAGE, SRC_URI, etc.) out of the way, then add the raw deps.

Dependencies

I was initially a bit unsure of the PIM library listing, as we have in Portage both kdepimlibs and libkdepim. The first was closer to the Debian package name, so I took a chance that this was the correct one. After that, a few quick eix checks on the rest of the packages sorted out the likely names, and then it was on to the source code to see what was a runtime dep, and what was a buildtime dep.

Turns out that with one exception, DEPEND was the same as RDEPEND, so that saved time. I initially had kdelibs as an explicit DEP, but Jonathan Callen (ABCD on IRC) kindly corrected me, as it's already in kde4-base.eclass. (Thanks to him and wired for answering some of my inquries.)

Eclasses

Eclasses were the next step: which eclass should be used to get proper background dependencies, source configuration, compilation, and installation? The KDE and Qt teams have been very good about eclasses over the years; most ebuilds inheriting them don't need much in the way of actual code lines -- no need to duplicate anything when the eclass does the work for you.

There are a few different KDE4 eclasses available in the tree, and I had to read through 'em all to guess which one was most appropriate. Other KDE applications in Portage don't need many lines of code; the various eclasses do all the heavy lifting. I jumped on IRC to confirm my choice of kde4-base.eclass, then ran the emerge, only to be met by compile failure!

Compiling and running

I suspected it was an error I've run (and fixed) before, and sure enough, it was: I just had to redefine ${S} since the package download is Blokkal-0.2.1, but the ebuild is blokkal-0.2.1 in lowercase. I'd gotten ${MY_P} right elsewhere in the ebuild; just forgot this one thing.

After the fix, it compiled just fine, started up just fine, and I added my account . . . only to discover that I couldn't log in. Something was missing . . . but what?

I took another look at Blokkal's source code. There were a few kwallet headers and kwalletmanager references that implied another runtime dependency was needed. I added kwallet to the ebuild's RDEPs, recompiled, and finally got the popup window asking for the password. Now I could login to my account and do some Blokkal UI configuration.

Try it out

Since the ebuild is finished, why not try out Blokkal? Get the ebuild here.

Coming up

So there you have it: another step in my KDE4 odyssey. I expect to get my hands on some themes, multimedia applications, office/writing tools, and more.

Obligatory screenshots

Here's my current desktop, which mostly shows off the "Naked" plasma theme and my desktop widgets:

For comparison, here's one with a couple of open applications. This shows how well gtk+ applications are integrated into KDE, thanks to the QtCurve style. In the background is Dolphin (Qt4) and in the foreground is Abiword 2.8.1. (From the ebuild I wrote for it)

Xubuntu is a perfect fit for my students. I’m grateful to the Ubuntu community for it, and to the community of talented people creating phenomenal open-source applications. Without Xubuntu, my successes as a teacher would be less. The volume and scope of our students’ success stories could fill up a great deal more space, but for now I just wanted to express what a fantastic effect the open-source community and Xubuntu have had on my students’ lives.

If you’ve ever had to question why you contribute to Open Source Software, look no further then the children.

Why KDE?

In a word, SLiM. Sometime in mid-December I caught an X11 update that made SLiM stop working. Or maybe it was something else. My theory is it was the xinit update that dropped twm, xclock, and xterm from the required runtime deps. So abruptly SLiM stopped working, and I couldn't login graphically; I just got errors saying "Couldn't execute login command" with nothing else in my logs. Forums didn't help. I could run startx manually, but that's a pain. Not suitable for a laptop shared with my wife. I unmerged SLiM and started looking around for alternatives. GDM is one, but it drags in a bunch of Gnome dependencies. XDM is just ugly and unconfigurable, and lacks the appropriate shutdown/restart/suspend actions. KDM was the last candidate. Yes, it had lots of KDE dependencies, but I figured that if I installed KDE4, then it wouldn't have as many deps, right?

Yeah, I know, it's like: "But . . . aren't you an Xfce guy? Don't you exclusively use gtk+ environments (including Gnome in years past)? Don't you hate heavyweight crap or endless C++ compiling?"

Yes, yes, yes, and yes. I know. But here's the thing: after initially getting excited about Aaron Seigo's (now canceled) upcoming talk on KDE at SCALE, I then found out that Camp KDE will be right here in San Diego, just a few miles from where I live. So I started thinking -- now that things have settled down since the disastrous 4.0/4.1/4.2 days, maybe . . . maybe it would be worth experiencing directly what "the future" is all about, according to the hype machine. I'm thinking of visiting Camp KDE, so I thought if I do, I should have some knowledge of how KDE currently works.

Past and present

The last time I ran KDE was back in late 2004 or early 2005. As far as I remember, it wasn't even on Gentoo, but on other LiveCDs and distributions. I still have an old Knoppix CD from 5 or 6 years ago lying around -- and that was KDE3-based. Given Plasma and all the other new buzzwords and technologies and new paradigms, I figured it was about time to see how things have progressed.

Or stayed put.

Configuration

True to form, KDE4 still makes configuration this massively complex, insanely arcane art. You need an engineering degree to wade through the simplest of configuration menus, even when right-clicking on an item in your panel -- if you can find it, that is. The dialogs are very inscrutable; it makes navigation difficult. All these weird arrows and spaces and popup panels in the default theme, not even something with extra bling.

One of the first things I did was turn off that stupid window-that-is-not-a-window on the desktop, so that I wasn't distracted by all the flashy Plasma widgets. After that, I spent a half hour trying to tweak the font settings. I discovered that buried in the Antialiasing dialog are the actual hinting and RGB subpixel hinting configs that I was looking for, though there's a catch. You can actually disable (that is gray out) the AA option, which makes you unable to get to the stuff below it. BUT, as long as you've tweaked your hinting settings before exiting that subdialog, that's okay! You just have to re-enable AA to get into the hinting subdialog. Stupid, I know. The Xfce way is much, much better; all three options are exposed top-level.

After making my desktop readable with Verdana fonts, it was time to start poking around. And around and around and around -- it's easier to navigate the Windows Control Center than KDE CC. Things haven't changed there in 6 years. It's especially bad when you get to the properties of your Qt theme, in this case, QtCurve. Several dozen confounding lines popped up in the right box, dizzying amounts of tweaks that should in no way be exposed to the end user. Seriously, just let the theme author set 'em and forget about 'em. If there need to be variants...don't expose every last line of optional code to the user.

Integrating gtk+ apps

Despite some initial setbacks, I decided it was time to start installing a few more packages. See, I wanted a bare minimum install, which turned out to be 74 packages for kdebase-startkde and kdm. That's after tweaking my USE flags for half an hour to whittle the dependencies down. Yeah, that's the bare minimum -- I was at only about 470, 480 total packages for my very minimal Xfce environment. I like my laptops to run lean.

Then I added qtcurve-qt4, gtk-engines-qt, and kcm_gtk, since without the unfortunately ~arch kcm_gtk, it's not possible to have your gtk+ apps use your Qt theme. This needs to be rectified; the gtk+ module should be stabilized ASAP, given that everything else is stable. Once in place though, even Firefox behaved nicely with my Qt theme. Very nice.

After fleeing from the QtCurve controls, installing kcm_gtk, and restarting KDE, I was able to get my gtk+ apps integrated nicely with KDE. That's one area that KDE4 beats Xfce and Gnome, at least in Gentoo. We don't have a "Make your Qt apps look like native gtk apps" gtk+ engine in Portage.

Packages: webbrowser

I still needed a file manager and a webbrowser, so I decided to install Konqueror, having used it in years past. It turns out that Konqueror doesn't have dual-functionality anymore; it's just a webbrowser. A webbrowser that can't use Flash until you install kde-base/nsplugins, FYI.

Konqueror startup is much better than it was 5 years ago. It's still kinda slow, but not as slow as Firefox! The downside is that when running, it tends to be a bit slower since it doesn't have the nice Adblock features that the Firefox extension offers. Yes, it can kind of do Adblock with lists, but as far as I could tell, it was still downloading all the "blocked" content and rendering it, but just making it invisible via CSS or some such mojo. It's still doing all the processing of heavy Flash and Javascript, but where you can't see it. Contrast that with never downloading blocked content in the first place.

Speaking of Adblock, I think the main reason why I'm still on Firefox is that there's not a single Adblock implementation that has the functionality of the Firefox version: making it easy to right click on anything, Flash, iframe, image, text, etc, and add it to the blacklist with a simple click. Nothing else even comes close, and I've tried almost all the gtk+ webkit browsers out there. None of them can do it. Which is too bad; I love webkit's speed and rendering accuracy, but no browser that uses it has integrated an easy-to-use constantly-configurable Adblock plugin. Maybe Arora, Rekonq, or some other Qt browser can, but I'm not holding my breath.

Packages: file manager

So I'm still on the lookout for a good Qt webbrowser, and a file manager while I'm at it. Supposedly Dolphin is the new Konqueror, but the jury is still out on its dependencies because of weird USE blocks. I've been sticking with Thunar, which now looks good in QtCurve, except for the icons. I get a lot of default blank icons even with the help of kcm_gtk. For some reason, despite activating the right setting, the KDE icon theme isn't fully integrated with Thunar. I'll give Dolphin another shot tomorrow.

Packages: terminal

Konsole works decently -- it doesn't start up as quickly as Xfce Terminal, but it does blend nicely with KDE (of course). Its configuration works just like the ol' Gnome terminal: instead of the simple, obvious "Edit Preferences" menu found in Xfce Terminal, you have to click "Edit current profile." Which means you have to know what a profile is, that you're using one, and that it has things you want to change in it. Still, Konsole is fairly configurable; I got it to my preferred white-on-black setup, with my fonts just how I like 'em. It did what I wanted it to after a bit, though I didn't find the option to disable "Scroll on output," which is annoying when I want to read a bit of emerge output in mid-compile. Minor nitpick; I'm otherwise satisfied.

Speed and desktop effects

Performance is another matter. Yes, I am running a mostly stable/some ~arch Intel graphics stack, on an X3100 IGP, but come on . . . I expect window moving, resizing, fading, and switching to be snappier! Once I enabled desktop compositing, it both helped and hindered window usage. The OpenGL renderer is faster than Xrender. Xrender is much slower at window fading and moving; there's lots of lag. However, the OpenGL renderer leads to buggy themes -- about half the Qt and Kwin themes are unusable because of serious visual glitches and artifacts that corrupt the widgets and buttons. This is present to some degree even in the default Oxygen/Ozone themes, and to a lesser extent in QtCurve. Sometimes widgets flash real fast or in weird colors when you mouse over 'em, sometimes they remain normal. It might just be Intel graphics code; who knows. It doesn't happen when using Xfwm4's Xrender compositing, though. Xfwm4's compositing is also very snappy, with no slowdown.

While there are some performance issues, and some OpenGL problems, I did discover something totally neat, something even my wife thinks is cute and wants on her Mac: the snow widget! KDE4 includes an awesome composite trick that brings weather onto your desktop. You can set it up so that there's gently-falling snowflakes behind all your windows. Awesome! So peaceful and cozy. If I take away one thing that gave me a good feeling from the experience, it was enabling the snow candy -- which isn't as hard to do as it was in Compiz, I might add. Mmm, snow.

What I really want now is some "rain" eyecandy that does the same thing. Or better yet, some kind of Plasma widget that sends rain/snow/wind/sunshine/etc. across my desktop depending on what the actual weather is in my area. Anyone heard of something like that? It'd probably have to tie in to accuweather.com or something. Man, that'd be sweet!

Panel widgets

Speaking of desktop widgets, while I haven't even scratched the surface of what Plasma can do, nor of all the thousands of Plasmoids out there, one widget that really bugs me is the clock in the panel. Seriously. What is up with this useless clock? Its only config options are "fonts," "timezone," and "timezone." Oh yes, and "timezone." Is there enough timezone yet? Apparently not. I can't even make it 12-hour, nor display the month/day in the format that I'd like. Even Xfce's not very-click-userfriendly clock at least gives me full display control by offering the time shell codes. Once I learned how they work, I set it up to my liking: %a, %b %d %l:%M%p, which results in Wed, Jan 06 11:47PM. I can't do that in KDE.

Heck, the menu that I get from clicking on the clock widget is not the same menu I get when going to the KDE CC and clicking the time dialog there. That's another HUGE gripe of mine against KDE over the years: so many different menus in so many different places, for the same option or really similar options. What I really don't like is right-clicking an object to see one menu, but then I see a totally different menu when left-clicking it. Oh man, you've just lost a lot of points in your UI design right there. The other thing in KDE that bothers me is the constant renaming of things. It's not always just "Properties" in the right-click menu, nor is it always easily accessible. Sometimes I have to scroll down to hit a horizontal arrow that exposes the "Properties" dialog or whatever it's called.

I don't think this is because it's an add-on application; this is all the stock KDE you get from emerging kdebase-startkde, not some random app from kde-look.org. Shouldn't there be more of a unified, easily accessible user interface? It feels like the right hand's not talking with the left hand throughout the desktop.

Future

Still, I want to press on and learn the system. I want to get through it and use it long enough to really see if it works for me. There's also the school of thought that says that if I have to adapt myself to the tool in order to use it, then the tool itself is broken from the start. Something to think about.

There's also this whole "semantic desktop" framework that's part of KDE. I have no real idea what it is, how to use it, how many resources it consumes, or even if I want it. But it's something I want to try out . . . somehow.

Assuming that I do stick with KDE's foibles'n'gripes and take the time to get over the learning cliff, deal with all the pesky annoyances, and generally persevere . . . I'll need to install more applications to get a useful workspace. If I'm going to take the time to get a good dual-boot desktop environment going, I need something to make it productive. That means music and video players, spreadsheets, word processors, instant message apps, a mail client. (Oh, the horror of migrating yet again, having lived through the Thunderbird -> Claws move). CD players/rippers/burners. Printer utilities. Easy WiFI/networking controls. Power management tools.

All kinds of apps that I have some idea about, but only from "the other side of the fence," things I've only read about in the gtk+ world. On the other hand . . . as long as my existing gtk+ apps are integrated visually into KDE (thanks to QtCurve) and "just work," maybe I don't need to duplicate my entire Xfce environment?

Still, suggestions and feedback are very much appreciated.

In order to properly answer this question, one must first take a look at what the year of 2009 reserved for this young distribution. Born out of Ken Vandine’s desire to follow the GNOME project as close to the upstream source as possible and introduce all the latest and coolest applications out there to the desktop before anyone else, Foresight was for a while synonymous to bleeding edge Linux done right!

Powered by the revolutionary Conary package management system and a small but talented and determined crew of developers, Ken was able to ship a new version of the distribution the same day that a GNOME release was published, a feat that no other distribution was able to keep up, even those enjoying of large hordes of developers and user base. Foresight was the first distribution to include several trend setter applications out there to the default installation, such as Banshee, F-Spot, Tomboy, Gwibber, Pulse Audio, PackageKit, among many others! And since the distribution followed a rolling release cycle, users did not have to wait for a major release in order to get the very latest bits.

Even if DistroWatch’s numbers weren’t impressive, those who took the time to test drive the distribution fell in love with the community, package selection, and most likely the possibilities that the underlying Conary technology provided for those inclined to do a little packaging or package maintenance. If you were a GNOME user/fan and didn’t mind the small sized, hand picked repository of supported packages, then you’d probably feel right at home! Sure there were KDE, Xfce, Fluxbox, Openbox packages available but those were mostly supported by some of the core users who didn’t mind doing the heavy lifting.

Then came 2009 and with it the major financial crisis the shook many companies around the world, creating a massive layoff wave for most of the first quarter. Sadly, approximately 75% of the active developers that comprised Foresight’s core developer base were part of the many casualties, including Ken Vandine, the heart and soul of the distribution! By late February these developers had already joined the ranks of companies such as Red Hat and Novell to do package and kernel management. Ken himself was quickly nabbed by Canonical to join their Desktop Experience Team, concluding then the completely dismemberment of the seasoned Foresight team!

Deprived of its core developers who were now devoting their time to working for their respective new companies, Foresight’s run at being a bleeding edge distribution and being able to keep up with the release schedules of GNOME (and all of its dependencies) quickly spiraled down toward what looked like certain doom. António “Doniphon” Meireles, second in charge of the distribution and holder of all the knowledge related to how all parts worked together became the sole guardian and maintainer of all packages. Have you ever tried to sync up and maintain all the modules that make up the X.org stack by yourself? How about making sure that every single package in the repository is properly compiled and linked to a newer version of Python?

Unfortunately for many of our loyal users expected point releases stopped from happening on time and deadlines were never met. Having been using Foresight Linux as my primary and only distribution for the last 3 years, I myself started to wonder if 2009 would mark the end of it all.

It took a few months for the remaining developers and users to get over the deep scars left from the massive exodus suffered early last year, but our user base proved to be very resilient and new developers stepped up to fill in the gaps. António was still doing the heavy lifting but this new crop of developers took upon themselves to bring the distribution closer to its former shape.

Slowly but surely milestones were achieved and the development branch eventually caught up with the latest GNOME packages. As of 2 weeks ago the development branch was pretty stable and I believe that only a few minor issues with PolicyKit were blocking a new release. Some massive work has also been done to pave down the way for Foresight 3.0, a major move that will allow for a more modular platform that can be used to derive other distributions, leveraging the flexibility and functionality provided by Conary. Moreover, the “Boots” project was kicked off to bring a Fedora based distribution completely managed by Conary, which should free up the time our developers spend maintaining some of the more complex stacks of the operating system and let them focus on making your desktop “freaking cool!”

So to answer the original question posted by Thilo, “is Foresight Linux dead?” I can gladly say “Far from it!” I predict that the Foresight community will rally together in 2010 to get back to being the most GNOMEic and bleeding edge distribution out there! As the Foresight Community Manager I can honestly say that we have always been and will always be a niche distribution! We don’t have the man power that distributions such as Ubuntu, Fedora, Mandriva or OpenSuse have to provide the same level of documentation or user support. We obviously cannot afford to have the same depth of package variety in our repositories or  claim to have the expertise and time to resolve all issues that manage to get filed in our tracking system. But I can guarantee one thing: Foresight is here to stay!

If you want to try a revolutionary package management system and want to be part of a an exciting crew, come hang out with us on #foresight at Freenode. We will help you get started and I promise you that you’ll be able to contribute in no time.

Expect great things from Foresight Linux this 2010!