Xfce

Subdomains
 

Benchmarks: gtk+ engines revisited

  • June 12, 2009
  • Josh Saddler

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?

Recently in Xfce

  • June 11, 2009
  • Jérôme Guelfucci

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...

News Update

  • June 4, 2009
  • Jannis Pohlmann

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.

A new panel plugin

  • June 4, 2009
  • Mark Trompell
I eventually created my first xfce panel plugin. Since foresight started to use indicator-applet and notify-osd, I wanted to have a native plugin to avoid using indicator-applet with xfapplet.
Today, I got it working. For now it's located at the Foresight Linux hg server.

indicate new messagesand show them

It still needs some tweaking, like translating the only string that can be visible and do proper resizing of the icon.
But for now it works. It needs indicator-applet from 0.2 branch.
Concerning Foresight Xfce Edition. It's still on my list, I almost released a set of isos, but I had some issues with them, that need to be solved first. Expect them soonish (as always).

Trip to Barcelona

  • May 24, 2009
  • Jannis Pohlmann

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.

Hands on with ebuilds: Abiword 2.7

  • May 14, 2009
  • Josh Saddler

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

  • May 13, 2009
  • Josh Saddler

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. :D

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. :)

Twitter

  • May 5, 2009
  • Jannis Pohlmann

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

  • May 1, 2009
  • Jérôme Guelfucci

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

  • May 1, 2009
  • Jannis Pohlmann

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.