Xfce News
The little mouse told me...

It feels like I'm finally getting somewhere. My GIO migration branch of Thunar now generates thumbnails using the D-Bus service provided by Tumbler (which is still in development but almost ready for a release). It has no references to ThunarVFS anymore, except for one function required by Thunarx, the Thunar extension library. The next step will be to prepare thunarx-2 with a ThunarVFS-free API. All plugins shipped with Thunar itself need to be updated. ThunarVFS will be moved out of the Thunar tarball and into its own, so that applications depending on it will still work. And then we only need to fork the HAL based volume monitor from GVfs and of course thunar-volman needs to be rewritten on top of GIO ...

Anyway, just a few moments ago, I did something I thought is worth sharing: I browsed one of our servers remotely over SFTP! Mounting still needs to be done from the terminal but after that, you can simply type in the SSH or SFTP URI and it will display its contents. Thumbnails are generated over D-Bus. Here's a screenshot:

Update

Thunar can now mount remote URIs on demand:

FTP browsing also works:

I'm pleased to announce the 1.6.0 release of Xfce4 Screenshooter. This cycle was quite long because I had some exams and the number of implemented features is bigger than usual.

First, there is a brand new interface based on a review by Fabrice Viale : it is simpler and more polished. This new interface also allows you to choose whether the mouse cursor should be captured and whether the application should be closed after taking the screenshot. Here is a screenshot of the application:

It is now possible to save screenshots on any remote share supported by GVFS: ftp, sftp, samba... You just need to connect to a share or a distant computer using Gigolo or gvfs-connect and it will be displayed in the sidebar of the save dialog.

This release also features the possibility to host screenshots online, on ZimageZ. You just need to set up an account on their website and you will then be able to upload your screenshots to ZimageZ directly from Xfce4 Screenshooter. This feature is still a bit experimental and will be improved in the next release: for example accents in the user name or password cause a fail during the upload...

There are also some other small changes which can be found in the changelog. I would like to thank Jannis Pohlmann (for his help concerning jobs and threads), Fabrice Viale (for his interface review), Mike Massonnet and Enrico Tröger (for their various patches) ,Yves-Alexis Perez and Ali Abdallah (for the testing and the suggestions). And last but not least, the translation team who did a great job by adding and updating a lot of translations of the application and of the documentation.

Six months ago I posted some benchmarks of popular gtk+ engines. It's time to revisit those benchmarks and test the engines again, this time using FOSS drivers for my new hardware.

Today I installed my brand-spankin' new graphics card, an ATI RadeonHD 4550, by Sapphire. Getting working 2D acceleration with EXA was a cinch, now that the 2.6.30 kernel is out. Doesn't require anything special in terms of packages; nothing from overlays or bleeding-edge git checkouts. Only needs three ~arch packages: gentoo-sources, libdrm, and mesa.

For this updated round of testing, I used the same gtk+ engines, but also added some new ones. These can all be obtained by installing the following packages: gtk-engines, gnome-themes, gtk-engines-aurora, gtk-engines-candido, gtk-engines-rezlooks, and gtk-engines-xfce. New to the testing list are the Crux, ThinIce, HighContrast, and Redmond95 engines.

Once again, gtkperf-0.40 was used to obtain these benchmarks. With the exception of the graphics hardware and driver, the testing environment is mostly the same. Xfce has been updated to 4.6.1.

Let's see how all these engines perform on my Xfce workstation, eh?

Notes on the hardware:

CPU: Athlon 64 X2 4600+
Graphics: ATI RadeonHD 4550, DVI 1440x900 @ 60Hz
RAM: 4GB DDR2-667
Mobo: ASUS M3N78-VM

Notes on the testing environment:

OS: Gentoo Linux (duh)
Kernel: Linux 2.6.30-gentoo-r1 #1 SMP PREEMPT x86_64
xf86-video-ati: 6.12.1-r1
CFLAGS: -march=athlon64-sse3 -O2 -fomit-frame-pointer
DE: Xfce 4.6.1
- Xfwm4 with Composite enabled, effects: drop shadows & transparency
- Open applications: 2 instances of x11-terms/terminal

Custom themes are noted with *. These are personal themes I've made, nothing more than simple color modifications of an existing freely available theme. No additional images are used, so rendering time should not be affected.

All tests were conducted 3 times, using a Test Round setting of 100. I picked the best score of the 3, as I was looking for best-case usage conditions. The results are ranked in order from fastest to slowest.

Engine: HighContrast
Theme: HighContrast

GtkEntry - time: 0.03
GtkComboBox - time: 0.63
GtkComboBoxEntry - time: 0.46
GtkSpinButton - time: 0.04
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.04
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.08
GtkDrawingArea - Lines - time: 0.91
GtkDrawingArea - Circles - time: 1.21
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.11
---
Total time: 4.70

Engine: Rezlooks
Theme: Rezlooks Blue Ink*

GtkEntry - time: 0.05
GtkComboBox - time: 0.61
GtkComboBoxEntry - time: 0.41
GtkSpinButton - time: 0.05
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.06
GtkCheckButton - time: 0.04
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.07
GtkDrawingArea - Lines - time: 0.94
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.11
---
Total time: 4.72

Engine: Mist
Theme: Mist

GtkEntry - time: 0.03
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.45
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.04
GtkRadioButton - time: 0.10
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.07
GtkDrawingArea - Lines - time: 0.87
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.72

Engine: ThinIce
Theme: ThinIce

GtkEntry - time: 0.03
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.42
GtkSpinButton - time: 0.07
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.07
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.09
GtkDrawingArea - Lines - time: 0.91
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.88
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.72

Engine: Glide
Theme: Glider

GtkEntry - time: 0.06
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.49
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.05
GtkRadioButton - time: 0.14
GtkTextView - Add text - time: 0.20
GtkTextView - Scroll - time: 0.09
GtkDrawingArea - Lines - time: 0.85
GtkDrawingArea - Circles - time: 1.20
GtkDrawingArea - Text - time: 0.87
GtkDrawingArea - Pixbufs - time: 0.14
---
Total time: 4.90

Engine: Redmond95
Theme: Redmond

GtkEntry - time: 0.04
GtkComboBox - time: 0.76
GtkComboBoxEntry - time: 0.57
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.10
GtkCheckButton - time: 0.12
GtkRadioButton - time: 0.13
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.08
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.16

Engine: Clearlooks
Theme: Glossy

GtkEntry - time: 0.02
GtkComboBox - time: 0.77
GtkComboBoxEntry - time: 0.56
GtkSpinButton - time: 0.19
GtkProgressBar - time: 0.12
GtkToggleButton - time: 0.12
GtkCheckButton - time: 0.08
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.10
GtkDrawingArea - Lines - time: 0.95
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.40

Engine: Crux
Theme: Crux

GtkEntry - time: 0.03
GtkComboBox - time: 0.89
GtkComboBoxEntry - time: 0.75
GtkSpinButton - time: 0.14
GtkProgressBar - time: 0.04
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.10
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.12
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.13
---
Total time: 5.46

Engine: Industrial
Theme: Industrial

GtkEntry - time: 0.05
GtkComboBox - time: 1.13
GtkComboBoxEntry - time: 0.54
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.05
GtkToggleButton - time: 0.15
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.07
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.15
GtkDrawingArea - Lines - time: 0.89
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.54

Engine: Aurora
Theme: Aurora

GtkEntry - time: 0.05
GtkComboBox - time: 1.10
GtkComboBoxEntry - time: 0.90
GtkSpinButton - time: 0.20
GtkProgressBar - time: 0.06
GtkToggleButton - time: 0.12
GtkCheckButton - time: 0.08
GtkRadioButton - time: 0.16
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.13
GtkDrawingArea - Lines - time: 0.92
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 6.08

Engine: Pixmap
Theme: Elegant Autumn*

GtkEntry - time: 0.04
GtkComboBox - time: 1.00
GtkComboBoxEntry - time: 0.80
GtkSpinButton - time: 0.15
GtkProgressBar - time: 0.15
GtkToggleButton - time: 0.22
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.23
GtkTextView - Scroll - time: 0.23
GtkDrawingArea - Lines - time: 0.98
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.92
GtkDrawingArea - Pixbufs - time: 0.13
---
Total time: 6.19

Engine: Candido
Theme: Graphite Light

GtkEntry - time: 0.05
GtkComboBox - time: 1.94
GtkComboBoxEntry - time: 1.36
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.17
GtkToggleButton - time: 0.22
GtkCheckButton - time: 0.07
GtkRadioButton - time: 0.09
GtkTextView - Add text - time: 0.22
GtkTextView - Scroll - time: 0.16
GtkDrawingArea - Lines - time: 0.89
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 7.45

Interesting. Six months (and one new graphics card and driver) later, there's been a bit of a shuffle. All engines tested are clustered much closer together. There used to be a 12-second gap between the fastest and slowest engines. Now it's only 3 seconds. Part of that disparity comes from new versions of the engines. Aurora in particular has made phenomenal improvements since 1.4; the numbers you see here are from version 1.5.1. It's no longer at the back of the pack -- last place now belongs to Candido, which is still rather slow, especially in the ComboBox tests.

Curiously, although the completion times are stacked very closely, there seemed to be a general slowdown. While the older gtk+ engines still turn in respectable times, they're not always at the front of the pack. In particular, the Pixmap engine, which has historically had a speedy reputation, is now trailing most other engines. The theme used is extremely simple. I'm not sure what's causing the slowdown here. Perhaps its reputation for speed is no longer deserved; even six months ago it wasn't a standout.

There's no longer an engine that can turn in 3-second completion times; in fact, the four fastest engines all tied at 4.7 seconds. Of the four, Rezlooks is without a doubt the prettiest. Many of the screenshots in my devspace feature Rezlooks themes.

Two of the engines added for this round of benchmarks, Crux and Redmond95, end up in the middle of the pack. They're not particularly fast, nor are they pleasing to the eye. The other two newcomers, ThinIce and HighContrast, distinguish themselves by jumping to the very top of the charts. HighContrast is undoubtedly the ugliest engine presented here, while ThinIce's appearance rather resembles Mist. It's tolerable, but nothing I'd use, personally.

Once again, I'll stick with Rezlooks-based themes, as well as the occasional standout Pixmap or Clearlooks theme such as ClearLUX. ClearLUX in particular is extremely easy on the eyes when doing late-night computer work.

---

But where are the Xfce engine results? Let's take a look . . .

The Xfce engine results baffled me. The completion times varied wildly, everywhere from middle-of-the-road to flat-out fast to back-of-the-pack. So I intermittently benchmarked the Xfce engine for an hour, under varying degrees of desktop activity. Everything from lots of different applications open to a completely blank desktop. I couldn't generate consistent results. So, I decided to close down all applications and run a final series of three tests. Presented here are the slowest and fastest times logged for this series.

Engine: Xfce
Theme: Xfce

Slowest times
GtkEntry - time: 0.06
GtkComboBox - time: 1.18
GtkComboBoxEntry - time: 0.50
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.07
GtkToggleButton - time: 0.08
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.20
GtkTextView - Scroll - time: 0.14
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.94
GtkDrawingArea - Pixbufs - time: 0.15
---
Total time: 5.56

Fastest times
GtkEntry - time: 0.02
GtkComboBox - time: 0.55
GtkComboBoxEntry - time: 0.43
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.06
GtkToggleButton - time: 0.06
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.04
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.12
GtkDrawingArea - Lines - time: 0.86
GtkDrawingArea - Circles - time: 1.19
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.63

Look at that. A completion time of 4.63 seconds, well ahead of any other engine. That's best-case though; it can be almost as slow as the Aurora engine, which is notoriously heavy. The DrawingArea and TextView numbers are fairly static in both sets. Everything else tends to vary widely. No idea why. Perhaps the developers have made some changes under the hood between Xfce 4.4 and 4.6?

This is just a short post with what happened recently in Xfce.

• Xfce4 Power Manager 0.8.0 was released. I did not have time yet to test it, but it looks promising.
• Jannis Pohlmann and Stephan Arts drafted a release process for Xfce. It still needs to be discussed, but it already looks great. Expect some progress on this once the migration to git is done.
• Brian Tarricone worked a lot on the git migration, things are almost settled.
• Jannis Pohlmann is making some awesome progress on Thunar. He developped Tumbler, a D-Bus thumbnailing service based on the thumbnail management D-Bus specification, to replace the old thumbnailing code. A video shows how his first experimental implementation behaves.
• Nick Schermer made a lot of progress on Xfce4 Panel, fixing and lot of bugs and improving performances. His code can be found on git.xfce.org.
• Stephan Arts has improved the git version of Ristretto a lot: it works, supports basic printing and features a new improved user interface.
• It seems that Colin Leroy will be the maintainer of Xfce4 Weather Plugin from now on. Welcome!
• Mike Massonnet rewrote Xfce4 Notes Plugin in Vala, and improved and lot of things at the same time. Expect a release soon.
• Ali Abdallah, the developper of Xfce4 Power Manager, added a new Goodie to the SVN. Parole is a Gstreamer based media player. I did not test it, so I cannot say more...

dh@triple-media.com

Seriously, you are a winner.

A lot of things are going on lately and it turns out I'm way to busy to update my weblog on a regular basis. So, this is just a short post to keep you all updated.

Last two weeks

• I took a new student job at the university, at the Institute of Theoretical Computer Science, which I love most. I'll be working on haplotyping algorithms.
• I went to Barcelona and had a great time at the Ubuntu Developer Summit overall. Stephan and I were very productive. One evening during dinner we discussed our development and release process and later started writing it down. The result is a beautiful document that still needs a bit of polishing. I hope it'll serve as a good foundation for the development and release process of Xfce in the future. Several others commented on it and it looks like we'll give the proposed concept a shot after we've switched to git and all that.
• Even though the week in Barcelona was great for Xfce, I was disappointed with how it went with regards to the cooperation between Xubuntu and Xfce. I talked it through with Stephan and after I got back, I resigned from my position as the Xubuntu Xfce4 Liaison.

At the moment

• I've started to implement the so-called thumbnail management D-Bus specification. My implementation is called Tumbler and it will hopefully start serving thumbnails for other apps soon. I'm planning to use it in Thunar, Stephan has expressed interest in using it in Ristretto and when discussing the specification and the existing hildon-thumbnail implementation, Philip van Hoof told me that Hildon/Nokia might be interested in dropping hildon-thumbnail in favor of Tumbler if it's flexible enough. I'm working on it as much as I can and I'm hoping to do a release within the next few weeks.
• I'm still working on the Transifex installation for Xfce. It's already running but I still need to import all the projects, releases and of course create accounts for maintainers automatically.
• The migration of Xfce to Git is still work in progress. Brian has most of the repository issues sorted out and is now waiting for me to finish the commit mail script. I have two or three possible implementations lying around but I need to have a look at that again.
• Jim needs the documentation repository next week, so I'm about to set it up.
• Our Buildbot server has arrived in Sweden. Today I set up the firewall. Samual is taking care of setting up the Buildbot host VM and other things. We're considering to move a lot of the services not related to development (like the Xfce websites) into separate VMs on that server too, in order to make the current server a development-only machine.

Besides that I'm trying to catch up with the work and personal stuff that piled up while I was away last week. And I really should go and sleep.

Tomorrow afternoon I'll be travelling to Barcelona, where I'm going to spend the week surrounded by hackers from all over the world planning the next release of Ubuntu. I'll meet up with Stephan, Cody, Michael and Steve there to improve Xubuntu but I'll hopefully also run into a few other familiar faces.

During the week I'll do my best in setting up the new Xfce documentation repository based on the discussions we had over the last few weeks. I'll also try to cook up Lunar Linux modules for Transifex so that we'll have it up and running as soon as we switch our repositories over to Git. These are my goals - let's see how far I can get.

I'm hoping for a few very nice couple of days. I've never been south of Germany and it's my first time in Spain ever. As a fortunate coincidence, there's the Champions League final Barcelona vs. Manchester United on Wednesday. Not that I'm much of football fan ... but I like it when people go crazy.

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?

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.

My recently-sent email to the -core and -dev mailing lists:


Hi,

I've enjoyed my time with Gentoo, mostly... But these days I've just got
too demotivated to work on it. I might have stayed if Ken69267 posted me
some Lifesavers, but he didn't.

On a more serious note, the problem seems to be the complete lack of
management in the required places, Gentoo is fast becoming (or more
likely, already is) an anarchic organisation, where it's becoming
nigh-on impossible to keep track of things.

I see a number of issues with Gentoo these days. The lack of a proper
leadership body. Lack of people working together in unison. The tree
needs to be sorted out: we have >16000 packages, and 200-250 developers,
not all of which are ebuild developers) - We're still using CVS, we do
*not* have the manpower to keep all the packages updated properly using
a centralised VCS. If these issues were fixed, I don't know/care how
they do get fixed, but if they were, I might consider coming back.

If you *really* want me to stay/not retire, and attempt to help fix
these issues, then I guess I can do so if enough people request that of
me. But I will do so purely in a "managerial" position, and will do no
ebuild or other such development.

I'll still hang around in various channels and so on and so forth.

Whatever happens, I do apparently maintain a few misc packages, most of
which are low maintenance. Various herds will now need a new lead
(apologies guys), so that will have to be arranged as well. You will
also need to find another slacker to replace me

If there isn't a mass revolt against my retirement, so long, and thanks
for all the fish! Otherwise... We'll see.

Thanks,
welp

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.

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_FAILED errors 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_FAILED is an error type you normally want to display. I think in this case raising a G_IO_ERROR_PENDING would 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 ThunarFile objects 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.

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.

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!

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

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.

      
Excitingly, Xubuntu 9.04 is almost here - only a short few weeks until the release and it seems like we’re already getting some great press for Xubuntu. Today I saw one article from iTWire titled “The best looking Linux is nearly here - and it’s not Ubuntu” which praises Xubuntu for its look and feel. Kudos to Pasi Lallinaho who is responsible for bringing us this cycle’s artwork.

So Woot Woot! Be sure to download Xubuntu 9.04 when it comes out!