Hands on with ebuilds: Abiword 2.7
Note: this post was originally written a few weeks ago, shortly after the Siag Office experiment. Since the draft was written, an Abiword bug has been opened with a different ebuild. Guess I was too slow about finishing up my draft and publishing it. Ah, well. Now you can at least track the progress of the latest Abiword.
After the lengthy but fun entry on working with Siag Office, I've got s'more goodies. It's time to remove more Gnome packages, as I want to have as close to a pure Xfce desktop as possible. Abiword has always been my default word processor, but it has always been burdened with Gnome libraries and other dependencies. The 2.7 development series changes that, removing the need for many Gnome packages.
After reading a comment, I decided to hack up an ebuild for Abiword 2.7.1, the latest developmental release. This is not a stable release; the changes made to the 2.7 series will eventually become the stable 2.8 series. As upstream warns, don't run developmental releases on production servers.
The first step was to copy the latest ebuild, 2.6.8, to my local overlay in /usr/local/portage and renaming it to 2.7.1. The next step was to determine what's changed since 2.6.8.
I took a look through Abiword's ViewVC to see for myself whether or not the pesky Gnome dependencies have been removed or made optional. Seems they have.
I also discovered that there are several totally unnecessary dependencies present in our current ebuilds. Moreover, several configure switches have been renamed from --enable to --with. This means changing the $(use_enable) bits to $(use_with). Also, some switch options have been renamed or removed; there's no more gnomeui or symbol switches, and the printing switch was renamed to print. These were all simple, quick changes to make in the 2.7.1 ebuild. Removing a line here, deleting 3 letters there. Basic stuff.
Another change was getting rid of the xml and expat configure switches, since they're no longer used. While Abiword does use expat, it's already pulled in by libgsf, so we're safe there. Even the internal Abiword documentation notes this in the various configure files, which is why they don't have explicit configure switches any longer.
The longer changes involved studying configure.in to see what it says are the new optional dependencies and adding those as new USE flags within the ebuild. goffice is now optional, and requires an updated version (0.6). So I added an "office" flag to IUSE at the top of the ebuild, and a line to the pkg_setup function:
$(use_with office goffice)
This USE flag can always be renamed later. The important thing is getting the initial functionality in place. It's very easy to add new flags into the Abiword ebuild; it really just requires copying and adjusting the existing USE info.
Once the critical dependencies and versions were sorted out, it was time to update the internals of the ebuild itself.
One of the things that tends to happen when you have a package in the tree for a long time is that cruft from old ebuild versions tends to linger around for a few years. In this case, the ebuild has a few EAPI-1 tidbits like SLOT dependencies, but it also has a lot of leftover baggage from the pre-EAPI days. Part of that includes redundant numbering. There were a lot of specific minimum versions that are completely unnecessary, as the minimum version hasn't existed for a long, long time. So I went through the ebuild and stripped out all the unnecessary versions, leaving just the category/packagename.
Only one package now needs a specific minimum version, gtk+-2.14. Once gtk+-2.12 is removed, then the dependency can be simplified to a SLOT dependency on gtk+:2, to avoid pulling in gtk+-1.x. I did the same SLOT update for the new required version of goffice and for glib-2. All part of the process of updating to the good stuff present in the EAPIs.
With the EAPI-2 update, it's possible to include USE dependencies in ebuilds. This means that you can get rid of hacks like built_with_use, which require a dependency of Abiword (such as Pango) to have been built with the X flag. The whole function to abort the merge if Pango was not built with USE="X" took 4 lines:
if ! built_with_use --missing true x11-libs/pango X; then
eerror "You must rebuild x11-libs/pango with USE='X'"
die "You must rebuild x11-libs/pango with USE='X'"
fi
With EAPI-2, I was able to update the ebuild to this RDEPEND:
x11-libs/pango[X]
Pretty slick, huh?
The next step was to try a test-compile. Run emerge abiword and watch the results.
Hmm, the merge aborts right at the very end. Turns out that the sed scripts carried over from the 2.6.8 ebuild aren't working: they die because the files they worked with no longer exist. Time to figure out where that .desktop file and other stuff have gone.
The first sed script is looking to change some install directories in a nonexistent Makefile. A quick grep through the Makefiles shows that the old change is no longer necessary; nothing has the old incorrect path. This sed script can be commented out.
The second sed script wants to alter the lines in the .desktop file Abiword installs. However, Portage can't find the file to sed, so it aborts the merge. Turns out that Abiword wants to install the file to /usr/share/abiword-2.7/applications/abiword.desktop. That is a nonstandard location, so no wonder Portage can't find it. If it installs here, Abiword won't show up in your desktop menu. The trick is to get Abiword to install its .desktop file to the right location.
Let's review what's happened so far:
1. Create a copy of the latest ebuild to work on.
2. Visit the upstream homepage and changelogs.
3. View the various configure files to determine new dependencies, versions, unnecessary dependencies, optional dependencies, renamed arguments, and the like.
4. Go to work on the ebuild!
a) Hammer out the raw dependency changes.
b) Fix up the USE flags and related functions.
c) Fix up version and SLOT stuff.
5. Give it a test run.
a) Since a couple of minor errors were found, revisit the ebuild. Fix sed scripts.
b) Test it again.
Now Abiword is compiling, installing, and running. The next step is to tidy up the ebuild. This means putting the dependencies and USE flags back into alphabetical order, removing extraneous whitespace, fixing typos present in the original 2.6.8 ebuild, and deleting any unnecessary comments. There's also the small matter of getting the .desktop file to install to the right location . . . call it homework. 
The final step (for me) is to upload the ebuild where you can view it. This ebuild is a working template for the 2.8 releases. I plan to keep tracking it, keeping up with the changes. No more forced Gnome dependencies! Yay!
Of course, I was only able to remove two packages: goffice and libgnomeprintui. Something is still pulling in libgnomecups, libgnomeprint, gnome-keyring, gnome-vfs, and several others. The next thing I'll investigate is all the gtk+ Bluetooth apps lying around. I won't rest in my quest to have a totally lightweight, Gnome-free, Xfce laptop.
* * *
This is a follow-up to my Siag Office experiment:
I've discovered that some of Siag's peripheral programs run in spite of the font errors. xedplus, tsiag, gvu, and xfiler all run. They still display the same font errors in the console output, but at least the application itself works. Though I'm not sure that xfiler is working correctly. It pops up a file browser window, but I can't click on an item to open it. I can select it with the mouse, but to open it I have to hit Enter. Annoying. But at least it does go to that folder, or open the document/picture in the appropriate Siag utility.
I still can't get the word processor or spreadsheet working, and those form the core of Siag Office. Any tips?
Hands on with ebuilds: resurrecting Siag Office
I was poking through the contents of my world file and USE flags the other day, trying to trim down the number of Gnome dependencies present on my Xfce laptop. Abiword is the application that requires all the Gnome stuff. If only it didn't need deprecated libraries like libgnomeprint, the rest of the Gnome desktop wouldn't get pulled in.
So, I started looking around at alternative word processors and office suites. There's always OpenOffice, but I don't really like using something as slow and bloated as OOo even at the best of times. There are some other office packages available, but they're for Qt/KDE. Or they're made of something really icky, like Java. 
And then I found it: Siag Office. This office suite dates back a number of years. It used to be present in Gentoo, actually, but was removed five years ago.
I took a look at the upstream homepage; it still seems to be sporadically developed. Last release was in 2006. I poked around in the documentation, INSTALL, READMEs, and whatnot in the upstream CVS to get a better feel for what's required. Siag mostly relies on little-used X libraries, including old-school Athena widgets and their derivatives. It also has its own expanded widget kit, Mowitz. Siag ain't pretty, though at least it looks better than Motif-based apps. Most importantly, it's reputed to be very fast, needing very few dependencies.
The Portage CVS attic contained outdated ebuilds; the latest Siag release is 3.6.1, and the latest Mowitz release is .3.1. I used the outdated ebuilds as a foundation for creating my own ebuilds. And that's when the trouble, I mean fun, really began.
For starters, the old ebuilds had a lot of cruft leftover from the pre-modular X days. Stuff like virtual/x11, deprecated configure/make functions, unnecessary USE flags . . . even some bad configure switches from when the code did odd things, like --host=${CHOST}. These obvious mistakes required fixing. Then I checked the Getting Siag page to get more of an idea of the current dependencies.
Siag-3.6.1 has build dependencies on gmp, Mowitz, tcl, libXpm, and libXaw. It has optional runtime dependencies for Python, ccmath, and netpbm. The dependency on libXaw may be interchangeable with other Athena widget-compatible libraries. I sent an email upstream to verify this, as comments in the source code give the impression that while Xaw can be used, so can XawM (a variant created by the Siag folks), Xaw3d, and possibly even neXtaw. In my email, I asked specifically about neXtaw, as Mowitz relies on neXtaw. I figure it's best to just use one widget set if possible to give a more unified appearance. Perhaps neXtaw can be used as a drop-in replacement?
Anyway, once the dependencies were updated for the Siag ebuild, it was time to redo the configure/install section. This is actually still a work in progress; I haven't taken the time to really nail down the optional dependencies, add final USE flags, etc. I've been trying to get working ebuilds, not perfect ebuilds. Not yet.
Once the Siag ebuild was working, I moved on to the Mowitz ebuild. This required many of the same fixes that Siag did. The biggest headache, though, was trying to get the Xaw dependency hammered out.
The old version used to be able to use a number of Xaw varieties, same as Siag. However, the latest version seemed to have narrowed it down to either Xaw3d or neXtaw, default is neXtaw. The configure switch --with-xaw3d= should allow for either one, right? The source code comments in the INSTALL file say the same thing. Unfortunately, it doesn't hold up in reality. If neXtaw is not installed, the configure phase will fail, saying it can't find the Xaw implementation (aka neXtaw). I spent an hour throwing Xaw3d and Xaw name/path variants at it before giving in. How ironic that the --with-xaw3d= switch can't actually use Xaw3d. So I let it just run with the default neXtaw, updating the ebuild for this build dependency. Worked just fine. Good thing that neXtaw was never taken out of the Portage tree! The neXtaw ebuild, at least, is up to date.
In my email to the upstream maintainer, I mentioned that the configure and/or documentation is incorrect. Hopefully I'll get a response, but it has been a few years since the code was touched upstream.
Now that I'd hammered out the dependencies for Siag and its two required dependencies (Mowitz and neXtaw), it was time to merge the package. The sourcecode for Siag itself is only abou 1.5MB. That's right, a whole integrated office suite, with word processor, spreadsheet, animation app, file manager, text editor, and previewer . . . less than 2MB. That's quite an accomplishment! Only took a few minutes to compile.
I discovered that Siag is so old that it seems to predate the common .desktop files used to display an application in your program menu, or at least upstream hasn't bundled any. I'll have to write up my own .desktop entries and add in the accompanying installation function into the ebuilds. So I had to use the command line to launch 'em. That's when the biggest issue hit: Siag won't run.
None of the binaries installed can actually run; I have hit upon a rather famous error that dates back to 1998 or so, and has popped up here and there in the intervening decade:
$ siag
Warning: Cannot convert string "-*-helvetica-medium-r-*-*-12-*-*-*-*-*-iso8859-*" to type FontStruct
Warning: Missing charsets in String to FontSet conversion
Panic: can't load any fonts!
I'm not entirely positive what causes this; Google searching has widely disparate bug reports. It's probably something to do with the way pre-modular X did font handling. Siag seems to want to do stuff in certain ways that the old monolithic X did. It may be able to compile against more modern libraries, but whatever it wants to do is too old-school. There's probably some leftover cruft hardcoded somewhere. I just haven't found what, yet.
At least I can see the errors when running the main applications like siag and pw. The animation app, egon, won't even show that much. Just as in the linux.com review, egon simply would not run:
$ egon
Segmentation fault
I'm unable to perform any further diagnosis. I don't have any debug libraries or applications installed on the laptop, and at this point I'm not going to waste any more time on just this one application.
I'll still try to get the rest of Siag running -- there are a few solutions for the runtime font failure, but none of them have worked for me so far. I have not yet given up; I'm still trying to find ways to slim down my laptop, get rid of Gnome dependencies, and lighten up my Xfce environment.
I've put my work-in-progress ebuilds in my devspace. Once again, I should remind you that the Siag ebuild in particular is not yet finished. It'll do the most important things--compile and install Siag--but it's not finished. If you're looking to cut your teeth on some simple ebuild tasks, you're welcome to spend some time in our Gentoo Development Manual and send me a patch. Working with ebuilds really isn't intimidating the way it may appear at first. Mostly, the work just requires time to sort through issues as they turn up. Time, not arcane knowledge of the most secretive inner workings of code.
Also, if you've got any potential solutions to the font startup failure, I'd love to hear from you! This is the last remaining barrier that I know of to getting Siag working. Well, that and setting up Siag to print, as it doesn't have a graphical interface. Instead, Siag needs you to tell it the proper CUPS commandline stuff. Which, again, is just a bit more time and reading the manpage for lpr. Time and reading. That's most of the process. Time, effort, and persistence.
I'm hoping it'll pay off for Siag Office.
I'm on Twitter now. My username is jannispohlmann. I guess I'll be microblogging about software (Xfce!) mostly and post the personal stuff on Facebook were only my friends can read it (hopefully). Follow me if you're interested.
Edit: Ok, I'm also on identi.ca now: identi.ca profile. I'll be forwarding anything from ident.ca to twitter, so you can follow me wherever you want.
Xfce4 Screenshooter news
I was quite busy during the last few days but I found some time to work on Xfce4 Screenshooter. It is now able to upload screenshots to ZimageZ, a free image hosting solution. At the beginning, I was planning to use Imageshack, but the API they provide is not easy to use. Meanwhile, I discovered ZimageZ which I really like: it provides galeries, a clean interface and an XML-RPC API which allowed me to implement the image upload stuff almost easily.
At the moment, things are a bit raw. A(n ugly) dialog pops up asking for your ZimageZ user name and login, an image title and a comment; once you validate it, the upload starts. No progress indication yet. I still need to make everything look more beautiful, to improve the error handling and to document this stuff!
I won't implement any other new features for this release. From now on, I'll focus on getting things usable and good looking.
Another Thunar/GIO Status Update
I'm more or less done with migrating the volume management code in Thunar to GIO. As of today there's not a single reference to ThunarVfsVolume or ThunarVfsVolume manager in Thunar anymore. While that is pretty neat and another thing I can mark as (almost) done, there are a few quirks also:
- There's no way to find out whether a volume is removable or not. Actually, there are APIs for that but they don't seem to yield reasonable results for any of my USB and DVD drives.
- GIO doesn't handle repeatedly issued mount requests too well. If you try mounting a DVD volume several times in a row, you'll end up
G_IO_ERROR_FAILEDerrors exposing private D-Bus error messages. That's nothing the user should be bothered with but unfortunately there's no way to avoid this.G_IO_ERROR_FAILEDis an error type you normally want to display. I think in this case raising aG_IO_ERROR_PENDINGwould be more appropriate.
So what's next? I'll just pick the list from my last post because I'm lazy:
- Move the thumbnail related code into exo.
- Load
ThunarFileobjects asynchronously. This will be a pain. A lot of functions will have to be split up to fit into the asynchronous concept. - Migrate Thunarx to GIO.
- Migrate thunar-volman to GIO.
- Integrate functionality similar to Gigolo (remote/virtual places management) into the file manager.
- Write GNOME-independent GIO extensions for volume management and the trash.
I'm not so sure I want to load ThunarFiles asynchronously. It'll only work in some situations anyway. However, the possibility of the loading process blocking the GUI is quite high, especially with remote mounts. I guess the next thing I'll work on (next week) is moving thumbnailing out of Thunar and into exo.
Oh, by the way, here are some boring stats of my work in the past four weeks:
thunar/Makefile.am | 44 +- thunar/main.c | 8 + thunar/thunar-abstract-icon-view.c | 4 - thunar/thunar-application.c | 655 +++++++-------- thunar/thunar-application.h | 25 +- thunar/thunar-chooser-button.c | 131 +-- thunar/thunar-chooser-dialog.c | 232 +++--- thunar/thunar-chooser-model.c | 450 +++------- thunar/thunar-chooser-model.h | 23 +- thunar/thunar-clipboard-manager.c | 53 +- thunar/thunar-clipboard-manager.h | 3 +- thunar/thunar-create-dialog.c | 155 ++-- thunar/thunar-create-dialog.h | 25 +- thunar/thunar-dbus-service.c | 47 +- thunar/thunar-debug.c | 4 - thunar/thunar-deep-count-job.c | 373 ++++++++ thunar/thunar-deep-count-job.h | 48 + thunar/thunar-details-view.c | 20 - thunar/thunar-dialogs.c | 100 ++- thunar/thunar-dialogs.h | 42 +- thunar/thunar-dnd.c | 21 +- thunar/thunar-enum-types.c | 57 ++ thunar/thunar-enum-types.h | 56 ++ thunar/thunar-file.c | 1455 +++++++++++++++++++++++-------- thunar/thunar-file.h | 309 ++----- thunar/thunar-folder.c | 192 +++-- thunar/thunar-gio-extensions.c | 355 ++++++++ thunar/thunar-gio-extensions.h | 63 ++ thunar/thunar-gtk-extensions.c | 4 - thunar/thunar-icon-factory.c | 13 +- thunar/thunar-io-jobs-util.c | 139 +++ thunar/thunar-io-jobs-util.h | 36 + thunar/thunar-io-jobs.c | 1074 +++++++++++++++++++++++ thunar/thunar-io-jobs.h | 54 ++ thunar/thunar-io-scan-directory.c | 123 +++ thunar/thunar-io-scan-directory.h | 37 + thunar/thunar-job.c | 1001 +++++++++++++++++++++ thunar/thunar-job.h | 112 +++ thunar/thunar-launcher.c | 521 +++++++----- thunar/thunar-list-model.c | 155 ++-- thunar/thunar-location-button.c | 29 +- thunar/thunar-location-buttons.c | 31 +- thunar/thunar-location-entry.c | 151 +++- thunar/thunar-marshal.list | 4 + thunar/thunar-metafile.c | 42 +- thunar/thunar-metafile.h | 5 +- thunar/thunar-path-entry.c | 65 +- thunar/thunar-permissions-chooser.c | 263 +++--- thunar/thunar-preferences-dialog.c | 103 +-- thunar/thunar-preferences.c | 71 +- thunar/thunar-progress-dialog.c | 152 ++-- thunar/thunar-progress-dialog.h | 7 +- thunar/thunar-properties-dialog.c | 108 ++-- thunar/thunar-renamer-dialog.c | 20 +- thunar/thunar-renamer-model.c | 11 +- thunar/thunar-sendto-model.c | 196 ++--- thunar/thunar-shortcuts-icon-renderer.c | 45 +- thunar/thunar-shortcuts-model.c | 433 +++++----- thunar/thunar-shortcuts-view.c | 594 +++++++++---- thunar/thunar-simple-job.c | 223 +++++ thunar/thunar-simple-job.h | 64 ++ thunar/thunar-size-label.c | 81 +- thunar/thunar-standard-view.c | 212 +++--- thunar/thunar-templates-action.c | 7 +- thunar/thunar-text-renderer.c | 19 - thunar/thunar-transfer-job.c | 888 +++++++++++++++++++ thunar/thunar-transfer-job.h | 60 ++ thunar/thunar-trash-action.c | 9 +- thunar/thunar-tree-model.c | 280 ++++--- thunar/thunar-tree-view.c | 730 ++++++++++------ thunar/thunar-user.c | 833 ++++++++++++++++++ thunar/thunar-user.h | 88 ++ thunar/thunar-util.c | 105 ++- thunar/thunar-util.h | 16 +- thunar/thunar-window.c | 274 +++--- 75 files changed, 10491 insertions(+), 3947 deletions(-)
The overall size of the patch is 844kb already.
Desktops, etc.
Man, it's been awhile since I blogged. I meant to keep putting up a monthly Xfce desktop, share some tips, talk about the latest Gentoo work, etc. And then real life got in the way.
Laptop
I killed yet another piece of hardware when updating my Thinkpad R61i on Friday. I've been sick this whole week, so I had some free time. The laptop hadn't been updated since early February, so there were 176 packages, including the big move to GCC 4.3, which necessitated a system rebuild. Unfortunately, I left the battery in while the system was on AC power for the compiling work. I guess the heat must have built up too much, because the battery got fried. Got the dreaded "battery light flashes amber rapidly" error. So now I only have the extended-life battery, which is heavier and bulkier.
Add that to the list of hardware that compiling Gentoo has killed over the years. The list includes another battery, an external power brick, an internal PSU, two motherboards, two RAM sticks, one RAM slot, two hard drives, and a fan. I'm really on a roll, here.
I still can't find a replacement battery for less than $90, even on eBay, so I may hold off. What I did do was order two more gigs of RAM, to bring the total up to 4GB. Only cost $40 at Amazon, free shipping. Why the RAM? While updating, I ran into the dreaded OOM-killer! The GCC 4.3 compile uses more than the 2GB available and it aborted the merge. This was with nothing else running, too. So be warned: if GCC dies when you move to 4.3, back off on your MAKEOPTS. I had to adjust mine from -j3 to -j2 while compiling GCC and glibc.
Also, while I was updating my whole system, I decided to move the rest of my X/kernel stack to ~arch, as I wanted the new Intel KMS/GEM/UXA hotness. This necessitated using ~arch xf86-video-intel and Mesa, as well as ~arch gentoo-sources, as 2.6.29 has some needed code not present in 2.6.28. I discovered that while this part of the graphical stack was just fine for KMS and fast graphical login, xorg-server-1.5.3 resulted in hard lockups as soon as I opened any windows. I had to grab xorg-server-1.6, libXfont, and randrproto from the X11 overlay in order to get a usable environment. It works great! No more lockups.
So, how much of an improvement is the new stack over what was available in February? I'll let the following numbers speak for themselves. These are the median-high numbers recorded. For the old stack, the numbers varied from 48FPS to 59FPS. For the new stack, from 489FPS to 504FPS. Sync to vblank and vsync have never been enabled.
xorg-server-1.5.3-r1, libdrm-2.4.4, xf86-video-intel-2.6.1, mesa-7.3, gentoo-sources-2.6.27-r8
$ glxgears Failed to initialize GEM. Falling back to classic. 292 frames in 5.0 seconds = 58.272 FPS
xorg-server-1.6, libdrm-2.4.6, xf86-video-intel-2.6.3-r1, mesa-7.4, gentoo-sources-2.6.29-r1
$ glxgears 2516 frames in 5.0 seconds = 503.174 FPS
Now, the usual caveat about glxgears not being a good benchmarking tool applies here. However, it is useful for relative comparison from one version to the next. And as you can see, it's an order of magnitude better. I notice that stuff is drawn much smoother; there's less flickering especially when shifting Terminal windows around. And I haven't hardly begun to tweak my system for best UXA performance. KMS is nice and smooth; it happens pretty quick in the boot process. No more flickering, just fast loading of SLiM and then Xfce.
My xorg.conf is pretty minimal; the only changes I've specified for the Intel driver section are these:
Option "FramebufferCompression" "false" Option "AccelMethod" "UXA" Option "Tiling" "false" Option "EnablePageFlip" "true"
There are probably some other things I should add for maximum performance, so I'll have to spend several more days hunting for 'em. But out-of-the-box, I'm extremely impressed with the current X stack.
Now all I need is smooth full-screen Flash video performance . . .
Xfce 4.6
The other thing I put on the laptop was Xfce 4.6.1. Decided that as long as my core graphics stack is part ~arch, it wouldn't hurt to try out the latest and greatest Xfce hotness. Now that some outstanding bugs were fixed from 4.6.0 (including a remote security bug, and an icons issue), I thought it'd be worth it. It's pretty slick. The desktop environment is initialized a bit faster than even a fully tweaked 4.4.3.
About the only outstanding issue I have with it is that there is no graphical menu editor. At first, I couldn't get a satisfactory menu even editing the XML file by hand; it was just too different from the old one. So my menu was cluttered with useless toplevel entries, such as Web Browser, File Manager, and so on. Fortunately, Mike pointed me to the solution, so now all offending stuff has been cleared out. Right now my menu works just fine, so I only really need a graphical menu editor for convenience's sake.
I really like 4.6 a lot. The artwork packaged with it is outstanding; I'm using one of the stock backgrounds because it's just that sexy.
Xfce 4.6 is a smash hit, so well done, guys. Very well done. And there's even more good stuff planned for the future. There's a great interview on Planet Xfce with one of the core developers. He discusses some of the exciting stuff coming down the pipe for Thunar, so make sure to read it.
Gentoo
I've been rather quiet on the Gentoo front for the last three months, because life in the outside world has a way of unexpectedly intruding on me. I've been on devaway since February while I try to get stuff into some semblance of order. Sadly, however, I've had to do much more documentation work than I originally scheduled, which keeps cutting into my plans for other areas. I've made a bunch of bugfixes and commits over the last couple of weeks especially. One of the most visible changes is in the Get Gentoo page, putting the automated weekly builds at the top. The handbooks will be updated, too, but they require a tremendous overhaul, so I'll need all the resources of my fellow GDP members to accomplish that. If I can get 'em, that is.
One of the other things I like to do is find some interesting little-known application, determine its usefulness, then hack up an ebuild for it. It's really good practice, actually.
Out of all the applications I've written and updated ebuilds for, the only one that's got me stumped is WordGrinder. I've been in contact with WordGrinder's upstream author, who's a really helpful guy, but I still can't get the ebuild working. While compiling and installing by hand works great, something happens during the compile phase as run by Portage where it violates the sandbox, killing the merge.
Plus, given the pmfile used by the package, it doesn't really respect a user's CFLAGS/CHOST and related configuration. That has to be altered somehow, so I've been trying to work out a similar solution to the one used by our dev-lang/lua ebuilds. No real luck there, but it's not my first priority. What I really want to do is have the merge workin' with Portage. So it's an interesting, informative, occasionally frustrating learning process.
Anyway, take a look at all the stuff in there. I recently reorganized the ebuilds by category/package, instead of dumping everything into a single directory. Some of these have since moved into Portage sometime after I wrote the ebuild for 'em, and some (like Songbird and WordGrinder) are works in progress. I've run into quite a few nifty apps; places like GnomeFiles are excellent resources. Most of the stuff in here I discovered on GnomeFiles, and a lot of the packages on the website are simple enough that it's just a few minutes' work to hack up an ebuild.
Thunar/GIO – Quick Status Report
I've started hacking on the migration of Thunar to GIO on April 9th. In about 61 commits, I've reduced the original number of ThunarVFS references in the Thunar source code dramatically. The most important and probably most time-consuming part of this work is only mentioned briefly on those pages: rewriting all recursive copy/move/trash/restore/chmod/chgrp/chown jobs -- by now most of the jobs have been rewritten based on GIO and the new ThunarJob framework ... and Thunar still works (for me at least)!
All in all, I suppose that about a third of the implementation work is done. Ok, maybe just a quarter, but an important one. I now have a very good overview over the source code and I'm almost done with one of the most critical parts of the migration.
If you want to know how that looks like for me, here's a screenshot:
These are the most important/big things that are still waiting for me:
- Replace ThunarVFSVolumeManager with GFileMonitor. Volume management is a large and complex subsystem of both ThunarVFS and GIO.
- Load ThunarFile objects asynchronously. This will be a pain. A lot of functions will have to be split up to fit into the asynchronous concept.
- Move the thumbnail related code into exo
These two are a bit out of scope but very important nonetheless:
- Integrate functionality similar to Gigolo (remote/virtual places management) into the file manager.
- Write GNOME-independent GIO extensions for volume management and the trash.
On a side node: Xubuntu 9.04 is available as of today! Go and grab it if you're interested in a nice distro based on Xfce. If you're interested in the Xubuntu development, you'll be able to meet Stephan, several Xubuntu folks and me at the Ubuntu Developer Summit in Barcelona from May 25th-29th. I'm very excited already!
Xfce Clipman Plugin 1.0.0
This post is about the latest release of Xfce Clipman Plugin, a Clipboard Manager for the Xfce desktop. I turn it more technical than for end-users. I hope people interested into GTK+, GObjects or Xfce panel plugins will like to read it. The release is going to happen very soon now.The first major change concerns the plugin being entirely rewritten by using GObjects and Xfconf, this means cleaner, better understandable, maintainable code, etc. There is the "main function" (for sack of clarity) and four objects. A collector which listens to clipboard changes and put them in the history, the history is also an object, a menu (on top of GtkMenu) that displays the history and allows to clear it, and finally another object which is part of a new feature for the clipboard manager.
Now having my objects it's just about instantiating them in the main function and binding them to Xfconf. If there is something missing in an object it is just about modifying a particular aspect of it.
The goal of using Xfconf is to have a less cluttered code for settings, and to make good use of property bindings against the objects. For instance, the object History has a maximum count of items, and being bind against Xfconf, it is possible to run an external command with xfconf-query to change that setting, without having to call a public setter function. Binding a property is a one function call.
Following this major change is the settings dialog. I have written it from scratch with Glade, a UI designer for GTK+, by which I can easily modify and beautify the dialog without having to fight with lines of code several hours a day. In fact it takes a few seconds to change a label and up to 5 minutes to design a goddamn dialog. Glade makes an increased use of memory however, but stop thinking of this when you know you have 1MB times 1000 installed on your system — I have currently 1GB on a netbook and 2GB on a quite-fanless Atom-based workstation but I use only around 300MB in general. If you still fear about having an application that uses only 2 but 5MB with Glade, well I can't help you! From what I have read, the built-in UI designer of GTK+, named GtkBuilder, needs less memory, but the Glade to GtkBuilder conversions are going to happen with Xfce 4.8.
Now about the new feature introduced into this major release. It is called "Actions" which is the fourth object by the way. An action is a match between a text selection and regexes to let you execute specific commands. For example the action "Image" can match text with image filenames and let you choose commands between "View with Ristretto" and "Edit with Gimp". I wrote something simple in the settings dialog to add new actions that is inspired from the Thunar User Custom Actions interface.
Finally, I made other changes that are more geeky than useful, like I made a bundle out of the plugin. The plugin is now installed under the binary directory instead of the common place holder for panel plugins but can still be added inside a panel with the "Add Item" menu action. As you might understand, it can be executed as well now, and if you do so it will run inside the notification area. An item is installed in the applications menu to be able to start it (under the category Utility), and as it is possible to run outside the panel, I added a autostart file.
That's it already. If you have questions, don't mind. If you wanna discuss the Actions/regex feature go ahead. More importantly, I hope you'll take a glimpse at the code.
If you are interested into panel plugins, have a look at the wiki. The panel plugins amongst the goodies are a good way to get to know code and start with something.
Update: ANN: xfce4-clipman-plugin version 1.0.0 released
Xfce developers, Jannis Pohlmann
Jannis Pohlmann, one of the core Xfce developers, kindly accepted to answer my questions on his involvement in the Xfce project and his plans for Xfce 4.8. Thank you for the time you gave Jannis!
Could you please introduce yourself?
I'm Jannis, an almost 24-year-old computer science student living in Lübeck, Germany. Besides hacking on Xfce in my free time, I am 100% addicted to music. I listen to Black and Doom/Stoner/Post Metal mostly and played drums and bass in two local bands until recently. I also had a darkroom and created b/w photographs for a few years but somehow I've lost touch with that.
Anyway, summer lurks around the corner and that means a lot of sunny days with barbecues and relaxing at the beach ahead of us. Enjoying those days could also be seen as some kind of hobby ... maybe 
What is your role in the Xfce community?
I'm the current maintainer or co-maintainer of several core components of Xfce, like the mixer, the menu library and Thunar. I also administrate the Goodies project which is our platform for Xfce extensions and programs which are not part of the core desktop. Not to forget, I am the so-called Xubuntu Xfce4 Liaison which means that I'm the main mediator between Xubuntu and Xfce.
What did you work on for Xfce 4.6?
Way too much . I wrote libxfce4menu, a library for displaying installed applications in a structured fashion, based on the
freedesktop.org menu specification. I also rewrote the mixer on top of GStreamer and the application finder, based on a re-design Jasper Huijsmans (the former panel maintainer) came up with. Last but not least, I did a lot of work on the 4.6 settings dialogs, mainly xfwm4 and the keyboard stuff, and of course fixed bugs where I could.
What do you think about Xfce 4.6? Are you pleased with? What do you think could be improved?
4.6 is a great release in many ways. Several neglected components have been rewritten, improved or replaced. With xfconf and the improved session manager Xfce as a platform has definitely gained potential. We've received a lot of overwhelming feedback and press for the release.
I see 4.6 more as an intermediate release though. By introducing xfconf and libxfce4menu we've changed a lot of the underlying infrastructure. So much in fact that the release was delayed for more than six months. As a result, there is a number of very young features in 4.6 which give the release a bit of an experimental touch. A lot of things need more polishing. And, as usual, there are also a few issues for which we don't have a solution yet.
What are you going to work on for Xfce 4.8?
Keeping in mind that our goal is to have a shorter release cycle (we've had ~10 months in mind but we haven't really made any plans yet ... that's just typical for us ...), I'll mostly concentrate on Thunar and libxfce4menu. I am currently migrating Thunar to GIO which I'll hopefully finish in time for 4.8. libxfce4menu is lacking menu merging support in 4.6 and is undergoing a redesign at the moment. Last but not least, the mixer panel plugin needs some love.
What is GIO and what is the aim of porting Thunar to GIO?
GIO is a filesystem abstraction layer. It provides a high-level API to accessing directories, files and volumes. It's been part of GLib since 2.16. Thunar has something similar called ThunarVFS which is in some aspects less powerful than GIO.
Migrating Thunar to GIO has several reasons: ThunarVFS is an additional library in the stack while GIO is part of GLib already. Dropping ThunarVFS means less maintainance work for us. And, as already mentioned, GIO has features that ThunarVFS does not have.
The personal goal I have is to write a so called "Studienarbeit" about the migration. That's an around 30 pages thesis students have to write at German universities as a preparation for the real diploma thesis (which is an equivalent to the master's thesis). The process can be followed on my wiki.
What features will this bring for users?
GIO itself will not bring any new features. However, GIO can be extended easily to support virtual/remote filesystems. There is a set of extensions called GVfs which supports SFTP, HTTP, FTP, SMB and other protocols. Unfortunately it has a few GNOME dependencies, so it is up to you to decide whether you want to use it. People could as well write their own extension for whatever protocol they need - if they want to.
What will be the influence on performances?
I know that many people fear bloat. GIO is already being used by GTK+, so by dropping ThunarVFS we can probably make Thunar even lighter than it is today. As opposed to ThunarVFS, GIO has an asynchronous API which may help in making Thunar more responsive in some situations.
Do you plan to implement new features apart from the GIO related ones?
Definitely. Not too many though. Migrating Thunar to GIO is a lot of work on its own already. My plans include a shared progress dialog for file operations, a more user-friendly side pane, inspired by this post from Hylke and a user-friendly way to manage "places" (such as remote locations).
What does GDesktopmenu (previously known as libxfce4menu) provide?
libxfce4menu (or gdesktopmenu in the future) is an implementation of the freedesktop.org menu specification. It provides applications with an easy way to list all installed applications in a structured manner, like for the applications menu.
What are your plans for Xfce 4.8? Will users be able to customize their menu easily?
Yes. As mentioned earlier libxfce4menu in 4.6 lacks support for menu merging which is an essential feature required by menu editors. In 4.8 this will be fully supported.
I'm now working together with Travis Watkins from Alacarte who has expressed interest in the 4.8 API I presented on my blog a while ago. We're planning to add a nice menu editing API to the library so that it'll be *very* easy to write menu editors. It looks like Alacarte will be the first editor to use it.
Any others future plans ? Something else to add ?
Yeah. Thanks again to everyone who donated money for our Buildbot server! We're currently waiting for the missing components to arrive so that we can set it up. Samuel Verstraete, together with the Coreboot team, did a great job in getting hardware virtualization to work on the server, so we'll hopefully see Buildbot running very soon.
Edit: sorry, I found forgotten a question which I just added.
Xfce 4.6.1 to be released soon
Stephan Arts started to tag Xfce 4.6, this bug fix release should be available in the next few days.
This release fixes a lot of bugs introduced in Xfce 4.6 and also comes with updated/improved translations.