Benedikt Meurer

A new approach to Function.prototype.bind

2015-12-25T00:00:00+00:00

The performance and compatibility of Function.prototype.bind and the resulting bound function objects has traditionally always been an issue in V8 (and thereby in Chromium based browsers and Node.js driven servers).

Consider the following simple test driver, which defines a (non-trivial) test function foo and creates two bound functions foo1 and foo2 based on it, which both bind the receiver and the first argument to some primitive.

"use strict";
function foo(x, y, z) { return this + x + y + z }
var foo1 = foo.bind(1, 0);
var foo2 = foo.bind(2, 1);
function test() {  // Performance test.
  var sum = 0;
  const limit = 1000;
  for (var y = 0; y < limit; ++y) {
    for (var z = 0; z < limit; ++z) {
      sum += foo1(y, z) + foo2(y, z);
    }
  }
  return sum;
}
for (let i = 0; i < 10; ++i) test(); // Warmup first.
var startTime = Date.now();
for (let i = 0; i < 10; ++i) test();
var endTime = Date.now();
print("Time: " + (endTime - startTime) + "ms.");

Now running this program with V8 tip-of-tree as of today requires a whopping 12,078ms to execute the test loop on a HP z620 work station running Ubuntu 14.04. Looking at the performance profile, almost all the time is spend in the boundFunction builtin (and the associated helper runtime functions) that acts as a trampoline for bound functions. Looking closely into that function, we see that on every possible [[Call]] path through the function (the [[Construct]] path uses the %NewObjectFromBound C++ builtin), we bailout to C++ at least twice, once into %BoundFunctionGetBindings, which returns a new Array with the bound target function, the bound this and the bound arguments, and once into %Apply, which calls back into JavaScript to execute the actual target function with the actual parameters.

Calling into C++ is certainly not fast in V8, but calling back from C++ into JavaScript is very expensive. Also building one or two temporary Arrays on every invocation of a bound function is not cheap, and can cause unnecessary GC traffic. So, there's a lot of room for improvement here. I've been working on a new approach to implement Bound Function Exotic Objects in V8 for a few months now, as part of a bigger project to fully support objects with [[Call]] and [[Construct]] internal methods that are not ECMAScript Function objects, i.e. to support Proxy Objects. After a lot of yak shaving, I now reached a point where I'm close to landing my new baseline implementation for Function.prototype.bind.

Running the test program above with my patch requires 239ms for the test loop, which is already a 50x improvement. There's still some more cleanup to be done in order to land the patch (i.e. some API functions seem to require additional work to deal properly with the new representation of bound function objects), but the baseline results are already very promising. Once the baseline implementation is stabilized, we can start looking into optimizing bound functions, i.e. enable inlining of bound functions - which should boost this particular case to 100x improvement - and properly collecting and dealing with bound function type feedback.

I hope that this will in particular help web sites and web apps using React, because React makes heavy use of Function.prototype.bind. But for React we will also need to look into the performance of Function.prototype.bind itself and not only the throughput of bound functions, in order to reduce latency and startup time.

JetStream performance results

2015-04-14T00:00:00+00:00

The V8 team has been working hard on improving JavaScript performance recently, where performance means both peak performance (as in throughput of long running computations) as well as user visible latency (as in time wasted not doing useful work towards completing a computation or rendering a website).

It is not always easy to improve both throughput and latency, especially since it usually introduces latency to generate the perfect code for optimal throughput. So there's always a trade-off to consider. Also the existing benchmark suites used to focus on either latency (i.e. the SunSpider 1.0.2 JavaScript Benchmark) or throughput (i.e. our own Octane benchmark), but not both.

Apple tried to address this problem by introducing a new benchmark suite that aims to combine latency and throughput benchmarks with roughly equal weighting, the JetStream benchmark suite. It contains benchmarks from both SunSpider and Octane, but also additional interesting benchmarks, like various Emscripten compiled C/C++ programs.

So JetStream seems to be a good candidate to measure our progress on improving overall performance of Chrome/V8 (considering both throughput and latency). As you can see from the chart below, we have been doing well pretty lately. Chrome 44 (current canary build) beats both Firefox and Safari, and we're working on reducing the latency further for the next release. The numbers were measured on a MacBook Pro (Mid 2012 / 2.3 GHz Intel Core i7 / 16 GB) running OS X 10.9.5.

Cross-compiling V8 for the Raspberry Pi

2013-08-25T00:00:00+00:00

The Raspberry Pi is probably the most popular Linux ARM device nowadays (not including the ARM based Android smartphones and tablets) and V8 is the most popular JavaScript engine, so chances are you may want to run (a recent version of) V8 on the Raspberry Pi. Building on the device is an option, but that takes ages. So you will probably want to cross-compile V8 on your powerful Linux workstation instead.

To do this for Raspbian, you'll need to install the cross-compile toolchain first (see this guide for detailed instructions). Assuming that you installed the tools to $HOME/Applications/rpi/tools, run the following command from your V8 checkout:

$ make AR="$HOME/Applications/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-ar" CXX="$HOME/Applications/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++" LINK="$HOME/Applications/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++" armv7=false armfloatabi=hard arm

This will build a debug version of the V8 shell in out/arm.debug/d8 and a release version in out/arm.release/d8.

How to fix the hostname of your Strato V-Server

2012-04-26T00:00:00+00:00

The Strato Linux V-Servers always reset their hostnames to hXXXXXX.stratoserver.net on boot, no matter what you put in /etc/hostname and there's no way to fix this (it's actually intended behavior). If you happen to have a Strato V-Server running Debian, here's a simple failsafe way to fix the hostname early during boot and have all daemons use your desired hostname.

Assuming that your desired fully qualified hostname is www.example.org, then create a new file /etc/init.d/strato-hostname-fix.sh with the following content

#! /bin/sh
### BEGIN INIT INFO
# Provides:          strato-hostname-fix
# Required-Start:       
# Required-Stop:        
# Default-Start:     S  
# Default-Stop: 
# X-Start-Before:    hostname
# Short-Description: Fix the Strato overwritten hostname.
# Description:       Fix the hostname in /etc/hostname and /etc/hosts that
#                    was previously overwritten by the Strato V-Server.
### END INIT INFO
        
PATH=/sbin:/bin
  
. /lib/init/vars.sh
. /lib/lsb/init-functions
        
do_start () {
        sed -i \
                -e 's/h[0-9][0-9]*/www/g' \
                -e 's/stratoserver\.net/example.org/g' \
                /etc/hostname \
                /etc/hosts
        exit $? 
}       

case "$1" in
  start|"")
        do_start
        ;;
  status|restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
  stop) 
        # No-op
        ;;
  *)    
        echo "Usage: strato-hostname-fix.sh [start|stop]" >&2
        exit 3
        ;;
esac    

:

and setup the script using the following command:

$ sudo insserv /etc/init.d/strato-hostname-fix.sh

Afterwards just reboot the machine. The above was successfully tested with Debian 6.0.4 (squeeze), and should also work with recent Ubuntu versions.

arm-linux-gnueabi cross compiler for OS X

2011-12-04T00:00:00+00:00

I spent some time getting a decent cross compiler toolchain for arm-linux-gnueabi running on Mac OS X, including GNU binutils 2.22, gcc 4.6.2 and OCaml 3.12.1. The cross compiler toolchain targets ARM boards running Debian/armel squeeze or later.

The stuff is available from my local MacPorts repository. To get it working on your Mac, make sure to update to the latest MacPorts first, using:

$ sudo port selfupdate
$ sudo port upgrade outdated

Continue by cloning my MacPorts repository and editing the MacPorts sources.conf file (as superuser):

$ git clone git://github.com/bmeurer/MacPorts.git
$ cd MacPorts/ports
$ sudo vim /opt/local/etc/macports/sources.conf

Add a new line to the file before the line with the [default] tag

file:///path/to/MacPorts/ports [nosync]

where /path/to/MacPorts is the path to the MacPorts repository clone. Once done, run

$ portindex

in the MacPorts/ports subdirectory to add the ports from my local MacPorts repository to the list of available ports (remember to rerun portindex everytime you pull from my repository). Now you can continue installing the cross compiler ports, using either

$ sudo port install arm-linux-gnueabi-gcc

to install just the binutils, gcc and the basic runtime, or

$ sudo port install arm-linux-gnueabi-ocaml-compiler

to also install the OCaml cross compiler and its runtime. Installing the toolchain will take some time depending on the available bandwidth and the overall speed of your machine.

Once done, your new cross compiler will be ready in /opt/local, with its system root in /opt/local/arm-linux-gnueabi/sysroot and related tools in /opt/local/bin, prefixed with arm-linux-gnueabi-, i.e.

$ arm-linux-gnueabi-as --version
GNU assembler (MacPorts 2011/12/02) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-linux-gnueabi'.

$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (MacPorts 2011/12/02) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ arm-linux-gnueabi-ocamlopt -config
version: 3.12.1
standard_library_default: /opt/local/arm-linux-gnueabi/sysroot/usr/lib/ocaml
standard_library: /opt/local/arm-linux-gnueabi/sysroot/usr/lib/ocaml
standard_runtime: /opt/local/arm-linux-gnueabi/bin/ocamlrun
ccomp_type: cc
bytecomp_c_compiler: arm-linux-gnueabi-gcc -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -fPIC
bytecomp_c_libraries: -lm  -ldl -ltermcap -lpthread
native_c_compiler: arm-linux-gnueabi-gcc -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT
native_c_libraries: -lm  -ldl
native_pack_linker: arm-linux-gnueabi-ld -r  -o 
ranlib: arm-linux-gnueabi-ranlib
cc_profile: -pg
architecture: arm
model: default
system: linux
asm: arm-linux-gnueabi-as
ext_obj: .o
ext_asm: .s
ext_lib: .a
ext_dll: .so
os_type: Unix
default_executable_name: a.out
systhread_supported: true

To help with cross compilation of OCaml projects using ocamlfind, the arm-linux-gnueabi-ocaml-compiler port also installs a custom ocamlfind configuration file /opt/local/etc/arm-linux-gnueabi-ocamlfind.conf, which you can use to utilize the cross compiler toolchain by setting the environment variable OCAMLFIND_CONF to point to this file.

Red-Black Trees for OCaml

2011-10-16T00:00:00+00:00

I decided that it was about time to get used to OASIS, that new all-in-one build system generator for OCaml projects. So I started by getting it up and running using various local MacPorts. Once everything was up and running, I started to switch my implementation of Red-Black Trees for OCaml to use OASIS instead of my custom Makefile-based approach. That went amazingly well, and so here's my first release, version 0.1.0, of ocaml-rbtrees featuring an OASIS-generated build system.

Download: https://github.com/downloads/bmeurer/ocaml-rbtrees/ocaml-rbtrees-0.1.0.tar.gz

Git repository: https://github.com/bmeurer/ocaml-rbtrees

For those of you using MacPorts on Mac OS X, ocaml-rbtrees 0.1.0 is also available from my local MacPorts Portfile repository as caml-rbtrees.

Towards a native toplevel for the OCaml language

2011-10-06T00:00:00+00:00

This paper presents the current state of our work on an interactive toplevel for the OCaml language based on the optimizing native code compiler and runtime. Our native toplevel is up to 100 times faster than the default OCaml toplevel, which is based on the byte code compiler and interpreter. It uses Just-In-Time techniques to compile toplevel phrases to native code at runtime, and currently works with various Unix-like systems running on x86 or x86-64 processors.

http://arxiv.org/abs/1110.1029

Patent Evil

2011-10-06T00:00:00+00:00

How the Patent War is Stifling Innovation in Silicon Valley.

Created by: MBA Online

Native toplevel test release 3.12.1+ocamlnatjit2

2011-10-06T00:00:00+00:00

After several additional hours of testing and bugfixing it was time for another test release of our new OCaml native code toplevel ocamlnat. The test release includes a fully featured OCaml 3.12.1 distribution plus our new toplevel ocamlnat, which is up to 100 times faster than the byte code toplevel. See the website for installation instructions and additional information.

Website: http://benediktmeurer.de/ocaml-experimental

Download: http://benediktmeurer.de/files/source/ocaml-3.12.1+ocamlnatjit2.tar.bz2

Git repository: https://github.com/bmeurer/ocaml-experimental

OCamlNat benchmark

2011-09-14T00:00:00+00:00

Now that we have working versions of our new native OCaml toplevel ocamlnat without toolchain dependencies for both i386 and amd64, I decided to run a few benchmarks, comparing our ocamlnat to OCaml 3.12.1 (both the byte code toplevel and the ocamlnat that silently ships with 3.12.1) and to our byte-code just-in-time compiler OCamlJIT2.

The benchmarks used are test programs from the testsuite/tests folder of the OCaml 3.12.1 distribution. They do more or less represent typical OCaml applications. The almabench, fft and nucleic programs are floating point benchmarks, quicksort and sorts are sorting algorithms, and the remaining are miscellaneous benchmarks. The programs were run on different platforms, measuring the combined user + system time for the process itself and all its child processes (only relevant for the old ocamlnat which invokes toolchain programs).

Below is the resulting speedup of the different toplevels compared to the ocaml byte code toplevel, with OCamlNat/ext being the old ocamlnat with the toolchain dependencies that ships with OCaml 3.12.1 and OCamlNat/jit being our new implementation available from the ocamlnat-jit branch of my ocaml-experimental repository.

As you can see, the speedup is quite impressive with our native toplevel being up to 100 times faster than the byte code toplevel. It is however worth noting that this is in part due to the fact that llvm-gcc is now the default with OS X, which disables the register assignment optimization in the byte code interpreter.

If you want to try our new toplevel (and/or help with testing), you can always grab the latest source from my ocaml-experimental repository using the following command

$ git clone -b ocamlnat-jit git://github.com/bmeurer/ocaml-experimental.git ocamlnat-jit
$ cd ocamlnat-jit

and build and install it using

$ ./configure -prefix /path/to/ocamlnat-jit
$ make world opt ocamlnat
$ make install

similar to the regular OCaml distribution. This will install a fully functional OCaml 3.12.1 system to /path/to/ocamlnat-jit together with a new binary ocamlnat, our native toplevel. You should be able to use ocamlnat as a drop-in replacement for ocaml in almost every case, unless you really need the byte code runtime (i.e. Coq is one popular application that heavily depends on the byte code runtime).

New website design

2011-09-09T00:00:00+00:00

I decided to update the website design again. Text should be easier to read now, and the new design feels lighter and less cluttered.

SSH via SSH Tunnel

2011-09-07T00:00:00+00:00

Imagine you want to connect via SSH to remote systems hostB and hostC on an intranet behind hostA. This could be achieved easily using port forwarding via hostA, just pick two arbitrary ports on the local machine and forward them to ports 22 of hostB and hostC. This works very well for a small amount of intranet hosts, but it get's quite messy as the list of hosts grows. After some time you'll have a rather huge amount of local ports to remember (or to lookup in your port forwarding script several times a day). It'd certainly be easier to just type ssh hostB and have the tunnel setup automatically.

Fortunately that is very well possible and quite easy to achieve using the ProxyCommand directive. Assuming hostA has nc installed, you can just add the following lines to your $HOME/.ssh/config.

Host hostB
    HostKeyAlias hostB
    ProxyCommand ssh hostA 'nc hostB 22'

Host hostC
    HostKeyAlias hostC
    ProxyCommand ssh hostA 'nc hostC 22'

Once done, you can easily connect to hostB via ssh hostB, or hostC via ssh hostC. No need to setup the tunnel first, it'll be set up and teared down automagically as needed.

Linear Scan Register Allocator for the OCaml Native Code Compiler

2011-08-25T00:00:00+00:00

I recently imported the first working version of the Linear Scan Register Allocator for the OCaml Native Code Compiler ocamlopt into the linear-scan-register-allocator branch of my ocaml-experimental repository. The register allocator was implemented for ocamlopt by Marcell Fischbach as part of his diploma thesis. It presents a first step towards a (better) native OCaml toplevel ocamlnat. Use the following command to checkout the source code:

$ git clone -b linear-scan-register-allocator git://github.com/bmeurer/ocaml-experimental.git ocaml-linscan

The implementation of the linear scan register allocator can be found in asmcomp/interval.ml, asmcomp/interval.mli, asmcomp/linscan.ml and asmcomp/linscan.mli (integrated into ocamlopt via asmcomp/asmgen.ml).

Some initial timing results are available here, here, and here. See bug 5324 for additional details.

OCaml GitHub Mirror

2011-08-20T00:00:00+00:00

During the last two days I managed to setup a GitHub mirror of OCaml. It works by importing the changes from the official OCaml Subversion Repository using git-svn and pushing them to the GitHub mirror. This is done automatically every hour by one of my servers. It works by setting up a Git branch for every version Subversion branch and a Git branch with a tags/ prefix for every tags Subversion branch. Also note that the master branch is called trunk.

I wanted to do this for some time now, but as some of you know, time is always against us. The major advantage is that there is now a single Git base for all my OCaml projects (and that of others), and there's is no longer a need to fiddle with git-svn in each and every project. Feel free to fork my ocaml repository for your own needs.

Demon Cam Promo Video

2011-08-16T00:00:00+00:00

Wow that Promotion Video for the Demon Cam is just awesome! I wonder if they will be able to actually make money with the app.

The app is iPhone-only right now, available at $0.99. A HD or Pro version for the iPad will probably follow at some point.

CocoaHeads Siegen September Meeting

2011-08-15T00:00:00+00:00

Next monthly meeting of the CocoaHeads Siegen scheduled for September, 13th 2011 at 19:00, feat: "iOS 5 - New and Noteworthy" (Benjamin Mies). Third meeting already and this time we also have a nice flyer!

On a related note: The server running the CocoaHeads Siegen website will be down on August, 27th 2011 due to some power supply related maintenance work at the Universität Siegen.

Random crashes with iOS 4.2.1

2011-08-13T00:00:00+00:00

I received several complaints about random crashes lately. The complaints of course did not mention any specific version of iOS nor any other useful details. So I had to digg into it myself. As it turned out the crashes were due to the use of DISPATCH_QUEUE_PRIORITY_BACKGROUND, which is not only unavailable with iOS 4.2.1 (and earlier), but also causes dispatch_async to crash - which is rather bad IMHO, a fallback to DISPATCH_QUEUE_PRIORITY_LOW would be better from both the user's and the developer's POV.

Blocks and Grand Central Dispatch

2011-08-11T00:00:00+00:00

Yesterday I held a talk about Blocks and Grand Central Dispatch at the second monthly CocoaHeads Siegen meeting. My slides are available for download from the CocoaHeads Siegen website. The presentation gave rise to some interesting discussion about networking performance with and without GCD, so today I'm digging into that GCDAsyncSocket thing again.

How to uncrush pngcrushed images from an iOS App Bundle

2011-08-04T00:00:00+00:00

I recently had to restore some PNG files from an iOS App Bundle, which apparently did not work very well, since they have been compressed automatically using Apple's version of pngcrush when they were copied to the App Bundle folder during archiving. Fortunately it's quite easy to revert the optimizations using the following command (assuming you have installed the Apple Developer Tools and the iOS SDK):

$ mkdir ~/reverted
$ /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/pngcrush -dir ~/reverted -revert-iphone-optimizations -q *.png

This will create a folder reverted in your home directory with the uncrushed PNG files.

Using Git tags to manage the version of Xcode projects

2011-07-25T00:00:00+00:00

Inspired by a recent post of Joachim Bondo I decided to rework my versioning scheme for Xcode projects as well. One of the major drawbacks of traditional versioning is that the so-called marketing version (Apple slang) is kept twice, once in the project's Info.plist file and once in the Git tag that is created after release. This redundancy is not only inconvenient, but can also lead to mistakes, i.e. forgetting to bump the CFBundleShortVersionString prior to tagging the new release.

So instead of maintaining the CFBundleShortVersionString we will now automatically inject the version number from the most recent Git tag into the generated app bundle. This is actually pretty easy and requires just the following two lines of shell code in a custom Build Phase:

# Update the CFBundleShortVersionString in the generated Info.plist using the most recent Git tag.
# Idea taken from http://tinyurl.com/3usjj9d by Joachim Bondo.

# Get the current release description from Git.
GIT_RELEASE_VERSION=`git describe --tags`

# Set the CFBundleShortVersionString in the generated Info.plist (stripping off the leading "v").
defaults write "${BUILT_PRODUCTS_DIR}/${INFOPLIST_PATH%.*}" "CFBundleShortVersionString" "${GIT_RELEASE_VERSION#*v}"

To add it to a target in your Xcode project, select the target, then Add Build Phase → Add Run Script, set the shell to /bin/bash and paste the contents of the script above. Make sure it is run after the Target Dependencies phase and before the Copy Bundle Resources phase, as shown in the following screenshot.

It is important to note that this will alter the Info.plist file of the built app bundle, not the Info.plist in your source tree, so your source tree won't get dirty from this operation, and you won't have to either reset or make another commit which would create a mismatch between the code you tagged and the code containing the correct version number. This way the version is stored only in the Git tag (i.e. v1.0.0) and you can remove the CFBundleShortVersionString from the Info.plist in your source tree.

A nice side effect of using git describe --tags is that if you make a development build, in-between any Git tagging, you will get a version number like v1.0.0-12-gf181880. In this case the version was built from a commit identified by the (partial) SHA gf181880 which is 12 commits after the last tagged version v1.0.0. A great way to handle the marking version of development builds.

Disabling the local snapshots feature of Time Machine in Lion

2011-07-24T00:00:00+00:00

Local snapshots for Time Machine is one of the new features in OS X Lion that looks really good on paper. But once you have used your new Lion installation for a few days, you will notice that you are running out of disk space. After some digging around I noticed that the /.MobileBackups folder that is used by Time Machine for local snapshots was at nearly 50GiB, even though the external Time Machine backup disk was connected most of the time. I guess this is done to speedup Time Machine in the common case, and make backups available when not connected to the external Time Machine disk.

Besides the disk space issue, the local snapshots feature also slows down your MBP noticably. You'll notice that the disk is spinning most of the time, and the file copying performed by Time Machine trashes your caches. Everything feels terribly slow after some time. Thankfully Apple engineers included a switch to turn of the local snapshots feature, tmutil supports a new command disablelocal in OS X Lion. Use the following command to disable the local snapshots feature of Time Machine:

$ sudo tmutil disablelocal

Note that it might take some time for Time Machine to cleanup the /.MobileBackups folder.

Lion

2011-07-21T00:00:00+00:00

So I'm trying to get used to OS X Lion now. One of the first things I noticed was that the Library folder does no longer show up in Finder by default. Of course that was rather trivial to fix using the following command:

$ chflags nohidden ~/Library

One really nice feature in Lion is that new tabs in Terminal.app now inherit the current working directory from the tab from which they were opened - something I implemented in Xfce's Terminal seven years ago, BTW. Looks like this is implemented by parsing the path displayed in the title bar, which can have unexpected results when combined with ssh sessions, since the path in the title is actually set via the (remote) shell. In addition the title bar of Terminal windows now provides the same handles as the title bar in Finder windows, which is pretty handy.

Unfortunately Apple decided to kick Spaces and replace it with Mission Control. This by itself is not necessarily bad, but now there's no way to get that two dimensional workspace layout back, at least until Apple decides to fix that shortcoming. I've also noticed that the order of the workspaces seems to change under some (obscure) conditions, which is even worse. Maybe I'm just getting old, but until now I was unable to figure out what triggers this rearrangement - not what I'd call intuitive.

Update 1: Lion also says bye bye to Microsoft Office for Mac 2004, since Rosetta is not available for Mac OS X 10.7.

Update 2: Make sure you don't miss the Mac OS X 10.7 Lion review by ars technica's John Siracusa.

Update 3: Well, I am old... the fix for that Mission Control feature that drove me nuts is obvious. In the Mission Control preference pane, disable the Automatically rearrange spaces based on most recent use option. Even if I was too blind to discover this earlier, it's nevertheless a really bad default. Out of 100 Mac users, how many would their workspaces to rearrange magically?

OS X Lion

2011-07-20T00:00:00+00:00

Just like almost every other geek on this planet, I'm downloading OS X Lion from the App Store right now. Rather slow... but that way I can do a full backup first while the update is downloading. #lion on Twitter is already busy discussing the new release.

In related news: The new MacBook Air looks really great - especially starting at $999. Finally a real alternative to the MacBook Pro.

Jekyllified CocoaHeads Siegen website

2011-07-20T00:00:00+00:00

I just migrated the CocoaHeads Siegen website to also use Jekyll, and uploaded the source to GitHub (it is not hosted on GitHub Pages though).

I've also uploaded the slides and source code from the first CocoaHeads Siegen meeting.

New website

2011-07-11T00:00:00+00:00

It was about time to get my website up2date... once again. In order to get it right this time, I decided to use Jekyll this time, and host everything on GitHub using their excellent GitHub Pages service.

XCasts color theme for Xcode 4

2011-06-19T00:00:00+00:00

Check out my Xcode 4 version of Ben Scheirman's XCasts color theme for Xcode 3, a dark theme loosely based on Ryan Bates' excellent Railscasts theme for Textmate.

Screenshot

Installation

Download and install the Inconsolata font.
Place the file XCasts.dvtcolortheme into the directory ~/Library/Developer/Xcode/UserData/FontAndColorThemes/.
Restart Xcode.
Open XCode | Preferences | Fonts & Colors and select the XCasts theme.

Nice transition from splash screen to main application screen using fade out and zoom in animation

2011-06-15T00:00:00+00:00

Change the -application:didFinishLaunchingWithOptions: method of your application delegate class like this (assuming your splash image is named Default.png):

Rounded rect additions for UILabel

2011-06-13T00:00:00+00:00

Category on UILabel which adds a property showsRoundedRect, which, if set to YES, causes the label to be drawn on a rounded rect, similar to the emblem shown for the number of new mails in the iPhone Mail app. Check out the Gist on Github.

git-utils - Various git related utilities

2011-05-31T00:00:00+00:00

Git Utils is a collection of simple utilities that made my Git life easier in some way or another. I tried to clean them up as much as necessary prior to putting here, so it should be easy to use for others as well.

Installation

You don't need anything special, just a working installation of Git and a UNIX system (tested with Mac OS X and Linux). To install the git-utils into /usr/local run

$ sudo make install

or just pick the scripts that you need and place them wherever you want.

Description

git-copy

Copy file from source path to target path and add the target path to the Git index.

git-push-all

Invoke git-push for all configured remote repositories.

A Step-indexed Semantic Model of Types for the Call-by-Name Lambda Calculus

2011-05-10T00:00:00+00:00

Step-indexed semantic models of types were proposed as an alternative to purely syntactic safety proofs using subject-reduction. Building upon the work by Appel and others, we introduce a generalized step-indexed model for the call-by-name lambda calculus. We also show how to prove type safety of general recursion in our call-by-name model.

http://arxiv.org/abs/1105.1985

OCamlJIT2 vs. OCamlJIT

2010-11-30T00:00:00+00:00

I did some final work on OCamlJIT2, and compared the result to OCamlJIT. The performance measures are presented in the following tech report (skip straight to section 4 for the performance results):

http://arxiv.org/abs/1011.6223

In short: Performance measured on a P4 "Northwood" (no long mode, plain x86) 2.4GHz. OCamlJIT2 beats OCamlJIT by a factor of 1.1 to 2.0 in every benchmark, and - rather surprising - was even able to beat ocamlopt in the number crunching benchmark (probably an issue with the x86 backend of ocamlopt).

As mentioned by Xavier Leroy and others previously, we probably went as far as we could go in the direction of JITting the byte-code virtual machine, while preserving its general stack-based nature and instruction set. Moving even further means translating the byte-code to some intermediate form suitable for use with standard compilation techniques; but as we saw earlier, in an LLVM-based prototype, the compilation overhead increases dramatically and the benefit of JIT compilation vanishes.

Therefore, as suggested earlier, I'll try to get my hands on the native top-level now (already contacted Alain for the emitter code). Additionally, the linear scan register allocation will be implemented by a student as part of his diploma thesis.

Update

See the discussion on the Caml mailing list.

OCamlJIT 2.0

2010-11-16T00:00:00+00:00

OCamlJit 2.0 is a new Just-In-Time engine for Objective Caml 3.12.0 on desktop processors (x86/x86-64). It translates the OCaml byte-code used by the interpreter (ocamlrun and ocaml) to x86/x86-64 native code on-demand and runs the generated native code instead of interpreting the byte-code. It is designed to run with minimal compilation overhead (translating only what is being executed, avoiding costly code generation and optimization techniques), while being 100% compatible with the byte-code runtime (including serialization and hashing of closures, etc.).

OCamlJit 2.0 was specifically designed for desktop processors and is not really portable to anything else in its current shape, because the target audience are people using the interactive top-level and the byte-code interpreter for rapid prototyping/development (which is unlikely to happen on anything else but x86/x86-64). The implementation currently requires a system that adheres to the SysV ABI, which includes Linux, BSD, OS X, but excludes Win32/Win64 (patches/ideas are welcome). It was tested on Linux/x86 (Debian), Linux/amd64 (CentOS) and Mac OS X 10.6 (64bit). The x86 implementation requires SSE2 capable processors (otherwise it falls back to the byte-code interpreter), so it won't speedup your OCaml programs running on 486 CPUs. :-)

OCamlJit 2.0 runs most benchmarks at 2-6 times faster than the byte-code interpreter. The interactive top-level benefits twice when used with the JIT engine:

the compiler stages are JIT compiled and
the generated byte-code is JIT compiled.

A tech report describing a slightly earlier prototype and including performance measures of OCamlJit 2.0 on Mac OS X (64bit) is available at:

http://arxiv.org/abs/1011.1783

The source code is available from the Git repository (master branch) at:

Installation is similar to installation of Objective Caml, just run

$ ./configure -prefix /path/to/ocamljit2 [options]

followed by

$ make world opt
$ make install

This will install a fully working Objective Caml 3.12.0 to /path/to/ocamljit2, where /path/to/ocamljit2/bin/ocamlrun and /path/to/ocamljit2/lib/libcamlrun_shared.so include the JIT engine in addition to the byte-code interpreter (fallback to the byte-code interpreter is necessary for debugging with ocamldebug). The configure script prints a line indicating whether the JIT engine is enabled or not (if not, it'll be just a regular OCaml 3.12 installation).

Update

See the discussion on the Caml mailing list, and the more recent work on OCamlJIT2.

git-hooks - Generic Git hooks

2009-11-23T00:00:00+00:00

Git Hooks provides a simple mechanism to manage hooks for several Git repositories in a unified and simple way. It allows you to install hook scripts in a central location and use them for your Git repositories.

Installation

You need CMake and GCC in order to build and install git-hooks. You will also need to have Git and Perl installed for the hooks to work properly. To build git-hooks run

$ cmake /path/to/git-hooks
$ make

in a new directory (preferably, tho you may also run it from the source directory). Then, use

$ make install

to install git-hooks. This will install git-hooks to /usr/local. You can use ccmake to change the installation prefix. Below, we will assume that you installed git-hooks to /usr/local.

Repository setup

To setup a repository using git-hooks, just use the repository template that ships with git-hooks.

$ mkdir myrepo.git
$ cd myrepo.git
$ git --bare init --template=/usr/local/share/git-hooks/template ...

This will setup the new repository myrepo.git with git-hooks. Check the sample config file that will be created for myrepo.git.

Repository migration

To migrate an existing repository to use git-hooks, you should first backup your existing hook scripts. Then replace the hooks with the ones from /usr/local/share/git-hooks/template/hooks. Afterwards, you should migrate your previous hook scripts to global hook scripts used by git-hooks.

Configuration

The git-hooks package includes several useful hooks, which can be configured to your needs using git config settings in your repository (or even global settings from /etc/gitconfig). The /usr/local/share/git-hooks/template/config file provides a sample configuration file.

Please see the hook scripts in /usr/local/share/git-hooks/*.d/ for the various supported config settings.

Gitweb and HTTP transport for public repositories

2009-11-07T00:00:00+00:00

It took me some time to figure out how to get gitweb and (readonly) HTTP transport working for public Git repositories using the same URL. So here's my Apache 2 configuration, it may save you some time. The configuration assumes that your Git repositories are located under /srv/git and the gitweb files are installed in /usr/share/gitweb with the configuration file in /etc/gitweb.conf.

# Dumb transport clone URLs for public repositories
AliasMatch ^/git(/.*\.git)/HEAD$ /srv/git/$1/HEAD
AliasMatch ^/git(/.*\.git)/info(/.*)? /srv/git/$1/info$2
AliasMatch ^/git(/.*\.git)/objects(/.*)? /srv/git/$1/objects$2
AliasMatch ^/git(/.*\.git)/refs(/.*)? /srv/git/$1/refs$2
<Directory "/srv/git/*.git">
        AllowOverride None
        Options Indexes
        <Limit GET POST OPTIONS>
                Order allow,deny
                Allow from all
        </Limit>
        <LimitExcept GET POST OPTIONS>
                Order deny,allow
                Deny from all
        </LimitExcept>
</Directory>

# gitweb user interface
Alias /git /usr/share/gitweb
<Directory /usr/share/gitweb>
        SetEnv GITWEB_CONFIG /etc/gitweb.conf
        Options +ExecCGI
        AddHandler cgi-script .cgi
        DirectoryIndex gitweb.cgi

        RewriteEngine on
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^.* /git/gitweb.cgi/$0 [L,PT]
</Directory>

Thunar 0.9.0, exo 0.3.4 and thunar-volman 0.2.0 releases

2007-02-12T00:00:00+00:00

I just released new versions of Thunar, exo and thunar-volman with several bugfixes and new translations. They are part of Xfce 4.4.2, which will be released tomorrow.

Seminar Paper on Model Checking

2007-01-22T00:00:00+00:00

Just uploaded my seminar paper on PLTL Model Checking toghether with the slides. The paper and the slides are in german, and cover the basics of Model Checking using Propositional Linear Temporal Logic (PLTL).

Thunar 0.8.0 and libexo 0.3.2 releases

2007-01-21T00:00:00+00:00

I just released Thunar 0.8.0 and exo 0.3.2 as part of the long awaited Xfce 4.4.0, which will be released in a few hours. The separate tarballs are provided for users of Xfce 4.2.x refusing to upgrade to Xfce 4.4.x, and users of other desktop environments. This is the final release of Thunar, but since not all items from the roadmap were completed, it is not yet the 1.0.0 version.

You will need at least libxfce4util 4.2.2, GTK+ 2.6.4, shared-mime-info 0.15 and desktop-file-utils 0.10 to build and run Thunar. In addition Gamin or FAM are highly recommended to enable file system monitoring in Thunar. For HAL support on Linux, the libhal-storage-devel package is required (0.5.0 or above). Furthermore if you want to use the trash panel applet, you will need the Xfce Panel 4.4BETA1 or above and D-Bus 0.34 or above. The README file contains a complete list of dependencies and optional packages.

The official announcement is available at: http://thunar.xfce.org/news.html#2007-01-21

Several screenshots are available at: http://thunar.xfce.org/screenshots.html

The source tarballs and the graphical installers can be downloaded from: http://thunar.xfce.org/download.html#0.8.0

Installation instructions and documentation are available at: http://thunar.xfce.org/pwiki/

Please report bugs to the Xfce Bug Tracker (product Thunar) at: http://bugzilla.xfce.org/

A visual tour of Xfce 4.4.0

2007-01-21T00:00:00+00:00

As of today, the long awaited version 4.4.0 of the Xfce Desktop Environment is finally available. I will try to highlight some of the new features which have been added since the last stable release.

Desktop Icons

One of the most often requested features during the 4.0 and 4.2 was support for icons on the desktop. Now, with Xfce 4.4.0, this feature was finally added to the desktop manager Xfdesktop.

The desktop manager utilizes Thunar's libraries to handle application launchers and regular files/folders on the desktop. The desktop manager is also able to display icons for minimized windows on the desktop, which is quite a popular feature from the CDE world. Of course, you can disable the desktop icons altogether if you prefer a clean desktop.

Xfdesktop also continues to provide access to the applications menu, as it did in the previous Xfce releases.

File Manager

The desktop icon support goes hand in hand with the new file manager Thunar which replaces the previous file manager Xffm.

Thunar was written from scratch to provide an easy to use, but still very lightweight file manager for Xfce. Its user interface was designed to look similar to the file chooser which was introduced with GTK+ 2.4, and other file managers such as Nautilus and pcmanfm already picked up that idea as well.

Thunar supports all the file management functionality which users will expect, and also several advanced features. For example, a so-called Bulk Renamer is included which allows users to rename multiple files at once using a certain criterion.

Removable Drives and Media

Xfce 4.4.0 provides easy access to data on removable drives and media. Just insert the media into the drive or plug the new drive in to the computer and an icon representing the removable volume will appear on the desktop and in Thunar's side pane.

Click on the icon to automatically mount the volume. Right-click the icon to unmount the drive or eject the media from the drive. Note however that this feature requires HAL and is therefore only available for Linux 2.6.x and FreeBSD 6.x and above at the time of this writing (there is limited removable media support for FreeBSD 4.x and 5.x which does not require HAL).

Text Editor

The new text editor MousePad is included with this release. MousePad provides all the basic editor functionality, nothing more, nothing less.

You can think of MousePad as the equivalent to NotePad on Windows. It starts up very fast, usually in less than one second, even on older systems.

Window Manager

Xfwm4 continues to be the window manager of the hearts.

This release features an enhanced compositor, supporting transparent ARGB windows, shadows, window frame transparency and much more.

Xfwm4 also includes a brand new application switcher, as shown in the screenshot above, which displays all windows from the current workspace with icons and window titles.

Further on support for multiple image formats for window decoration themes was added, including PNG, GIF and SVG images.

Advanced controls for the window manager were also added, allowing thorough tweaking of window behavior.

Panel

The Xfce4-panel was completely rewritten for the Xfce 4.4 release. Multiple panels are supported out of the box now and can easily be configured using the new Panel Manager shown in the screenshot below.

One of the major problems in previous Xfce releases was that every plugin had to be run in the same process as the panel, and hence every plugin was able to crash the whole panel. To address this issue, support for external plugins was added to the panel.

Developers of panel plugins can now decide whether the plugin should run as external process or as part of the panel process, depending on the stability of the plugin.

Since there is now support for multiple panels, the separate Xftaskbar4 and Xfce4-iconbox utilities are no longer required. Instead, both the taskbar and the iconbox are available as panel plugins now.

Most of the additional panel plugins, available via the Xfce Goodies Project, have been updated for the new panel, and several new plugins were added. For example, the brand new xfce4-xfapplet-plugin allows users to add GNOME panel applets to the Xfce panel.

Time Management

The new time management application Orage replaces the Xfcalendar, which was introduced with Xfce 4.2.0. Orage provides several features to efficiently manage your time.

While Orage is very lightweight and easy to use, it supports all the important features found in larger calendar applications like Outlook or Evolution. While Xfcalendar used the custom dbh format in the past to store your settings, Orage is based on ical and therefore compatible with other calendar applications.

Terminal Emulator

While Terminal was already available during the 4.2 days, it was not mature enough at that time to be part of the core. With this major release, it was moved into the core desktop.

Besides the basic features which you might expect from a terminal emulator, it includes some nice additional features, like multiple tabs per window, customizable toolbars and the ability to configure nearly every aspect of the application via hidden options. As can be seen in the screenshot above, this release also supports real transparency using Xfwm4's integrated composition manager.

Printing

Xfprint, the Xfce printing management application, saw several small improvements with this release. First, the a2ps converter is not mandatory anymore, whilst still recommended. Support for CUPS 1.2 was added and Xfprint is now able to display the printer state with the CUPS-backend.

Xfprint also integrates with MousePad to provide generic printing support for different kinds of text documents using the a2ps converter.

As you can see the print dialog still looks relatively similar to that of Xfce 4.2, but the internal workings of the printing support were improved, especially the CUPS support. Besides that, the printing management functionality was moved to a library, so other applications can use the API to access the printer configuration.

Autostart

Xfce 4.4.0 implements the new Autostart Specification - actually Xfce was the first desktop to implement said feature, but the others were faster to release. ;-)

The specification consists of two parts, the Autostart of Applications During Startup, which is implemented in xfce4-session and the Autostart Of Applications After Mount which is implemented in thunar-volman. This release also includes the xfce4-autostart-editor, shown in the screenshot above, which allows users to easily add, remove or disable autostarted applications.

Settings

This release introduces new options to customize the desktop to your needs. Some examples of new settings dialogs were already shown in the sections above.

The preferred applications framework, which was previously only available in Terminal, was imported into Xfce, so users no longer need to edit shell profiles to specify which browser and terminal emulator should be used by Xfce applications. The goal was to make it as easy as possible to change an application for a certain category (GNOME users may have already noticed that GNOME adopted this approach, because it is so simple).

And then there was the problem with the keyboard shortcuts in Xfce 4.2... Xfce 4.2 limited the number of freely available keyboard shortcuts, while people wanted to assign any number of keyboard shortcuts. With Xfce 4.4 this limitation is history and the application shortcuts are now separated from the window manager shortcuts.

thunar-volman 0.1.0

2007-01-15T00:00:00+00:00

I just released the first version of the Thunar Volume Manager. It adds automatic management of removable drives and media to Thunar, without adding another daemon to your desktop sessions. It requires Thunar 0.5.1svn or above, HAL 0.5.0 or above and D-BUS 0.32 or above.

Website: http://foo-projects.org/~benny/projects/thunar-volman/index.html

Documentation: http://thunar.xfce.org/documentation/C/using-removable-media.html

Release notes: http://developer.berlios.de/project/shownotes.php?release_id=12027

Download: http://developer.berlios.de/project/showfiles.php?group_id=910&release_id=12027

Just another Xfce 4.4 review

2006-11-15T00:00:00+00:00

Another interesting review of Xfce 4.4.

Xfce 4.4 release candidate 2

2006-11-06T00:00:00+00:00

Hopefully the last release candidate for 4.4.0...

Thunar 0.5.0 and libexo 0.3.1.12 rc2 releases

2006-11-05T00:00:00+00:00

I just released Thunar-0.5.0rc2 and libexo-0.3.1.12rc2 as part of Xfce 4.4RC2, which will be released in a few hours. The separate tarballs are provided for users of Xfce 4.2.x that don't want to upgrade yet, and users of other desktop environments. It is planned to be the last release candidate before the final release, so please help with testing so we can locate and elimate the leftover bugs for the final release.

You will need atleast libxfce4util 4.2.2, GTK+ 2.6.4, shared-mime-info 0.15 and desktop-file-utils 0.10 to build and run Thunar. In addition Gamin or FAM are highly recommended to enable file system monitoring in Thunar. For HAL support on Linux, the libhal-storage-devel package is required (0.5.0 or above). Furthermore if you want to use the trash panel applet, you will need the Xfce Panel 4.4BETA1 or above and D-Bus 0.34 or above. The README file contains a complete list of dependencies and optional packages.

The official announcement is available at: http://thunar.xfce.org/news.html#2006-11-05

Several screenshots are available at: http://thunar.xfce.org/screenshots.html

The source tarballs and the graphical installer can be downloaded from: http://thunar.xfce.org/download.html#0.5.0

Installation instructions and documentation are available at: http://thunar.xfce.org/pwiki/

Please report bugs to the Xfce Bug Tracker (product Thunar) at: http://bugzilla.xfce.org/

thunar-archive-plugin 0.2.2

2006-11-04T00:00:00+00:00

This is a minor release, which adds support for the new Drag'n'Drop menu in Thunar 0.5.0 and tangoified icons, as well as several new and updated translations.

Download: http://developer.berlios.de/project/showfiles.php?group_id=910&release_id=11557

Release notes: http://developer.berlios.de/project/shownotes.php?release_id=11557

Website (with screenshots): http://foo-projects.org/~benny/projects/thunar-archive-plugin/index.html

Xfld 0.3 release

2006-11-01T00:00:00+00:00

Unfortunately I have the flu and so I'm somewhat late with posting old news here... Anyway, Xfld 0.3 is finally available for download. This time it's based on Xubuntu. And as usual it is the perfect LiveCD for nearly every use case. ;-)

Xfce 4.4 release candidate 1

2006-09-03T00:00:00+00:00

Another step forward to 4.4.0. Get it while it's hot!

Thunar 0.4.0 and libexo 0.3.1.10 rc1 releases

2006-09-03T00:00:00+00:00

I just released Thunar-0.4.0rc1 and libexo-0.3.1.10rc1 as part of Xfce 4.4RC1. The separate tarballs are provided for users of Xfce 4.2.x that don't want to upgrade yet, and users of other desktop environments. As suggested by the name it is not yet a final release, but is considered to be somewhat stable.

You will need atleast libxfce4util 4.2.2, GTK+ 2.6.4, shared-mime-info 0.15 and desktop-file-utils 0.10 to build and run Thunar. In addition Gamin or FAM are highly recommended to enable file system monitoring in Thunar. For HAL support on Linux, the libhal-storage-devel package is required (0.5.0 or above). Furthermore if you want to use the trash panel applet, you will need the Xfce Panel 4.4BETA1 or above and D-Bus 0.34 or above. The README file contains a complete list of dependencies and optional packages.

The official announcement is available at: http://thunar.xfce.org/news.html#2006-09-03

Additional (updated) screenshots are available at: http://thunar.xfce.org/screenshots.html

The source tarballs and the graphical installer can be downloaded from: http://thunar.xfce.org/download.html#0.4.0

Installation instructions and documentation are available at: http://thunar.xfce.org/pwiki/

Please report bugs to the Xfce Bug Tracker (product Thunar) at: http://bugzilla.xfce.org/

New features in Thunar 0.4.0rc1

2006-08-09T00:00:00+00:00

About a month ago Thunar 0.3.2beta2 was released as part of Xfce. Much has happened since that time, and we're nearly ready for the first release candidate of Xfce 4.4.0 now, which should be available in two or three weeks. So, it's time to sit down and check what we have in the pipe for Thunar 0.4.0rc1.

Below is the list of features - focussing on the three most visible changes (to users) - that are already available in the development version and will definitely be part of the first release candidate. This list will hopefully be extended with some additional features if time permits, but most probably not in time for 0.4.0rc1. The most interesting pending feature here is network support for Thunar, which will include atleast browsing Samba shares and connecting Samba shares (and probably other network file services as well) via smbfs or FUSE.

Trash

Probably the most notable change when starting Thunar after upgrading will be the addition (or better re-addition) of the trash support, which implements the Desktop Trash Can Specification (but is currently limited to the home trash).

So when you delete files now, they will not be lost forever, but instead will be moved to your trash can, and can be recovered easily by right-clicking on the file or folder and selecting Restore from the context menu. If the location from where the file or folder was moved to the trash is no longer present you'll be ask whether to recreate the required folders in order to be able to restore the trashed resource.

If you want to permanently delete a file, you can either move it to the trash and then delete the file in the trash, or hold down the Shift key while pressing Del or selecting Delete from the menu. You'll still need to confirm the permanent removal of files, so you don't accidently remove an important file without any notice.

You can also move files or folders to the trash by dropping them onto the trash can in the shortcuts or tree pane, or by dropping them onto the trash panel applet, shown in the screenshot above. The panel applet displays the current status of the trash can and allows you to empty the trash can from the context menu. You will need to build Thunar with D-Bus support in order to be able to use the panel applet, because the applet does not monitor and manage the trash itself (to avoid any additional overhead), but instead uses the new org.xfce.Trash interface to talk to Thunar and lets Thunar do all the hard work.

It is expected that xfdesktop will also get a trash can for 4.4.0rc1, using the org.xfce.Trash interface as well. But that is still work in progress.

Rubberband Selection

With the addition of rubberband selection to GtkTreeView in GTK+ 2.10 it is finally possible to use rubberband selection in Thunar's detailed view.

Unfortunately that didn't work as smooth as it should, so there was some additional work put into ExoTreeView to be able to really use the rubberband selection with GTKs own Drag'n'Drop mechanism! With the work-arounds in place you can now start a rubberband selection in the detailed list view by pressing the left mouse button on a not selected row (it still not possible to start the rubberband selection in an empty area of the detailed list view and there's unfortunately no way to work-around this GtkTreeView bug, but hopefully this will be fixed in one of the next GTK+ releases).

Creating Launchers the Easy Way

With exo 0.3.1.10rc1 it will be even easier to create launchers for applications on your system, that are registered via the freedesktop.org menu system. No need to look up the name of the binary for the application and search through large icon directories to locate the appropriate icon for the application anymore. Just start typing the name of the application or the applications purpose in the Name box and a list of possible applications with that name or purpose will appear.

Select the application you are looking for from the list of matching applications and all the required values are filled with the applications settings.

Bugfixes and Improvements

Of course this release will also include a bunch of bugfixes and improvements. For example when selecting an image file in Thunar, the statustext will also include the dimensions of that image, so you don't need to fire up the properties dialog to find out the width and height of the image.

The dependency of the thunar-vfs library on GConf is gone and startup time was thereby improved (actually not the startup that much, but the time when the first thumbnail is loaded). The GNOME thumbnail generators (i.e. Evince for PDF, Totem for video, etc.) are now collected by an external utility and stored into an mmap()able cache file.

File dates - the time of the last access and modification - are now displayed in a more human readable format. The overall memory usage was again decreased by using the new slice allocator in GLib 2.10 and above where appropriate.

How to contribute?

Thunar - and other Xfce components as well - is still looking for contributions, may it be knowledge, time or money. If you feel like donating any of this to Thunar, visit the Contribute to Thunar page and be sure to subscribe to the thunar-dev mailinglist.

Feedback

Please send your feedback to the thunar-dev mailinglist.

Trash, Bugs, Wasted Time

2006-07-28T00:00:00+00:00

So, the trash framework finally made its way into Xfce SVN. Still a bit rough around the edges, but that's mostly cosmetic fixes.

In other news, I wasted four hours hunting down a bug/incompatible change in GTK+ 2.10, where the GtkTreeModelFilter doesn't behave properly anymore, which means that people using Thunar with GTK+ 2.10 and the tree pane will most probably not be able to run Thunar. The suggested solution for now is to switch to the shortcuts pane instead (or downgrade to GTK+ 2.8).

Update

According to the responsible GTK+ maintainer that was an intentional break in the expected behavior of a GtkTreeModel. Of course, in a perfect world, toolkit maintainers would let application developers know of such breakage instead of waiting for other applications to crash... Thunar is now switched to the new behavior and will therefore work with GTK+ 2.10 again. Now we'll wait for the next crash. Maybe its worth the time porting Xfce to Qt; not that Qt is perfect, but atleast (if you have commercial support) you get useful comments about breakage in Qt that may cause trouble in applications.

Trash is back

2006-07-21T00:00:00+00:00

Because this feature was requested quite often, and it somewhat makes sense for a file manager, I'll add trash support (based on the trash specification) for the next release (most probably RC1).

Trash support will be transparently available to all applications using thunar-vfs (no API/ABI breakage, just a few special methods added), and it should be easy to develop a panel plugin that displays the trash can or add a trash can to xfdesktop.

Unfortunately the problem of interoperability of trash:-URIs remains, but that should be a minor problem as long as people don't try to use the trash as primary storage for their documents.

Xfce 4.4 beta2 released

2006-07-10T00:00:00+00:00

And so it's done. Another huge step forward to Xfce 4.4.0.

Thunar 0.3.2 and libexo 0.3.1.8 beta2 releases

2006-07-09T00:00:00+00:00

I just released Thunar-0.3.2beta2 and libexo-0.3.1.2beta2 as part of Xfce 4.4BETA2, which will be released tomorrow. Separate tarballs are provided for users of Xfce 4.2.x that don't want to upgrade yet, and users of other desktop environments. As suggested by the name, it is still a beta release and it is thereby considered to be more or less stable in what it does, but it is not yet a final version.

You will need atleast libxfce4util 4.2.2, GTK+ 2.6.4, shared-mime-info 0.15 and desktop-file-utils 0.10 to build and run Thunar. In addition Gamin or FAM are highly recommended to enable file system monitoring in Thunar. For HAL support on Linux, the libhal-storage-devel package is required (0.5.0 or above). The README file contains a complete list of dependencies and optional packages.

The official announcement is available at: http://thunar.xfce.org/news.html#2006-07-09

Additional (updated) screenshots are available at: http://thunar.xfce.org/screenshots.html

he source tarballs can be downloaded from: http://thunar.xfce.org/download.html#0.3.2

Installation instructions and documentation are available at: http://thunar.xfce.org/pwiki/

Please report bugs to the Xfce Bug Tracker (product Thunar) at: http://bugzilla.xfce.org/

thunar-archive-plugin 0.2.0

2006-07-04T00:00:00+00:00

This is a major release, which introduces a generic scripting interface for archivers, so the plugin can now be used with basicly every archive manager that supports the required command line parameters. Support for File Roller (the GNOME archive manager) and Ark (the KDE archive manager) is builtin. Xarchiver will include support for the archive plugin in the next release. It depends on Thunar 0.2.2 or above.

Download: http://developer.berlios.de/project/showfiles.php?group_id=910&release_id=10461

Release notes: http://developer.berlios.de/project/shownotes.php?release_id=10461

Website (with screenshots): http://foo-projects.org/~benny/projects/thunar-archive-plugin/index.html

Another Xfce 4.4 BETA1 review

2006-05-11T00:00:00+00:00

What next for the Xfce Project? on LWN.net.

New Xfce Installer

2006-05-05T00:00:00+00:00

Jannis just uploaded new screenshots demonstrating the next generation of the Xfce Installer, which will hopefully be available for BETA2.

Be sure to have a look!

Xfce 4.4 BETA1 review

2006-05-02T00:00:00+00:00

Tuxmachines.org has nice review of Xfce 4.4beta1, which provides a more detailed overview than my brief list of major changes.

Conclusion: Things are only getting better with xfce4 4.4. Updated interface configurations, new options, and new applications make this release an exciting prospect. If you've never tried xfce or haven't tried it recently, you owe it to yourself to test it out.

Major changes in Xfce 4.4 BETA1

2006-04-18T00:00:00+00:00

As you might already know, Xfce 4.4BETA1 was released today, and it contains a lot of changes, that have been worked since the last major release. I'm going to present an (incomplete!) list of the most important changes in BETA1. I will not include Thunar here, read the Thunar 0.3.0 release notes for details about Thunar

Desktop Icons

One of the most often requested features during the Xfce 4.0/4.2 days was support for desktop icons. Xfce 4.4 finally includes support for icons on the desktop.

xfdesktop utilizes Thunar's libraries to handle application launchers and files/folders on the desktop, and it is also able to display icons for minimized windows on the desktop (a popular CDE feature), or to disable desktop icons all together.

Mousepad

Mousepad, a simple and lightweight text editor, was included as part of Xfce 4.4. Mousepad starts up very fast and provides all the basic text editing features, which makes it a perfect default editor for Xfce.

Orage

Orage, the new calendar application based on xfcalendar, provides all the features one would expect from a time management application today, while it remains lightweight and easy to use.

Panel

The Xfce Panel was completely rewritten for 4.4, and supports multiple panels and external plugins (running as separate applications and thereby improving the stability of the panel). xftaskbar4 and xfce4-iconbox were dropped from the release, as their functionality is completely provided by the new panel now.

The panel items can now be added and reordered using Drag'n'Drop, and the panel launcher properties dialog was redesigned to make it easier to create and manage launchers with attached menus (there is also support for Zero Install now).

Most of the panel plugins, available via the Xfce Goodies project, have been updated for the new panel, and the new xfce4-xfapplet-plugin allows users to add GNOME panel applets to the Xfce panel.

Preferred Applications

A new preferred applications framework was imported into Xfce, so users no longer need to edit shell profiles to specify which browser and terminal emulator should be used by Xfce applications.

Window Manager Tweaks

xfwm4, the Xfce window manager, saw a lot of improvements. One of the most interesting user-visible changes is the inclusion of a window manager tweaks dialog, which allows users to tweak several advanced options of the window manager.

There is also support to tweak the builtin composition manager in the window manager settings if xfwm4 was built with support for the Xcomposite extension.

This is just a very brief list of changes. A more complete review of Xfce 4.4BETA1 should be available during the next weeks.

Xfce 4.4 BETA1 released

2006-04-17T00:00:00+00:00

Xfce 4.4beta1 was finally released today with all the nice stuff (new panel, Mousepad, Orage, Thunar, ...). Be sure to grab your copy today!

thunar-archive-plugin 0.1.2

2006-04-17T00:00:00+00:00

I just released the second version of the thunar-archive-plugin. It includes a bunch of new translations, and fixes the problem that the folder was not properly reloaded after creating or extracting an archive. It requires Thunar 0.2.2alpha2 or above and File Roller.

Download: http://developer.berlios.de/project/showfiles.php?group_id=910&release_id=9778

Release notes: http://developer.berlios.de/project/shownotes.php?release_id=9778

Website (with screenshots): http://foo-projects.org/~benny/projects/thunar-archive-plugin/index.html

Thunar 0.3.0 and libexo 0.3.1.6 releases

2006-04-17T00:00:00+00:00

I just released Thunar-0.3.0beta1 and libexo-0.3.1.6beta1 as part of Xfce 4.4BETA1 (separate tarballs are provided for users of Xfce 4.2.x that don't want to upgrade yet, and users of other desktop environments). As suggested by the name, it is a beta release and it is thereby considered to be more or less stable in what it does, but it is still not a final version.

You will need atleast libxfce4util 4.2.2, GTK+ 2.6.4, shared-mime-info 0.15 and desktop-file-utils 0.10 to build and run Thunar. In addition Gamin or FAM are highly recommended to enable file system monitoring in Thunar. For HAL support on Linux, the libhal-storage-devel package is required (0.5.0 or above). The README file contains a complete list of dependencies and optional packages.

The official announcement is available at: http://thunar.xfce.org/news.html#2006-04-16

Additional (updated) screenshots are available at: http://thunar.xfce.org/screenshots.html

The source tarballs can be downloaded from: http://thunar.xfce.org/download.html#0.3.0

Installation instructions and documentation are available at: http://thunar.xfce.org/pwiki/

Please report bugs to the Xfce Bug Tracker (product Thunar) at: http://bugzilla.xfce.org/

New Thunar Wiki

2006-04-15T00:00:00+00:00

I set up a new Thunar Wiki today, which contains interesting information for users. The old wiki with the development notes is still there and will continue as dev wiki.

Compact View

2006-04-14T00:00:00+00:00

Thanks to Matt McClinch, who worked out a patch for Thunar and libexo, Thunar BETA1 will also include the often requested Windows Explorer-like Compact View.

Close to BETA1

2006-04-13T00:00:00+00:00

We're close to Thunar BETA1, hopefully this weekend. So, time to share a few screenshots. The BETA1 includes a full-featured tree pane...

...allows to customize the columns in the detailed list view and provides a fixed column width mode, which does not only improve the usability for users used to the Window Explorer way, but also speeds up the display of the detailed list view by a factor of 10 for medium sized folders...

...includes improved single-click navigation support with configurable hover selection...

...and will work properly on Solaris out-of-the-box (with support for Solaris specific file types), though the Solaris volume management support will not be merged for the BETA1, as it's not ready for prime-time yet...

...and as additional goodie, the bulk renamer was imported, which allows users to easily rename multiple files at once.

Together with the additional plugins, and especially Jannis' thunar-media-tags-plugin, a lot of bugfixes and usability improvements, and other changes I forgot to mention, we're already very close to the first final release.

Transparent Terminal Hack

2006-03-27T00:00:00+00:00

This one was requested quite often lately, so here's a quick&dirty hack to make the Terminal transparent. The Terminal-side changes are pretty easy, just use ARGB visuals if possible. The VTE patch is really just a hack for the Xft backend with a hardcoded alpha value of 0xaaaa. You need to run a composition manager for this to work (i.e. xfwm4 with --compositor=on), and select solid background color in Terminal (as said, the VTE patch is just a really quick hack). The result is:

Patch for Terminal, works with latest SVN.
Patch for VTE, created with 0.11.18, but should also work with newer versions.

Anybody willing to create a clean patch for VTE (requires quite a lot of changes, but doable)?

thunar-archive-plugin 0.1.0

2006-03-26T00:00:00+00:00

I uploaded a first release of the thunar-archive-plugin, which currently integrates File Roller into Thunar (support for Xarchiver will be added once Xarchiver is ready). Check the website for download locations and instructions.

Thunar startup

2006-03-15T00:00:00+00:00

I decided to do some profiling on Thunar startup to find out why it takes 2-3 seconds to popup here using the Gtk+ 2.8 port (while it starts up faster with the full debug build of Gtk+ 2.9). Using Federicos simple access() trick, I found out that the majority of time was spent in gtk_window_size_request() and gtk_window_realize().

Looking at the relevant parts of the truss output it was very easy to locate the cause of the problem. gtk_window_realize() loaded the GtkIconTheme instance for the default screen, which in turn tried to stat() every icon in Tango and all inherited icon themes. Looking at the Gtk+ source, it shouldn't stat() the icon files if an updated icon-theme.cache file is found. Since I had updated icon-theme.cache files for all relevant icon theme directories (the truss output also shows that after stat()ing all icon files, the icon-theme.cache file is finally used), it should not stat() the icons, but only the icon directory (according to the Gtk+ source).

So after some further research, I found this patch, which gets applied to the x11-toolkits/gtk20 FreeBSD port. The patch basicly changes the icon cache loading to first stat() all icon files in the theme and test if any of them is newer than the cache file. That does of course make the startup slow (the startup of every Gtk+ application on FreeBSD). Whoever came up with that idea was definitely on crack.

Ok, so removed that patch, rebuilt the port, and voila...

1/2 second from startup to gtk_main(), that's quite ok. Now whats left over is the question why gtk_window_size_request() takes that long on first call. Looking at the truss log again, it seems to be the Pango initialization. Have to check this later...

Update

For the sake of completeness, here's the time it takes to completely open and display (measured as wait for the last expose event) a folder (the thunar source directory, 223 files and folders) in Thunar:

1.3 seconds isn't that bad for a first unoptimized release. Still room for improvement, tho.

What's next?

2006-03-09T00:00:00+00:00

Thunar will enter beta phase soon, so I thought I'd share two additional screenshots of what's to come soon.

First, Thunar finally supports DnD to shortcuts (after crashing Thunar and Nautilus several times while testing, but finally remembered to remove GTK_DEST_DEFAULT_ALL). Screenshot

Next, I started work on the tree view. The basic tree view and tree model took less than a day, pretty easy using GNode. But I guess it'll take another week to add all the small details. Screenshot

Thunar 0.2.2 and libexo 0.3.1.4 alpha2 releases

2006-03-05T00:00:00+00:00

I just released Thunar-0.2.2alpha2 and libexo-0.3.1.4alpha2. As suggested by the name, it is an alpha release and it is thereby considered to be more or less stable in what it does, but it is by no means a final version.

You'll need atleast libxfce4util 4.2.2, Gtk+ 2.6.4, shared-mime-info 0.15 and desktop-file-utils 0.10 to build and run Thunar. In addition, Gamin or FAM are highly suggested to enable file system monitoring in Thunar. For HAL support on Linux, the libhal-storage devel package is required (0.5.0 or above). The README file contains a complete list of dependencies and optional packages.

The official announcement is available at: http://thunar.xfce.org/news.html#2006-03-05

Additional (updated) screenshots are available at: http://thunar.xfce.org/screenshots.html

The source tarballs can be downloaded from: http://thunar.xfce.org/download.html#0.2.2

Please report bugs to the Xfce Bug Tracker (product Thunar) at: http://bugzilla.xfce.org/

Desktop actions

2006-02-06T00:00:00+00:00

I finally came around to fix some long standing issues with the internals of the file launching stuff in Thunar (to sum it up: it was a mess). Now it's cleaned up, and with the new classes it was actually too easy to add support for desktop actions (see the desktop file spec for details) to Thunar (Brian already added support to Xfmedia some time ago).

In addition the Open With actions are now also available if more than one file is selected.

Thunar 0.2.0 and libexo 0.3.1.2 alpha releases

2006-01-22T00:00:00+00:00

I just released Thunar-0.2.0alpha and libexo-0.3.1.2alpha. As the name suggests, it's an alpha release and it is thereby considered to be more or less stable in what it does, but it's by no means a final version.

You'll need atleast libxfce4util 4.2, Gtk+ 2.6, shared-mime-info 0.15 and desktop-file-utils 0.10 to build and run Thunar.

The official announcement is available from: http://thunar.xfce.org/news.xhtml

The source tarballs are available from: http://thunar.xfce.org/download.xhtml

Please report bugs to the Xfce Bug Tracker (product Thunar) at: http://bugzilla.xfce.org/

Some more screenshots

2006-01-10T00:00:00+00:00

Long time no post. So, here's another bunch of random screenshots.

Just another screenshot

2005-11-15T00:00:00+00:00

Not much to say here, just more options available from the user interface:

Thunar 0.1.4 and libexo 0.3.1.1 pre-alpha releases

2005-11-14T00:00:00+00:00

Checkout the announcement on thunar-dev.

New Thunar snapshot

2005-11-09T00:00:00+00:00

For the brave: I just uploaded a new Thunar snapshot, which will soon replace the (now) outdated version currently found in the Xfce SVN repository.

Thunar application chooser

2005-09-22T00:00:00+00:00

Finally found the time to finish and commit the initial application chooser for Thunar. It's still a bit rough, but it works for now:

(Mis)Use of icons in Gtk+/GNOME

2005-09-15T00:00:00+00:00

As seen on pgo: An interesting blog entry from tigert about the use of icons in Gnome today (be sure to scroll down to Waldo Bastian's comment).

Content Manager Ideas

2005-09-10T00:00:00+00:00

I've been reading through the Appeal Wiki lately, and stumbled about the Content Manager page today. While the idea is not new, it's certainly one of the most interesting areas of Project Appeal.

New installer

2005-09-09T00:00:00+00:00

Just checked the new installer for Xfce 4.4 yesterday. Really nice work so far, Jannis. The UI sure needs some work, but the fundamentals look good, and I think it's on the right track.

Thumbnails

2005-09-03T00:00:00+00:00

It took quite some time and it wasn't very enjoyable, but now Thunar finally supports thumbnails (atleast loading):

It's not yet committed tho. Fortunately most desktop applications already store thumbnails today, so the file manager seldomly needs to generate a thumbnail itself. For the generation, we'll support whatever GdkPixbuf supports (we'll probably also include a fast jpeglib based generator), and optionally support the GNOME thumbnail generators. The GNOME thumbnails generators are just tools that write the final thumbnail to a file specified on the command line, which is good. Unfortunately the GNOME guys decided to store the generator list in GConf, which means that the GNOME thumbnailer support will depend on GConf, and thereby comes at a certain price.

The thumbnail loading is quite fast, but nevertheless adds a little overhead (both memory and CPU time). Therefore we'll most probably include an option to disable thumbnailing completely. The good news is that Thunar is still very light on memory. A quick and dirty measurement (on a FreeBSD/i386 5.4-STABLE box with Gtk+ 2.6) shows, that Thunar's VmData size is at 2228 kb after startup (displaying the first 12 items from my home dir). For example, Nautilus' VmData size is 4368 kB after startup displaying the same set of files (in browser mode and without the sidebar), while ROX is at 2988 kB and Xffm-iconview is at 2532 kB. Of course this is far from a serious benchmark, but it tells me that we're on the right way.

What we really need with Thunar (or in a separate tool based on Thunar-VFS) is a way to cleanup dead thumbnails:

$ ls -1 ~/.thumbnails/normal|wc -l
   5867

Update

For the sake of completeness: Konqueror's VmData size is 4364 kB (KDE 3.4).

Drag and Drop

2005-09-02T00:00:00+00:00

I finally committed the drop-site support for the current views in Thunar (the icon and details view). I stumbled over a few oddities in the GtkDnD code that I have never noticed before, and the current code in Thunar is not yet perfect, as some things don't work properly (or don't work as expected) right now. For example, you can drag a file in nautilus and drop it on a Thunar view, but you cannot drag a file in Thunar and drop it in a nautilus view, odd.

In other news, we're close to hitting the current thread-length-record on thunar-dev with another website discussion. In short: This is how the Thunar website will most probably look like.

Debian packages for Thunar and libexo

2005-09-02T00:00:00+00:00

I just uploaded new Debian packages with Thunar and libexo snapshots to the os-cillation repository, so Debian/Ubuntu users can test Thunar easily without having to build and install them manually.

Icon view

2005-08-19T00:00:00+00:00

Committed the new icon view code to libexo today, and updated Thunar to use it.

KDE Viewer

2005-08-05T00:00:00+00:00

Jasper: I also read that articles, and they are indeed very good. Especially the number 8 on Ben's list is really a very good idea. It'd be just great to have something like Preview for Xfce/Gnome. Maybe Evince could turn into something like this.

File alteration monitoring

2005-08-02T00:00:00+00:00

Just committed a change to get file alteration monitoring working again in Thunar. I had more or less carefully evaluated the possibilities of doing the monitoring within the Thunar process, using a combination of various backends:

kevent (this was already in the first prototypes)
dnotify
inotify
regular stating in the main thread
regular stating in a separate thread

But every solution I could think of would add way too much complexity to Thunar with no real gain. So the monitoring will now be done solely by FAM or Gamin. I strongly recommend Gamin, because it offers several advantages over FAM:

Can utilize various modern operating system services like kevent and inotify.
Allows its client to disable the sending of FAMExists events, which aren't used in Thunar (nor in any other FAM-based software I've seen recently) and produce only unnecessary noise.
Runs as user process rather than system service.

On the other hand, if you use NFS mounted home directories, you should better stay with FAM for now.

For people that don't like file monitoring, just disable FAM/Gamin (or just don't install it) and Thunar will run without monitoring. The Thunar-VFS jobs will provide feedback to the monitor whenever they perform an action on the filesystem, so you should be able to work with the file manager even if you don't have FAM/Gamin, without the need to reload the folder manually after copying/moving/deleting files. ;-)

Thunar in Xfce SVN

2005-07-31T00:00:00+00:00

Thunar was finally imported into the Xfce Subversion repository today, and it's in quite good shape (although we're still not in time for Xfce 4.4).

Transfering files

2005-07-26T00:00:00+00:00

One wouldn't imagine how difficult it can be to copy/move files around. You can come up with cp/mv hacks within a few minutes. But doing it right, with user interaction, trash support, percentage/EST calculation and all the good stuff (threaded of course, and esp. without risking data loss on the user's side), seems to be surprisingly difficult. I guess it's time to stand up from the computer and do something else.

In other news, there's Mickael posting about Xfce is KDE done the right way, based on one of Jaspers screenshots: I doubt that Xfce will ever attract the average KDE user. There ain't enough bells and whistles in Xfce, or - to quote a colleague - Xfce just works. KDE users are a bit like Mac Classic users: It doesn't matter that much if something doesn't work properly (they'll figure out how to ignore the problem), but everything must be cute and cuddly. And personally, I wouldn't want to see Xfce turning into that direction.

Time

2005-07-20T00:00:00+00:00

It's wednesday already. Managed to finish my last math exam successfully this week and now I'm planning for my birthday party next saturday.

There's not much to tell from the Thunar front. I hope to have a release version ready by the end of the month, which will be imported into the Xfce SVN repository then, but no promises. Not sure if we can really release 4.4.0 this year, atleast its questionable for Thunar. But on the other hand, that shouldn't be a problem, as long as we manage to release prior to 20060116. And dropping Thunar from Xfce 4.4.0 now that we told everybody that it will be included with 4.4 won't work.

As always, whats needed the most is time.

Slow media

2005-07-16T00:00:00+00:00

While testing some volume manager related stuff, I tried to load a large folder from a CD-ROM (the i386 folder from one of my more or less unused Windows 2000 install CDs, which contains about 4000 files) into the tree view and it took forever, even after the folder content was visible (I suspect this is GtkTreeView loading icon data for the invisible items, tho haven't checked yet). And of course, since currently everything runs in the main thread, the GUI was blocked.

While I was aware of this problem, I decided to ignore it so far. On the solution side, we have basicly two possibilities: First we can do everything asynchronously or secondly we can do the fast stuff synchronously and add a "media://"-implementation, which does its work asynchronously (if somebody has a slow NFS-mount, he won't have fun with most probably every other program either, so we can safely ignore this case and focus on removable media). The first option is actually what I did for the very first prototypes and it turned out to be complex (I don't want to force everything into a limited low-level API like Gnome-VFS does, and so the high-level stuff would need to be thread-safe) and slow. The second option looks better to me, although it's still a lot of work to implement ThunarFolder and ThunarFile in a thread-safe way.

Future of xfce4-toys

2005-07-15T00:00:00+00:00

I just removed xfce4-tips from the xfce4-toys package, since it's now included with xfce4-session. Now the question is: Where to move the eyes plugin to (which is the only component left in xfce4-toys)? We have basicly three options:

Move it to xfce4-panel
Turn it into a separate goodie
Drop it (if Danny do not want to maintain it anymore)

Autostart editor

2005-07-15T00:00:00+00:00

Since we're now using desktop files instead of arbitrary scripts or symlinks, it is pretty easy to make the list of autostarted applications editable through a simple user interface. And so here's xfce4-autostart-editor:

xfce4-autostart-editor is now part of xfce4-session (trunk, rev 16232). I'm looking for an icon - or atleast an idea about how such an icon could look like - for this tool (unfortunately Francois is away).

New autostart mechanism in xfce4-session

2005-07-14T00:00:00+00:00

I just changed xfce4-session to use the new standard autostart mechanism, based on Waldos second draft. Your old autostart items from ~/Desktop/Autostart/ will be migrated automatically on first run of the new session manager.

Windows Explorer

2005-07-11T00:00:00+00:00

Looks like Microsoft's Longhorn will include a GtkPathBar-like navigator for Windows Explorer. Else the screenshots look like a random mix of Aqua and the Windows XP UI, with no real concept. But I'm sure they'll polish the stuff prior to the final version.

Menu merging

2005-07-11T00:00:00+00:00

I just added support for menu-merging based on GtkUIManager to the ThunarView. This was the last step in the reordering of the view stuff. Now there are only a few other issues to address before Thunar can be imported into Xfce's SVN repository. Maybe we'll also release an early pre-alpha version as suggested by Botsie.

Not many user-visible changes over the last weeks, but anyways, here's a new screenshot:

Lemmings

2005-07-10T00:00:00+00:00

Lemmings is always fun to play.

Xfce Developer Tools 4.3.0

2005-07-09T00:00:00+00:00

I should have done this a long time ago already, but anyways, here's xfce4-dev-tools 4.3.0. Download locations and installation instructions are available at

http://xfce.org/~benny/projects/xfce4-dev-tools/index.html

The guide isn't finished yet, and therefore neither in SVN nor in the tarballs.

A brief introduction to the Xfce Developer Tools

2005-07-09T00:00:00+00:00

Overview

The Xfce Developer Tools - xfce4-dev-tools for short - provide an easy way to handle the setup and maintaince of a projects build framework. They currently consist of a bunch of M4 macros for commonly used checks and the xdt-autogen script, which examines the projects configure.ac or configure.in file(s) and calls the appropriate autotools in the correct order.

As the name suggests, the Xfce Developer Tools are mainly useful for application developers to maintain their build environment. But users will also be required to install them if they plan to build software straight from CVS or SVN checkouts.

Preparing the project

In this section I will describe how to use the developer tools with your project. We will therefore examine a sample project and discuss the various steps. Our sample project will contain only a single binary, which does nothing useful. The project itself will be named sample, and will depend on libxfcegui4 and can optionally use D-BUS (this is only to demonstrate the usage of some of the M4 macros). And our project will be translatable to other languages.

We start off with the Makefile.am's and the source code. First, we create the projects directory layout:

$ mkdir sample
$ mkdir sample/po
$ mkdir sample/sample

Next the sample/main.c source file:

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <libxfcegui4/libxfcegui4.h>

#ifdef HAVE_DBUS
#include <dbus/dbus.h>
#endif

int
main (int argc, char **argv)
{
  xfce_textdomain (GETTEXT_PACKAGE, PACKAGE_LOCALE_DIR, "UTF-8");
  g_print (_("Hello World!\n"));
  return 0;
}

As you can see, we conditionally include dbus/dbus.h only if the HAVE_DBUS preprocessor macro is defined. The check for D-BUS is made in the configure.ac file, which is discussed below. Besides that, the only thing we do here is to print the string "Hello World!" in a translatable manner, after setting up the proper textdomain for gettext.

We continue with the sample/Makefile.am, which contains instructions about how to compile the sample/main.c file:

INCLUDES = \
  -DDBUS_API_SUBJECT_TO_CHANGE \
  -DG_LOG_DOMAIN=\"sample\" \
  -DPACKAGE_LOCALE_DIR=\"$(localedir)\" \
  -I$(top_srcdir)

bin_PROGRAMS = \
  sample

sample_SOURCES = \
  main.c

sample_CFLAGS = \
  $(DBUS_CFLAGS) \
  $(LIBXFCEGUI4_CFLAGS)

sample_LDFLAGS = \
  $(DBUS_LIBS) \
  $(LIBXFCEGUI4_LIBS)

The $(localedir) make variable is set by the XDT_I18N() macro and will point to the location where the translations are installed (e.g. /usr/local/share/locale). The $(DBUS_CFLAGS), $(DBUS_LIBS), $(LIBXFCEGUI4_CFLAGS) and $(LIBXFCEGUI4_LIBS) variables are set by the appropriate calls to XDT_CHECK_OPTIONAL_PACKAGE() and XDT_CHECK_PACKAGE(), which will be discussed below. Note that $(DBUS_CFLAGS) and $(DBUS_LIBS) will be empty if D-BUS was not found or disabled by the user.

We also need to define DBUS_API_SUBJECT_TO_CHANGE because the D-BUS API is not yet frozen, but that's an unimportant detail in the context of this article.

Furthermore we will also need a toplevel Makefile.am, which should look like this:

SUBDIRS = \
  po \
  sample

AUTOMAKE_OPTIONS = \
  1.8 \
  dist-bzip2

The AUTOMAKE_OPTIONS variable is used by automake to enable or disable special behaviour. In this case, the 1.8 tells automake that we need version 1.8 or better. And the dist-bzip2 option tells automake to generate a dist target, which will not only create the gzipped source tarball, but also a bzip2 compressed source tarball.

Now we are done with the Makefile.am's. The next step is to take care of the i18n setup. Therefore we need to create an empty po/ChangeLog file (the po/Makefile.in.in generated by glib-gettextize requires this file)

$ touch po/ChangeLog

and afterwards create the po/POTFILES.in file, which lists all source files (and sometimes other files like .desktop or .xml files as well) that contain translatable strings. In this case only the sample/main.c file contains a translatable string, so the file looks like this:

sample/main.c

Note that all paths in po/POTFILES.in must be relative to the projects toplevel directory. One last step before we go on to the configure.ac file is to create four required files for GNU projects:

$ touch AUTHORS ChangeLog NEWS README

You should of course add content to these files later on, but for now, we want to concentrate on the important facts, the contents of configure.ac:

dnl Version information
m4_define([sample_version_major], [0])
m4_define([sample_version_minor], [0])
m4_define([sample_version_micro], [1])
m4_define([sample_version], [sample_version_major().sample_version_minor().sample_version_micro()])

dnl Initialize autoconf
AC_COPYRIGHT([Copyright (c) 2005
Benedikt Meurer <benny@xfce.org>])
AC_INIT([sample], [sample_version()], [benny@xfce.org])

dnl Initialize automake
AM_INIT_AUTOMAKE([AC_PACKAGE_TARNAME()], [AC_PACKAGE_VERSION()])
AM_CONFIG_HEADER([config.h])
AM_MAINTAINER_MODE()

dnl check for basic programs
AC_PROG_CC()
AC_PROG_INSTALL()
AC_PROG_LIBTOOL()

dnl Check for i18n support
XDT_I18N([de])

dnl Check for required packages
XDT_CHECK_PACKAGE([LIBXFCEGUI4], [libxfcegui4-1.0], [4.2.0])

dnl Check for optional packages
XDT_CHECK_OPTIONAL_PACKAGE([DBUS], [dbus-1], [0.22], [dbus], [D-BUS support])

AC_OUTPUT([
Makefile
po/Makefile.in
sample/Makefile
])

You should be familar with most of the above, therefore we will only discuss the XDT_I18N(), XDT_CHECK_PACKAGE() and XDT_CHECK_OPTIONAL_PACKAGE() macros here. If you are not familar with the basic autoconf and automake macros, you should have a look at the GNU manuals.

XDT_I18N(LINGUAS [, PACKAGE])

This macro takes care of setting up everything for i18n support.

If PACKAGE isn't specified, it defaults to the package tarname; see the description of AC_INIT() for an explanation of what makes up the package tarname. Normally, you don't need to specify PACKAGE, but you can stick with the default.

XDT_CHECK_PACKAGE(VARNAME, PACKAGE, VERSION [, ACTION-IF [, ACTION-IF-NOT]])

Checks if PACKAGE >= VERSION is installed on the target system, using the pkg-config utility. If the dependency is met, VARNAME_CFLAGS, VARNAME_LIBS, VARNAME_VERSION and VARNAME_REQUIRED_VERSION will be set and marked for substition. For example, if you specify GTK for the VARNAME parameter, the variables GTK_CFLAGS, GTK_LIBS, GTK_VERSION and GTK_REQUIRED_VERSION will be set appropriately and substituted.

VARNAME_REQUIRED_VERSION will be set to the value of VERSION. This is mostly useful to automatically place the correct version information into the RPM .spec file.

In addition, if the dependency is met, ACTION-IF will be executed if given.

If the package check fails, ACTION-IF-NOT will be executed. If this parameter isn't specified, a diagnostic message will be printed and the configure script will be terminated with exit code 1.

XDT_CHECK_OPTIONAL_PACKAGE(VARNAME, PACKAGE, VERSION, OPTIONNAME, HELPSTRING [, DEFAULT])

Checks for an optional dependency on PACKAGE >= VERSION. DEFAULT can be "yes" or "no" (defaults to "yes" if not specified) and controls whether configure should check this dependency by default, or only if the user explicitly enables it using a command line switch.

This macro automatically adds a commandline switch based on the OPTIONNAME parameter (--enable-optionname and --disable-optionname), which allows the user to explicitly control whether this optional dependency should be enabled or not. The HELPSTRING parameter gives a brief(!) description about this dependency.

If the user chose to enable this dependency and the required package was found, this macro defines the variable VARNAME_FOUND and sets it to the string "yes", in addition to the 4 variables set by XDT_CHECK_PACKAGE(). But VARNAME_FOUND will not be marked for substition. Furthermore, a C preprocessor define HAVE_VARNAME will be placed in config.h (or added to the cc command line, depending on your configure.ac content) and set to 1.

First run

Now that everything is in place we are ready for the first run. Therefore, go to the toplevel directory of the project and execute the

$ xdt-autogen

command that comes with the developer tools. This will run all the required autotools (in our case these are glib-gettextize, libtoolize, aclocal, autoheader, automake and autoconf), and afterwards run the generated configure script.

The next thing to do is to generate all language files specified with the XDT_I18N() macro (we've only specified de in our configure.ac). Therefore execute the following commands:

$ cd po
$ make sample.pot
$ cp sample.pot de.po

Now if you check po/de.po, it will contain exactly one translatable string, the one from sample/main.c.

That's it, now you can simply run

$ make

in the projects toplevel directory in order to build your project for the first time. Congratulations, you've successfully completed the build framework setup.

The source code for the sample project is available here.

For more details on the internal workings and the other available macros, check the M4 files in the m4macros/ subdirectory of the Xfce Developer Tools distribution.

No software patents in Europe

2005-07-06T00:00:00+00:00

Very good news. No software patents in the EU for now.

Debian update

2005-07-06T00:00:00+00:00

Started to update the os-cillation Debian packages to 4.2.2. Ubuntu guys should sync these once done. Unfortunately that takes a lot of time. Need to reevaluate the idea of a Xfce debian team, so others can help in maintaining the packages. Shouldn't be a problem now that we have SVN setup on espresso with fine-grained access control. Need to discuss with Auke.

4.2.2 done

2005-07-06T00:00:00+00:00

uhm, I shouldn't be awake. Nah, whatever. Updated all packages to 4.2.2. Not sure about the xffm4 package, I think Edscott changed something, but I'm not in favour of figuring out what it was right now. The package looks ok in that xffm still starts. Drop me a note if something broke. Also noticed that Erik released mousepad 0.2.2 some time ago - why did nobody tell me? - and the mousepad package is also updated now. By the way, mousepad is really a very bad name. Try goggling for mousepad and you'll know why. ;-)

Orage is better than Xfcalendar

2005-07-05T00:00:00+00:00

Mickael: Orage is a lot better than Xfcalendar. I never really liked that xf prefix (it's ok and maybe even necessary for core desktop services, but not really nice for general applications).

It just doesn't work(TM)

2005-07-05T00:00:00+00:00

I just spent some time reading through the recent Why Linux won't work on the desktop and The Linux desktop of the future stuff. Just works(TM) seems to be the most important point today, and many projects claim to follow that idea. My experience is that most things just work if [long list of conditions skipped].

Playing the devils advocate, I think that things are even worse than before on the Unix/Linux desktop: While some time ago, a lot of stuff was very Linux specific and you had to port it yourself if you happen to run a Unix or a BSD system, today you have to run a specifc Linux distribution (at a specific version) to get a chance to have certain things running. So instead of being Linux specific, which is already not a good thing, stuff is now Linux distro vendor specific. A simple example: Try to get Mono into a usable state on a slightly out-of-date Debian system (yeah, I know, Debian is always a bit behind, but this is really just a bit behind the latest stable release for various reasons): It isn't trivial. It's just pain. Waste of time probably.

And there are several other examples. HAL comes to mind here. The initial idea was very good. A platform independent hardware abstraction layer. But in it's current state you need to run a very specific version of the Linux kernel. No chance to get see this running on anything else in the not so far future (yeah, I know there's a solaris/osspec.c, but if you look closely, it's just a dummy).

I remember a time where the vendor-independence was a big plus for the Unix/Linux desktop, and I remember a lot of people complaining about the dependency on Microsoft for the Windows products. Now, it looks like the vendor-dependency is being ported from Windows to Linux.

Sure you could say "The stuff will be ported at a later time", but let's be honest, Microsoft could tell exactly the same.

I was very surprise to see that from the big two on the Unix/Linux desktop, KDE is far ahead of GNOME when you use it on a machine that doesn't run a product made by RedHat or Ximian/Novell. You get nearly 99.99% the same functionality with an old Linux/i386 system, a new Linux/i386 system, a Solaris/sparc and a FreeBSD/i386 machine. That's pretty amazing and very encouraging. It's nearly as platform-independent as Xfce. ;-) Although, to be fair, KDE provides a lot more services than Xfce, so you can say, the KDE people did a good job. With recent GNOME releases it's kinda frustrating, esp. if you just want to check something in Nautilus (e.g. to verify that Thunar will behave similar). For example, I don't see any removable devices on FreeBSD or on that older Linux machine, although Konqueror displays them. Even the Thunar prototype does that already in the BSD volume manager implementation, and it's really easy. Even CDE provides better volume management on Solaris than recent GNOME versions. Then the SMB module in GnomeVFS. I have no clue about SMB and CIFS, but even Xffm works way better than GNOME here. GNOME never sees the Windows machines during testing. And there are several other things that don't just work.

Now I'm not a desktop user. I don't use a file manager. I mostly interact with applications running inside a terminal emulator. And of course, browser and mail reader. But I wasn't talking about myself. I was talking about the average user. And the average user won't be pleased to discover that just works is bound to 100 conditions (atleast if his system does not fullfil 99 of these conditions).

It may look like an advantage to Novell to ship something with their distribution, which doesn't easily run on other systems as well. But if you look back in time, that wasn't the way of the world so far. Imagine back in the days before the internet as you know it today, somebody would have come up with: "Hey, here's TCP/IP and there's the socket interface, which can be used to connect networks to form the internet. But, ehm, you'll need to run 4.2BSD to use it. You cannot get it to work on other systems. That's intentional. Everybody should run our beloved system." Doesn't sound like this would have worked, does it?

It's more than ok if the first public version doesn't support all the operating systems out there. But it would be good if released software would run equally well on all supported systems. And in the case of GNOME: While the desktop is in reality just the core of C programs, most people also think of 3rd party stuff like Beagle, etc. as GNOME components, and it doesn't matter if you tell them that it's not part of the core and thereby not officially supported; they'll be disappointed to see that only half of their GNOME works.

To conclude (as usual, just my 2 cents, nothing that's neccesarily true): With the current direction, it is very doubtful that the Unix/Linux desktop can compete with Windows and OSX in the future. That's even independent of Microsoft and Apple. The problem is that people started to cut off their very own roots.

Desktop notification (in reply to Chris)

2005-07-05T00:00:00+00:00

In reply to Christian's comment on my last blog entry:

I read the spec right before writing the blog entry, and I basicly followed the discussion on xdg-list earlier.

The spec covers some basics. But from my point of view, the focus of the reference implementation and the spec is wrong.

First of all, your reference implementation is the most important point for now, simply because that's what people see. You could write a perfect spec, people will always check your reference implementation first. So all oddities (really mainly the odds, not the bugs) will affect the acceptance of the spec. My feeling is that Galago is currently trying to catch people with those nice popup effects seen on other operating systems - but I don't follow that project very closely, so I may be wrong here. Still it is a problem for your project if developers (and users) see your project as eye-candy only.

Then, back on topic, the filtering issue. You really want to do filtering on the daemon side, because else if the client would filter events, those would never show up in the event log. And besides that, this is the only way to ensure that all the filter information is managed and stored in a single place. But to be able to allow useful and flexible filtering in the daemon, the client must provide as much data as possible. And in order to allow easy configuration, the client must also provide information about the filter tags.

The spec currently provides two tags for filtering: The notification type id and the urgency level (I'd strongly suggest to provide more than 3 levels by default). The application name is pretty useless, as the spec explicitly states that this should be the formal name rather than a unique id. And formal names are not garantied to be unique and may change over time. The notification type id is a single string and thereby not suitable for non-trivial filtering. E.g. I can only say, that I'd interested to know whenever an IM buddy goes online. I cannot say Tell me when Harry goes online (sure, you could use something weird like im.user.harry.online, but that's really only a work-around for a limitation in the system). Two criterions are simply not enough to perform useful filtering.

Then, the configuration issue: If you want to do filtering in the daemon (and you really want to do this if you plan to support event logging), then there must be a way for clients to tell the daemon about the different filter tags and the default settings, and at best also an interface to allow clients to change the settings easily. I proposed to use a simple XML file here, installed by every client that supports desktop notification, but that was just a suggestion, you could use any other file format. The file name would somehow include the application's unique id. You would also store thinks like the application icon and the sounds to play for a specific event and such within this file, which allows integration with desktop wide sound themes, etc.

What really bugs me about the spec and the way this is started in GNOME currently is the fact that important issues like filtering get nearly no attention, but instead the focus is on minor details like the appearance (esp. since the spec explicitly states that "applications can generate passive popups", which somehow makes it less suitable for a general desktop notification spec). I'd welcome if people would focus on the important parts first, and don't focus too much on details like how to display the messages (and there should be really more than one way to display notifications, atleast something non-disturbing like an icon in the systray).

Note that these are just my 2 cents. I'm not an expert in desktop notification, nor do I have any time or interested to work on the spec or the implementation (well, maybe an implementation for Xfce, once there's a usable spec, but not this year). So you may disregard my comments silently. But I really strongly recommend to revise the spec, because else I'm pretty sure, this won't be the standard for a long time.

Icon theme cache

2005-07-04T00:00:00+00:00

Edscott, how about using the icon-theme.cache generated by gtk-update-icon-cache instead? There are several advantages: First - and foremost - the cache is shared by all Gtk+ apps and therefore it's likely that most parts of the cache are already loaded. Second, both the image data and meta-data is contained within the icon cache, and thereby safes you a lot of disk I/O in the common case. And last but not least, there's already an implementation of the icon cache, namely GtkIconTheme.

Desktop notification

2005-07-04T00:00:00+00:00

Really, I don't get this. The GNOME guys started the libnotify integration (once again?), which lead to controversial discussion.

I wonder why things have to be that complicated all the time. Why not simply design a desktop notification system based on the ideas used in system notification - namely syslog. Speaking from the flexibility's point-of-view. You have different, pre-defined levels of importance. And you have various services, like Thunderbird or the battery monitor, that want to present notifications. Now the user can choose based on the level and the service, how to present the notification (e.g. popup notification for events from the battery monitor, and simple, non-disturbing, systray notification for Thunderbird events). All events will be logged and it's possible for the user to access/clear this log. In addition, you could allow the services to tag their messages using simple strings. For example with an instant messenger, if you're only interested about online/offline popup notifications about your friend Harry, you'd add a rule to the notification server saying it should display a popup for notifications tagged with "online-state-changed", "Harry". For easier usage, the notification server should allow its connected services to also modify certain settings. So, all the user would need to do is to right-click on Harry's buddy icon and toggle Tell me when Harry is online/offline.

Of course, sane defaults should be choosen for the different services. Services would need to install an XML (or whatever) file to tell the notification server what they do, which events they provide and whats the default way of notification.

This way you'll have a very flexible, but yet easy to use system. The average user will probably just stay with the (sane) defaults, while the more advanced users will reconfigure certain aspects. And the logging of the events ensures that you don't miss events while you're away.

Does KISS mean nothing in today's open source world?

Where do you want to go, Gnome?

2005-07-02T00:00:00+00:00

Just discovered on the nautilus mailinglist:

Looks familar, eh? The full thread is here.

Freedom

2005-07-02T00:00:00+00:00

Just read this article (german). Wow. Best heise article I've read so far.

Thunar Firefox-like location bar

2005-06-28T00:00:00+00:00

I decided to upgrade the currently available libexo debian package to revision 85, so Ubuntu/Debian users do not need to compile libexo themselves in order to run the Thunar mockups or the currently available snapshots. The API shouldn't break during the next weeks, so you're mostly safe to upgrade.

And while I was at it, I also updated the Xfmedia package to the latest 0.9.0svn snapshot, so users of that package are now able to also enjoy the new jump-to-file thingy - which I still think is very annoying, esp. with large playlists, where the tree model switching causes ugly flickering, but Brian likes it that way currently, so you'll have to live with it or use another media player. ;-)

I may update some of the Xfce core packages as well during the week. Most of the current trunk stuff is pretty stable. Maybe that stops people from sending me mails, asking when the packages will be updated next time. Nah, but seriously, with 4.2.1.1 in Ubuntu universe and 4.2.2 in Debian experimental, it's time to think about 4.3 now.

Qt4

2005-06-28T00:00:00+00:00

So Trolltech finally released Qt4 today, and their servers are nearly unreachable all day. We'll most probably stay with Qt3 for a long time tho, as it would be too costly to upgrade to Qt4. Even trivial programs take a lot of time to migrate, and we have way too much non-trivial, partly plattform-dependent code. Nevertheless we checked the new Qt4 today. What makes me wonder is that in all the announcements and relnotes, there's not much mention of the new accessibility support of Qt4, which is IMHO the most important addition to Qt (besides the model/view separation).

Terminal day

2005-06-27T00:00:00+00:00

Finally came around to fix some long standing issues for Terminal. While profiling stuff I found out that VTE uses around 24M data memory to manage 13 VteTerminal widgets, which is really a lot of memory.

And then there was trash...

2005-06-22T00:00:00+00:00

The ThunarFile and ThunarFolder interfaces are now completely independent of the specific implementation. This makes it possible to support various different file systems with Thunar. As a first candidate, I implemented a first draft for the Trash vfolder today, which means Thunar is now able to display the contents of the trash cans currently connected to your system - well, in theory it is, but the trash manager doesn't handle foreign trash cans currently, but it will soon. :-)

Diving into trashed directories isn't supported yet, but shouldn't be a problem with the current interfaces.

Signals

2005-06-21T00:00:00+00:00

One thing missing from GObject and esp. the signal system is that there's no way to control the order in which signal handlers will be fired except the after flag, which isn't very powerful either. Sure, 99.99% of all applications will never need to be able to have fine-grained control about the signal invocation order, but then there's always atleast one application, that needs this feature in order to avoid other weird work-arounds.

Thunar is such an application and the use-case is pretty simple: We have a ThunarIconFactory class in Thunar, which is used to load icons and perform some kind of caching on the icons, so you don't need to grab them from the disk everytime. Now if the currently selected icon theme changes, the icon cache must be cleared before other modules get informed about the icon theme, as they'll immediatly perform an icon lookup. So, the order in which the signal handlers are invoked matters. Unfortunately you have don't necessarily have control about the modules, it can be code in Gtk+ or other libraries. Sure you could say, the icon factory is the first object I create and so it's signal handler will always be fired first, but that's really messy, as - according to murphy's law - somebody will forget about this condition at some time (no matter how much comments you add to that code) and you'll have a very, very hard to find bug, because you simply don't think about that condition in the first place.

As a work-around, and that's what we're now used with Thunar, you can connect a signal emission hook to the "changed" signal of the GtkIconTheme class. Emission hooks are garantied to be run before any signal handler is fired (the default handler may run first, depending on the signal flags, but that's no problem for us). Ok, this sounds cool so far. Unfortunately emission hooks aren't bound to instances, but to types. And so whenever the "changed" signal is run on any instance of GtkIconTheme, the emission hook will be fired. While in theory this looks like a bad thing, in practice with the icon theme class, this is not a big deal, as you only have one icon theme per screen (or maybe even only the global icon theme) and so the worst thing that can happen here is that you loose the icon cache for all screens if you change the icon theme (which is not really a common action).

So, problem solved. But the solution is pretty hacky, tho no real need to break GObject. Just wondering...

And just right now Gtk+ 2.7.0 was announced with lots of breakage - have fun fixing your custom widgets if you used to use Xlib directly. ;-)

Hierarchical Spatial

2005-06-21T00:00:00+00:00

According to murrac, patches have been applied to Nautilus CVS to implement a tree view on a spatial view similar to what is possible with Aqua/Classic Finder. Judging from the screenshot this looks very similar to what xffm (and xftree in the Xfce3 days) did and still does if started with xffm. Sure the UI looks cleaner than the default xffm UI, but at the core its the same concept. So, if that's what is needed to stop people complaining about the spatial Nautilus, why didn't they use xffm instead (probably even sending some patches to edscott to polish the default UI)?

Trash me, baby

2005-06-19T00:00:00+00:00

Postponed all work on the icon view for now, and been working on the volume manager and the trash implementation for the last 2 days. As initially planned, the ThunarFile class is now an abstract base class and the ThunarFolder class will be turned into an interface or an abstract base class as well. In addition, the ThunarFile class won't export the associated ThunarVfsInfo (which is now only associated with ThunarLocalFile instances). This way we don't limit ourselves to file implementations, which are more or less based on stat(2) directly. For example, there will be virtual files, like the trash can itself, and forward files like the trashed files. You could even imagine another class that handles locations other than file:// and trash:// using GnomeVFS, to provide support for network file systems and such. But that is an optional gimmick and not important right now.

While working on the trash classes, I was testing the basics when I realized that the far-from-being-complete implementation of the ThunarTrashFile and the not yet adjusted ThunarFolder class lead to an interesting effect:

I was pretty confused to see this working on first sight. My bet was that it would crash right away. But of course, it had to work that way. Anyway, not the expected behaviour from a user's point of view, but it looks just too weird to not post the screenshot here.

Linux for losers

2005-06-18T00:00:00+00:00

A friend of mine pointed me to an interesting article today, which on first sight looked like just another useless Linux vs. BSD article, esp. since it quotes Theo De Raadt, who was never known for being very objective. But De Raadt points out some real problems with the Linux development model (everybody that has ever worked on the kernel or a non-trivial driver will be aware of these problems). Unfortunately, De Raadt's diction is very bad, as usual, and so it's unlikely that any of the Linux guys will pay much attention.

But the problems with quality assurance is not limited to Linux in the open source world. Many OSS hackers still seem to believe, that "if it runs, it's good", which is obviously not the case. There's a common misbelieve that the crux in being part of the OSS world is knowledge about coding (it'd rather use the term hacking). From my experience, coding was always (and is still) the easiest part of the story. The hard work is to figure out what to code, and how to organize the various modules, to make it fit into the whole picture, and once the implementation is done, verify that the implementation covers all use cases and performs well. This is the shortest possible definition of my understanding of how to develop high-quality software.

But in order to develop the way described above, you need to setup clear goals for your projects. And this is exactly the point where Linux and many other OSS projects lose. They concentrate too much on providing an universal solution or on adding a new feature as soon as possible, and so improvements happens by fluke many times, not as a result of structured development and quality assurance. And even if they're pushed by big players like IBM at the moment, this kind of development won't work in the long run.

I'm not trying to blame Linux/OSS hackers, instead I strongly invite people to think about their development models and their understanding of open source. Take the chance to develop high quality software in your spare time; many of us will be forced to develop low quality software in our daily job anyways (yannow that money thing), so don't you think you could do better in your spare time? Of course it takes time and the feeling of success won't show up that early, but in the end you can be proud of your work.

Of course I could also be completely wrong here, and my understanding of open source is simply escapist.

All quiet on the western front...

2005-06-18T00:00:00+00:00

It's been very quiet in the Xfce community lately. The traffic on thunar-dev and xfce4-dev is amazingly low. I'm currently the only one to work on Thunar, tho Alexander, Jean-Francois and Brian have expressly declared their interest to help earlier. In addition the Thunar website project seems to be fast asleep.

Well, I'm not in a hurry. I'm wondering because 3-4 weeks ago, many people were offended at me for taking a break from the public. And now I'm still working on it alone, like I did 3-4 weeks ago. Maybe the debate was just full of hot air.

Concerning the Xfce Debian packages: We receive quite a lot of mails recently, asking for the status of the Xfce Debian packages. The Xfce 4.2 stable branch is now maintained by Ubuntu people. We will provide new packages once Xfce 4.4.0 enters ALPHA/BETA stage. People using plain Debian should consider upgrading to Ubuntu or using the so called official Xfce Debian packages (dunno how up-to-date or usable they are, tho).

You could also try the Xfce 4.2.2 packages for Debian, prepared by Mario Izquierdo, which are based on our Xfce 4.2.1.1 packages. His repository is available here.

Testing GtkIconView 2.8

2005-06-16T00:00:00+00:00

I refactored the new GtkIconView into an ExoIconView implementation, added the required magic to ExoCellRendererEllipsizedText and did some testing. The result was disappointing: It is very slow for large models (1000 items and above), esp. in resizing and rubberbanding, even on a fast machine (with Render hw accel). I imagine that it would be frustrating to use Thunar with this icon view on a slightly slower machine. Besides that it contains some tricky rendering bugs (one of which looks pretty similar to a bug I've also in my own experimental icon view, where the focus rect is not cleared properly sometimes).

I'm sure there's a lot of potential for optimization in the new GtkIconView, but since the source file contains about 9000 lines now and internals have changed quite a bit, this would waste a lot of time and energy. And so, I'll finish the work on the old ExoIconView, which is reasonably fast already, even with very large models.

Icon view renderer

2005-06-16T00:00:00+00:00

I just updated my gtk+ sandbox and, wow, the new GtkIconView in gtk 2.8 does exactly what is required (atleast from a first look), without breaking the API, thanks to RedHat's Matthias Clasen. The new icon view uses cairo for rendering, which of course leads to flickering and rendering errors if combined with the good old way of rendering things in GDK, since the cell renderers in a Gtk+ 2.4/2.6 installation still use plain Xlib functions (through the GDK wrappers). But this is more or less easy to fix, as we can use GDK functions instead of cairo functions (probably Xrender for the rubberband... tho, unfortunately the most interesting function in GDK here isn't public).

In addition, there are some problems with the cell renderer text API in gtk 2.4/2.6, which doesn't include the wrap-mode and wrap-width properties. But these properties are required to layout the text properly. Again, not necessarily hard to work around; if everything else fails, the ExoCellRendererEllipsizedText class will be extended to support the text wrapping properties and will be used as default text renderer.

The more important problem is that my performance patch for the old ExoIconView won't work with the new GtkIconView class, atleast not without major rework. The patch basicly replaces the GList-based item handling with a faster array based solution, which reduces both heap fragmentation and reduces time spend in malloc and time spend in loops looking up the item for a given index. The next step was to use a static item layout, which makes things like looking up the item for a position or determining the items within a rubberband selection very fast (tho, that was still work-in-progress and didn't really work). Well, I guess, I'll first import the new icon view and stuff into libexo and do some testing on it, and then we'll see how important it is to forward-port the performance patches.

Icon view item renderer

2005-06-15T00:00:00+00:00

One of the first things that perplexed me when I looked at GtkIconView (back in the gtk 2.5 days) was "why the hell is there no GtkIconViewItemRenderer?". I guess somebody was worried about performance and therefore the renderer was hardcoded into the first icon view implementations (which is of course not very flexible and can lead to weird work-arounds on the model side). Unfortunately, I hoped that over the time somebody else would notice the problem and magically fix it for the stable 2.6 icon view.

Now, that was not the case. Gtk+ 2.6 API has stabelized and no GtkIconViewItemRenderer. We'll have to implement our own renderer-based icon view with ExoIconView, which means that once that is done, not only the icon view implementation in libexo will differ from gtk+ (there are some major performance improvements pending for libexo 0.3.1 or 0.3.2), but also will ExoIconView provide the programmer with a completely different interface.

We really need this flexibility for the icon view in thunar, in order to be able to render emblems, etc., in a simple and fast way. The alternatives would be either a full-featured canvas widget (like Nautilus does with EelCanvas) or to pre-generate pixbufs with the embedded emblems in the list model, which would mean unnecessarily creating and copying a lot of pixbuf stuff. Both alternatives are certainly not very well suited for a fast (and lightweight) file manager.

Volume Manager (2nd)

2005-06-14T00:00:00+00:00

I tried to come up with the basic requirements for the volume manager interface and did some prototyping with the BSD implementation. My mail to thunar-dev, which summarizes the results of my current research, is still pending - I guess I shouldn't attach source code to mails. :-)

Anyways, I think I caught the basic requirements for Thunar 1.0:

The question that remains is whether the volume manager should be implemented in the Thunar binary or as separate D-BUS system service. There are pros and contras for both solutions. If you feel like you have something to say about this topic, wait for my mail to arrive on thunar-dev. :-)

The prototyping with the interface described by the requirements above was satisfactorily so far. I hacked up a simple interface to the volume manager for the favourites pane and it now shows all removable devices, whose medium status is active, like in the screenshot below:

Hopefully the discussion on the volume manager will come to a useful result soon and work on the trash system design can start.

Volume Manager

2005-06-12T00:00:00+00:00

After spending some time improving the ThunarVfsURI internals (handling schemes other than file://, performance improvements and the like), I took the time to refine the basic requirements for the volume manager. The volume manager provides core functionality required for the trash system to work (esp. since my current plan for 1.0 excludes trashing to the "home trash" as fallback).

From the high-level view, the volume manager module looks pretty simple:

The main goal is to provide a small interface, to support many different backends, but still includes all the functionality required for the upper layers. Back in 2003, I rewrote the core of the fstab plugin for xffm with support for many different platforms, so the basic code (which now also includes a few bugfixes) is there. We could also add HAL support later, but since HAL is only supported on Linux and isn't widely used currently, this has very low priority (maybe even a TODO item for Thunar 2.0).

The important work for now is to define an interface to the volume manager, that allows the trash system to query the list of active trash cans (and also get notified once a new trash can is online) and the favourites view to display the list of removable devices. The favourites view also requires the ability to mount and umount/eject devices.

By the way, I'm looking for a term to describe the "eject/umount" action in the GUI. While "eject" is fine for CDs, it's simply wrong for other removable media types, such as floppies or usb sticks - imagine an USB slot with the ability to fire off usb sticks. ;-)

Favourites

2005-06-11T00:00:00+00:00

I have a more or less working prototype for the ThunarFavourites module now (well, it currently works a little bit different from the shortcuts list in GtkFileChooser, but I'm not going to care for that now). You can add favourites using DnD from every DragSource that supports text/uri-list (e.g. from the location buttons or another file manager such as Nautilus), or reorder favourites internally. There's no way to remove favourites currently (except editing ~/.gtk-bookmarks manually of course), but that's not important for now. All the low-level stuff in ThunarFavouritesModel is connected properly now. So the next step is to add some more stuff to the ThunarIconView GUI, and then I'll be ready to continue work on the low-level stuff, esp. the VFS Monitor and the trash system (unfortunately nobody volunteered to help with the trash system).

Note that this doesn't mean, that the prototype can do anything useful now; it's just in a state where it can be used to test the underlying modules from the GUI, not only from automated test suites.

On the usability front, Erik and David seem to be serious about the usability team which will be a real win for Thunar - and probably for Xfce as well, tho it was a bit problematic in the past with usability suggestions, the last failed attempt from Eugenia comes to mind here. ;-)

Perl guru wanted

2005-06-10T00:00:00+00:00

os-cillation is looking for a Perl guru to take part in a bigger project. So, in case you are looking for an interesting job and live in Siegen, Germany (or near to Siegen), send a mail to info@os-cillation.com.

Another website mockup

2005-06-10T00:00:00+00:00

Benjamin Muskalla came up with another website mockup today. It's clean and simple (the side pane is a bit busy probably, but that could be optimized). The mockup is available here.

My window manager is faster than yours

2005-06-09T00:00:00+00:00

Enlightenment's Carsten Haitzler (the rasterman) came up with a benchmark about 2 weeks ago, that was meant to measure the performance of today's most popular window managers for X11. Surprise, suprise, E17 is on top of both lists.

His benchmark tool measures both the throughput of a window manager (mapping windows and testing the time taken by the window manager) and the response time (measuring the time between the XMapWindow request and the map to be done). The benchmark itself is well done and ok. Unfortunately, the result tells nothing about the daily use of a window manager, tho.

But it's good to know that there's E17, just in case I'll ever need a window manager that can handle 260 window mapping requests per second.

The article itself is definitely a good marketing joke to make people aware of E17, but not a serious benchmark for common use-cases of a window manager. And indeed, it works pretty well: E17 will gain a lot of new clueless users thanks to this article (maybe even some smart users, who just came to know E17 by this article).

Location buttons

2005-06-08T00:00:00+00:00

People tend to prefer pictures, so screenshot first:

On the informative side, I redefined the basic UI interfaces, and now all navigational UI elements in a ThunarWindow will implement the ThunarNavigator interface. In addition, there are separate interfaces for elements that can be placed in the side pane and for elements that provide a location bar. This makes support for plugins in this area very easy. The main view does not implement ThunarNavigator currently, because it needs special treatment to get proper error handling (e.g. if a user tries to enter a directory, which he's not allowed to enter, the window should display an error message and fallback to another directory, and this must be performed by exactly one module, the ThunarWindow, and so the ThunarWindow must perform the initial opendir on the folder). In addition, there must be async error support for the main view to properly support error handling with the ThunarVfsMonitor module.

Website mockups

2005-06-05T00:00:00+00:00

Henrik Andersen and Nick Schermer came up with two mockups for a Thunar website: Henrik's mockup can be seen here, Nick's mockup is here.

Just another screenshot

2005-06-05T00:00:00+00:00

Spent the day implementing additional parts of Thunar's core.

Spatial Thunar

2005-06-04T00:00:00+00:00

I took the time and implemented parts of the core functionality for Thunar, as thunar-dev is pretty quiet when it comes to code-independent development. Below is a screenshot of the very first test application showing the some of the core classes in action - it's really spatial and it'll never be that spatial again. :-)

I decided to postpone my plans for a fully multi-threaded core. There's actually a lot of stuff to take care of in order to make it both right and fast. It's not necessary possible to completely hide the multi-threadedness within the ThunarFile and ThunarFolder classes, so people writing high level classes like ThunarListModel, ThunarTreeModel or ThunarDesktopView, would be presented with a more complex interface, which in turn can decrease the stability of the whole application.

The approach taken now is faster for loading directories and it makes things way easier to handle, but it can make the UI feel unresponsive while loading large directories or loading from slow media.

Progress again

2005-06-02T00:00:00+00:00

So, I'd say the "Shame on you, Benny"-debate is over and we're able to make progress again. Atleast, Jasper is requesting input. I'm going to prepare a small collection of diagrams with the most important stuff I've set up so far and that'll be the rough direction for the next weeks. While the lower-level stuff is mostly settled (the left-over stuff is mostly implementation specific), the high-level stuff is mostly undefined. E.g. somebody would have to work out a set of preferences that should be configurable for Thunar. For techies, there's the outstanding ThunarTrashFolder and ThunarTrashFile to define and implement (the latter is pretty simple, the most important thing here is to override the get_visible_name() method using the name set when trashing the file, but the former is really complex and care must be taken so the implementation does not result in something completly unmaintainable). There are a few more open issues (bookmarks, treepane, removable devices, ...), so people that complained previously should be able to get their hands dirty really soon (but as a limitation, developing on Thunar is not firing up vi and starting to write code).

Clearance

2005-06-01T00:00:00+00:00

I don't want to stop work on Thunar - with the initial goals. I really like the idea of a simple file manager. The question is rather whether it fits with Xfce (or whether Xfce fits into the picture).

Edscott about Thunar

2005-05-31T00:00:00+00:00

Edscott sent some comments about Thunar development to thunar-dev today, with similar contents like a mail he sent me previously some time ago. It's seldomly the case in conversation with Edscott, but with these mails there's really nothing I could say against or in addition. He'll most probably be either flamed or ignored for his mail, tho.

In the meantime, I worked on some ideas for the backend code (I'm still thinking to use GnomeVFS instead if this turns out to get too complicated, because there's no valid reason to reinvent a tricky wheel):

Development continues

2005-05-31T00:00:00+00:00

I decided that development on Thunar as part of Xfce will continue, but with some limitations, which will help to keep the fun with the project.

Break

2005-05-30T00:00:00+00:00

Now that were two really busy months - april and may - for me (up to 300 hours each), and it was a necessary break from Xfce for me. Somehow I lost not only my interest in Xfce, but more important, it was no longer fun for me. To me it looked (and still looks) like Xfce development is going into the wrong direction. I'm not yet sure if and how I will continue my contribution to Xfce. I started to do some long standing stuff for libexo/thunar yesterday. But reading the last suggestions on thunar-dev made me think that there's no need for a simple file manager in Xfce. Maybe Xfce people should extend Xffm even more, rather than developing a second not-simple file manager.

Too much work...

2005-04-01T00:00:00+00:00

So, CeBIT 2005 is over and - as usual - the result is: A lot of work. Very interesting work, tho. But it leaves me with no time for xfce (besides that, my energy level is near to zero when I return home). I don't even manage to read all my mail currently.

Speaking from the recent mail subjects on the xdg list, work is going on with D-VFS and there seems to be another attempt to standardize the icon names for icon themes, which is a very, very good thing.

On the thunar front, there seems to be a lot of discussion concerning a different name (I haven't read all the mails, still 23 unread mails in thunar-dev, but from those I read, I'd say Thunar is still the best name), and Benjamin Cohen came up with a patch for auto-completion for the prototype, I'll look into this tomorrow.

A quick look at the OSNews poll tells me, that Thunar wins again with 11% (and 89 comments is quite a lot for an Xfce sub project, that did not release a single line of code). Besides that, when will people realize that it's Xfce not XFce? ;-)

That's all for the day, my bed awaits me...

Thunar - Name of the Beast?

2005-03-29T00:00:00+00:00

The name discussion started once again. Most popular seems to be:

Secretary
Nomad
PathFinder
Digger

for now. Personally, I still prefer Thunar for the reasons described in this mail.

On a related note: Thunar was on OSNews already (why did nobody tell me?), and people commented on the Suggestion 20050320. I tried to get some useful information out of the comments, but it's hard to decide what's useful and what not (the slashdot syndrome). It'd be better if people would suggest/comment stuff on thunar-dev instead.

Caching MIME information

2005-03-29T00:00:00+00:00

RedHat's Matthias Clasen came up with the idea of caching the MIME information provided by the Shared MIME database (the list of MIME type aliases, subclass information, the glob patterns, the magic patterns and the XML namespaces) in a mmapable file today. With his attempt, there'll be one cache file (mime.cache) per mime directory, e.g. on most Linux systems, this will be

/usr/local/share/mime/mime.cache
/usr/share/mime/mime.cache
~/.local/share/mime/mime.cache

while on for example FreeBSD, this will be

/usr/X11R6/share/mime/mime.cache
/usr/local/share/mime/mime.cache
~/.local/share/mime/mime.cache

(both with default $XDG_DATA_DIRS settings). He also provides patches for both xdgmime (the MIME implementation used by gtk+ and gnome-vfs) and update-mime-database.

The general idea is good, and the implementation looks good too. We should consider using the cache for Thunar as well. My major concern about this currently is the bad data locality with many mime.cache files (which should only happen if the admin is on crack) and the probably reduced performance due to the big endian to little endian conversions (we need a benchmark here to decide if it's really worth to spend another thought on this conversion). If we'd adopt this idea for Thunar, we could further reduce startup time, as the process would not need to parse the MIME database first, and it would reduce the memory overhead, tho this is less critical in case of Thunar, since all windows (and the desktop background) run in the same process space and thereby share the MIME database.

Anyways, it's nice to see some useful activity on the xdg mailinglist again, after all this discuss it to death-threads about D-VFS and gconf.

Edit: Additional notes can be found in this mail.

Thunar - No feedback

2005-03-27T00:00:00+00:00

Looks like Thunar does not attract software developers (yet), at least they did not respond to my last mail to thunar-dev. Somehow it looks like we got a bunch of users and hackers hanging around on the mailinglist and waiting for code or mockups to play with, which is fun of course; but we need more dev activitity on the dev mailinglist. ;-)

Thunar Relations

2005-03-25T00:00:00+00:00

Some more thoughts on the Thunar architecture:

This diagram illustrates the basic relations within the Thunar backend (and also includes a few entities from the frontent). The Thunar MIME applications/actions handling is pretty much undecided yet (both the backend and the frontend).

Thunar Designing the architecture

2005-03-24T00:00:00+00:00

As the overall feedback on the Thunar suggestion was very positive, I think we are mostly settled with the user interface now. Only minor changes will happen on the user interface, no more major changes on the UI concept.

So it's now the time to start to design the basic architecture for Thunar. Work on the MIME system was already started and a few bits and pieces can be found on the Wiki. The interesting part will be to design the ThunarView architecture, that is the way the main view will be designed and connected to the backend(s). My first idea here looked like this:

The idea is to separate the user interface part from the data storage (where storage is the wrong term here, as the data is already stored in the file system, a better term would be data manager). The volume manager is required to properly implement the Trash specification and to list the removable devices in the sidebar (both the shortcuts and the tree). On Linux we may use HAL to implement the volume manager, but HAL won't be a requirement, esp. since it's not portable at all, which conflicts with Xfce's major goals.

This design offers several advantages (yes, it looks obvious, but it's not; check other file managers and see for yourself): Adding different backends in the future or converting existing backends (e.g. move to D-VFS) will be very easy. Adding new views (like Column View or Tree View) will be very easy (version 1.0 should ship with List View and Icon View). The whole trash related functionality is implemented in one single place (except for the trash_file() function, but this function is more or less easy), which is a very good thing, since the trash spec is tricky and scattering the functionality over the source tree would surely become a maintaince problem over time.

More detailed information about this idea can be found on the Thunar Wiki.

Thunar Suggestion 20050320

2005-03-20T00:00:00+00:00

So, I decided that it's time to sum up the results of two/three weeks of Thunar UI discussion, and hacked it into a Wiki page:

http://thunar.xfce.org/wiki/ui:suggestion-20050320

I think we can all agree on this suggestion, as it provides ease of use and simplicity with the default look (layout 1), but without limiting the user too much (something that has been complained about by Gnome users quite often lately), since the user is free to use a different look and feel (layout 2) or even customize the layout to fit his own needs. This is exactly the kind of flexibility we need for Xfce, and that's why people love Xfce: Put the user in control, but only to a certain degree. And of course, keep it lightweight and fast.

Thunar location bar again

2005-03-20T00:00:00+00:00

I have tried to adjust the prototype to make both parties happy, the path bar guys and the location bar addicts:

The path bar user interface looks as usual:

The location bar user interface is very similar, except that it has location entry widget instead of the path buttons:

And a third possibility, as suggested by Jeff, would be to disable the bar completely. This will make ROX users happy as well.

A tarball of the prototype with the stuff mentioned above is available here.

And the laugh of the day goes to...

2005-03-20T00:00:00+00:00

... my favourite Linux based operating system, Debian. The mighty and outstanding Debian people finally came to the conclusion that it might be a good idea to release their software from time to time (sarge will become stable right after the Hurd 1.0 release). Oh, really. Why did noone think of this earlier?

But seriously... we suck at releasing our stuff... but hey, we do release it. And people like it - well except the few with the broken panel config. ;-)

On a related note: I did an Ubuntu intall recently on one of our new servers (Fujitsu Siemens Primergy 200) at work; the installation went very smooth. Ubuntu just works. No need for endless googling about stupid problems. No need to compile a custom kernel, as the Ubuntu default kernels support even high-end hardware out of the box. Many people say "Xfce is Gnome done right". I say "Ubuntu is Debian done right".

Xfce splash screen crash course

2005-03-19T00:00:00+00:00

Here's a very brief introduction to the way splash screens work in Xfce 4.2.0 and above:

The whole splash thingy is a bit complex atm. On the first level, there are splash engines (currently mice, simple and balou); these are loadable modules. mice isn't themable at all, everything's hardcoded. simple is themeable from the configure dialog, and balou is themable using a theme file.

balou theming is pretty easy, its just a themerc file and a logo image file. Check the Default balou theme in the xfce4-session source to get an idea of the file format/content (it includes a few comments). To distribute a theme, create a directory layout like this:

Name
Name/balou
Name/balou/themerc
Name/balou/logo.png

where Name is the name of your theme. Then tar up the stuff like this:

$ tar czvf Name.tar.gz Name

Now users can simply install the theme by dragging the .tar.gz file from a file manager and dropping it to the balou configure screen in the settings manager.

Thunar Firefox-like location bar (the 2nd skin)

2005-03-19T00:00:00+00:00

Just came up with a better idea for the location bar layout:

It's now very similar to what Firefox does. The major difference is, that it's not associated with the statusbar as in Firefox, instead it's associated with the main view (icon/list view), which makes more sense.

It's important to have a user-visible way to get rid of the location bar again, even if there's already Escape or focus-out.

Terminal 0.2.4 released

2005-03-19T00:00:00+00:00

So I finally released the next version of Terminal after nearly 3 months since 0.2.2. And since everybody likes cute new features - as long as they don't blow up things too much - this new version finally includes support for helper applications (yes, that means clicking on URLs/email addresses is possible now):

This was about the most often requested feature. Several other changes have been made to improve Terminal. See the Release Notes for a complete list of user visible changes.

With this new release we're close to a 1.0 release, I think there'll be 0.2.6 and 0.2.8/0.3.0 before we jump to 1.0 though, as we've still some unresolved issues.

4.2.1(.1) is doomed

2005-03-19T00:00:00+00:00

I'm the new wimp of the day, as I accidently uploaded the wrong installer binary for 4.2.1.1 (I uploaded 4.2.1 with the panel bug again). I updated the mirrors now (except for www.us.xfce.org, www.xfce.org redirects to this mirror so don't download from xfce.org now, which will be updated during the next 3-4 hours) with the correct 4.2.1.1 binary, and everybody who installed 4.2.1.1 from the installer should refetch the binary and reinstall. Sorry for the inconvenience caused by this doomed 4.2.1(.1) releases.

Update

Brian's comment on this was:

<kelnos> we need a new motto
<kelnos> Xfce: Our software rocks, but we can't release it for shit

Xfce 4.2.1.1 available

2005-03-18T00:00:00+00:00

Since 4.2.1 contained this critical panel bug, we did a quick 4.2.1.1 release yesterday, which fixes the panel issue. All users of Xfce 4.2.1 should upgrade to 4.2.1.1. Updated installers are available from Xfce installers website.

Thunar Firefox-like location bar

2005-03-18T00:00:00+00:00

So I added the firefox-like location bar to Thunar today (Brian Schott came up with that idea yesterday) and after playing around with it for some time, I'm pretty sure that this is the solution to the location bar problem we've been trying to find during the last weeks.

It's just great, you can navigate using the keyboard, but the location entry widget isn't visible until you need it. This is great for newbies and power users, as it combines the best of both worlds: Newbies will use the path bar and the shortcuts for mostly everything, while power users can easily enter paths if necessary.

Thunar Open Location Ideas

2005-03-17T00:00:00+00:00

Brian Schott came up with a new - actually borrowed from ROX - idea for an Open Location control in the GtkFileChooser-like UI:

Here we'd have a fast and easy way to jump to a different location wihout the need to popup a separate dialog.

My original attempt (and that's how it's currently implemented in the prototype) was to have a separate Open Location dialog:

See the thread on the mailinglist for the discussion concerning these ideas.

Releasing bugs...

2005-03-17T00:00:00+00:00

Funny, right after the 4.2.1 release is finally done - well, except for Olivier's ChangeLog/NEWS - somebody files a critical bugreport against xfce4-session 4.2.0: xfce4-session - the simple and balou engines to be exact - crashes on startup with new freetype2 2.1.10cvs (well, not surprising that mice doesn't crash, as it doesn't render any text). Looks like a 4.2.2 release is not far away...

New Panel Design

2005-03-17T00:00:00+00:00

Jasper decided to open the design process for the new panel for general discussion. He's using the Xfce Wiki for this purpose. The most important part is the Panel Plugin API. So, in case you are a panel plugin writer or plan to write a plugin in the future, I suggest you enter the discussion.

Jasper presented his ideas for the new Panel at FOSDEM 2005 (slides available).

Embedded Xfce

2005-03-17T00:00:00+00:00

os-cillation now offers an embedded linux platform with Xfce as graphical interface for control units, appliances and other embedded applications. The system boots from a flash file system, which can be customized to fit the customers needs. The system itself offers 4 RS232 ports, 4 USB ports, 1 IrDA port and up to 16 GPIO pins, which makes it well suited for system control in the industry.

Once again Xfce demonstrates its power as all-around desktop, which also supports small setups, like embedded systems, very well.

Debian packages for Xfce 4.2.1 and Xfmedia 0.7.0

2005-03-17T00:00:00+00:00

I just uploaded new Debian packages to the os-cillation repository, including the update to Xfce 4.2.1, the new Xfmedia 0.7.0 release and a few goodies. In addition the xfld-desktop package does no longer depend on xnetcardconfig, which enables Ubuntu users to easily install xfld-desktop now.

Critical bug in xfce4-panel 4.2.1

2005-03-17T00:00:00+00:00

The xfce4-panel in the latest Xfce 4.2.1 release contains a bug: It does not save its configuration on session logout. The Xfce Debian package already contains a fix for this bug, so you don't need to worry about it. If you have installed from the graphical installer or plan to install from the graphical installer, follow these steps to fix the bug:

Download the xfce4-4.2.1-installer.bin (if not already done)
Mark the file executable using chmod +x xfce4-4.2.1-installer.bin
Download the file xfce4-panel-4.2.1-store-config.patch
Download the file xfce4-session-4.2.1-mcs-manager-crash.patch
./xfce4-4.2.1-installer.bin --extract-only
cd /tmp/xfce4-4.2.1-installer/xfce4-panel
patch -Np1 < /path/to/xfce4-panel-4.2.1-store-config.patch
cd ../xfce4-session
patch -Np0 < /path/to/xfce4-session-4.2.1-mcs-manager-crash.patch
cd ..
./bootstrap.sh

This also fixes a possible crash in xfce4-session when testing a splash engine. Now follow the usual installation instructions from the installer documentation.

In case, you installed Xfce 4.2.1 from source, untar the xfce4-panel-4.2.1.tar.gz file again, download the patch xfce4-panel-4.2.1-store-config.patch, cd xfce4-panel-4.2.1, patch -Np1 < /path/to/xfce4-panel-4.2.1-store-config.patch and afterwards run configure, make and make install as usual.

Update:

Xfce 4.2.1.1 available.

Xfcalendar improvements

2005-03-16T00:00:00+00:00

Mickael and Juha are doing a great job at improving xfcalendar recently. I'm pretty sure that Xfce 4.4.0 will ship with a very nice and very useful calendar application. Xfcalendar can already schedule appointments (tho it's still very rough on the edges), it currently looks like this:

Once the technical part is done, the user interface should be revised, and xfcalendar should probably drop the dependency on the MCS manager. It would be so much easier (and better for the future when we drop MCS) to just store the 3 settings into a resource file (XfceRc is your friend). There'll only run one xfcalendar instance per session anyways, so no concurrent write access problems.

Thunar Location Bar vs. Path Bar

2005-03-16T00:00:00+00:00

We are currently discussing the Thunar User Interface:

On the one hand, we have the traditional location bar approach, which looks pretty similar to navigational Nautilus:

On the other hand, we have the new path bar approach, which looks pretty similar to the GtkFileChooser User Interface:

I tend to prefer the path bar approach...

Premature Xfce 4.2.1 announcement

2005-03-16T00:00:00+00:00

OSNews did it again today, but not only did they announce Xfce 4.2.1 before it was officially released, this time they did the same for KDE's 3.4 release. Neither xfce.org nor kde.org contained any mention of a new release at the time the announcements where published on OSNews. In today's open source world, the most difficult part of release engineering seems to be preventing news sites from announcing releases before they actually happen, in order to get a smooth release. This worked amazingly well with the Xfce 4.2.0 release, but not before I mailed several news sites that they should not post anything until they get an official notice.

Enigmail works

2004-12-04T00:00:00+00:00

I finally got EnigMail working with native Mozilla on NetBSD/i386 -current (latest Mozilla 1.5.1 from pkgsrc with enigmail 0.82.2). I uploaded the XPI files here. To install the XPI files, run Mozilla as root, open the directory that contains the three XPI files in the browser and click on the files to install them, in the following order: The IPC module, the enigmime package and finally the enigmail package. Finally start Mozilla and configure enigmail as mentioned on the EnigMail website.

What to put in /etc/mk.conf

2003-05-01T00:00:00+00:00

In order to get a sane build environment and to build sane packages out of your environment, you should consider overriding some default values in your /etc/mk.conf. For example, if you are running NetBSD/alpha, you shouldn't use any optimizations to cc(1), because gcc is still buggy on Alpha. And in general you should think twice before setting the optimization level above 2, because this might cause several programs to segfault frequently or not run at all. Here are some lines from my mk.conf, which might help you (they will honor all default values but -O*):

COMMONCFLAGS?=-O2 -pipe
COPTS:=${COMMONCFLAGS} ${COPTS:C/-O[0-9]*//g}
CFLAGS:=${COMMONCFLAGS} ${CFLAGS:C/-O[0-9]*//g}
CXXFLAGS:=${COMMONCFLAGS} ${CXXFLAGS:C/-O[0-9]*//g}

When trying to fix bugs in packages, it is helpful to append -Wall -Werror to COMMONCFLAGS, but beware: This might break a lot of configure scripts (so, you have the chance to fix them too ;-). Another needful thing to have in your mk.conf is support for sudo instead of the default su(1), so you may need not to type the root password everytime you install a package as a user. Here are the lines from my mk.conf:

.if exists(/usr/pkg/bin/sudo)
SU_CMD=/usr/pkg/bin/sudo /bin/sh -c
.endif

Another helpful thing to do, is to override the default MASTER_SITE with faster (local) mirrors. E.g. I have a local NetBSD mirror (thats the tatooine.kosmos.all line, so don't simply copy&paste to your mk.conf :-), from where pkgsrc should try to fetch the needed distfiles first and after that fails, it will try several other mirrors, and only if a distfile cannot be found there, it'll try to fetch it from the MASTER_SITEs specified for the package. Here are the lines from my mk.conf:

MASTER_SITE_OVERRIDE+= \
  ftp://tatooine.kosmos.all/pub/NetBSD/packages/distfiles/ \
  ftp://ftp.de.netbsd.org/pub/NetBSD/packages/distfiles/ \
  ftp://ftp2.de.netbsd.org/pub/NetBSD/packages/distfiles/ \
  ftp://ftp.at.netbsd.org/pub/NetBSD/packages/distfiles/ \
  ftp://ftp.netbsd.org/pub/NetBSD/packages/distfiles/

How to get NetBSD running on your Sega Dreamcast game console

2003-02-02T00:00:00+00:00

Josh Tolbert <hemi at puresimplicity dot net> recently put together a lot of stuff related to the NetBSD/dreamcast port and created an easy to install NetBSD Dreamcast system along with a short introduction on how to setup your Dreamcast and what need to be done to increase the usuability of the NetBSD/dreamcast port (for now, focus on wscons(4) support for the Dreamcast framebuffer and getting POSIX threads to work). Josh's How-To and all stuff needed to get NetBSD working on your Dreamcast can found here.

NetBSD 1.6 book

2003-01-30T00:00:00+00:00

As mentioned on www.netbsd.org the german publisher C&L has made available a book on NetBSD 1.6. The book covers NetBSD installation (i386, macppc and others), user administration, updating the system, kernel tuning, configuring the rc.d startup system, package management using pkg_install and the pkgsrc tree, configuring the X window system and using NetBSD in a networked environment (IPv4/6, DNS, NFS/NIS, FTP, Samba and the like).

Introduction to NetBSD loadable kernel modules

2002-11-27T00:00:00+00:00

Introduction

Loadable kernel modules (LKMs) are quite popular on most modern operating systems such as GNU/Linux, FreeBSD and of course Microsoft Windows, just to name a few. They offer you the possibility to extend the kernel's functionality at runtime without recompiling or even rebooting the system. For example nearly every Linux device driver is available - or can be made available - as a loadable kernel module, that can be loaded at runtime to get support for a particular device (or even a pseudo-device).

With NetBSD, LKMs are not that popular yet. At the time of this writing only a few drivers are available as loadable modules (mostly filesystem and compat drivers, and a few others such as the linuxrtc emulation). This might change in near future.

The loadable kernel module interface was originally designed to be similar in functionality to the loadable kernel modules facility provided by SunOS. The lkm(4) facility is controlled by performing ioctl(2) calls on the /dev/lkm device, but since all operations are handled by the modload(8), modunload(8) and modstat(8) programs, you should never have to interact with /dev/lkm directly. Note, that you need to run a kernel compiled with the LKM option in order to make use of LKMs.

Writing the module

I'd like to show you how to write a simple character device driver that does nothing but the simple job of calculating the Fibonacci numbers (I'll therefore name the module fibo.o and let all the function's names begin with fibo_). The driver will provide 8 minor devices /dev/fibo0 to /dev/fibo7. Each minor device offers the following functions:

static int fibo_open(dev_t, int, int, struct proc *);
static int fibo_close(dev_t, int, int, struct proc *);
static int fibo_read(dev_t dev, struct uio *, int);

You can open and close a device provided by this driver and you'll be able to read from it (we'll have a closer look at the parameters later, when we discuss the actual functions). Now we need to tell the kernel that we provide a character device with the 3 functions listed above. Therefore we need to fill in a struct cdevsw (cdevsw means character device switch and the struct cdevsw is defined in sys/conf.h).

static struct cdevsw fibo_dev = {
  fibo_open,
  fibo_close,
  fibo_read,
  (dev_type_write((*))) enodev,
  (dev_type_ioctl((*))) enodev,
  (dev_type_stop((*))) enodev,
  0,
  (dev_type_poll((*))) enodev,
  (dev_type_mmap((*))) enodev,
  0
};

enodev is a generic function that simply returns the errno(2) ENODEV (Operation not supported by device) which says that we does not support any operations besides open, close and read. So, for example, whenever you try to write to the device, the write(2) will fail with ENODEV.

Furtheron we need to tell the kernel how the module is named and where to find information about operations provided by the module. This is a quite simple task with the lkm interface: We use the preprocessor macro MOD_DEV, which is defined in sys/lkm.h to hand the information over. The MOD_DEV macro was changed in NetBSD-current, therefore we use the following construct to get things working with both NetBSD 1.6 and earlier and NetBSD 1.6H and later (thanks to Anil Gopinath for the hint).

#if (__NetBSD_Version__ >= 106080000)
MOD_DEV("fibo", "fibo", NULL, -1, &fibo_dev, -1);
#else
MOD_DEV("fibo", LM_DT_CHAR, -1, &fibo_dev);
#endif

This means that our module is named fibo, we'll provide a character device (minor devices are handled by the module itself, so they doesn't matter for now), we want to retrieve a dynamic major device number from the kernel (if you want to use a specific major device number you'll need to specify that instead of the -1, but beware of getting in conflict with other device drivers) and we provide the information about the supported operations in fibo_dev.

In order to ensure proper unloading of the module we need to keep a global reference counter of opened minor devices.

static int fibo_refcnt = 0;

And furtheron we need to keep a bunch of information about each minor device.

struct fibo_softc {
  int       sc_refcnt;
  u_int32_t sc_current;
  u_int32_t sc_previous;
};
 
#define MAXFIBODEVS 8
 
static struct fibo_softc fibo_scs[MAXFIBODEVS];

As mentioned above our driver will provide 8 minor devices. Each minor device stores information about how often it was opened (in our example each minor device can only be opened once to keep things simple), the current number and the previous number for calculating the Fibonacci numbers. If you don't know how to calculate the Fibonacci numbers, you should have a look on a book about algorithms, as explaining this is beyond the scope of this article.

Each kernel module needs to have an entry point which is passed to ld(1) by modload when the module is linked. The default module entry point is named xxxinit. If xxxinit cannot be found, an attempt to use modulename_lkmentry will be made, where modulename is the filename of the module being loaded without the .o. In general the entry function will consist entirely of a single DISPATCH line, with DISPATCH being a preprocessor macro defined in sys/lkm.h to handle loading, unloading and stating for us. So our fibo_lkmentry function will look like this:

int
fibo_lkmentry(struct lkm_table *lkmtp, int cmd, nt ver)
{
  DISPATCH(lkmtp, cmd, ver, fibo_handle, fibo_handle, fibo_handle);
}

Now we need a handler function for our module to do module specific tasks when loading, unloading or stating the module. The name of this handler function is passed to DISPATCH (see above) to tell the kernel which function it has to call when doing such things. A pointer to the module entry in the LKM table and an integer representing the desired command (LKM_E_LOAD, LKM_E_UNLOAD or LKM_E_STAT) are passed to the handler function. The handler is called after the module is linked and loaded into the kernel with the LKM_E_LOAD command. Then we need to check whether the module was already loaded into the kernel and initialize our data structures. When unloading the module, the handler is called with the LKM_E_UNLOAD command and we need to check if the module is not required any more (e.g. check if all devices are closed for char/block driver modules) before confirming the unload command.

static int
fibo_handle(struct lkm_table *lkmtp, int cmd)
{
  switch (cmd) {
  case LKM_E_LOAD:
    /* check if module was already loaded */
    if (lkmexists(lkmtp))
      return (EEXIST);
      
    /* initialize minor device structures */
    bzero(fibo_scs, sizeof(fibo_scs));
    printf("fibo: FIBONACCI driver loaded successfully\n");
    break;
    
  case LKM_E_UNLOAD:
    /* check if a minor device is opened */
    if (fibo_refcnt > 0)
      return (EBUSY);
    break;
    
  case LKM_E_STAT:
    break;
    
  default:
    return (EIO);
  }
  
  return (0);
}

The open function is quite simple as most of the hard stuff is already handled by the NetBSD kernel (e.g. the kernel will automatically allocate a vnode(9) for you). The parameters for the open function are the major and minor device numbers (use the major and minor macros), the flag and mode arguments as described in open(2) and a pointer to the struct proc of the process that did the open system call.

So the first thing to do is to check if the minor device number we got when the device was opened is not out of range, and if the minor device is not already opened. You should always keep in mind that the minor device handling is completely up to you and that this is a never ending source of mistakes! Then we need to initialize the minor device data (the Fibonacci starting numbers 1, 0 + 1 = 1, 1 + 1 = 2, 1 + 2 = 3, ...) and increase the minor device and the global module reference counter.

static int
fibo_open(dev_t dev, int flag, int mode, struct proc *p)
{
  struct fibo_softc *fibosc = (fibo_scs + minor(dev));
  
  if (minor(dev) >= MAXFIBODEVS)
    return (ENODEV);
    
  /* check if device already open */
  if (fibosc->sc_refcnt > 0)
    return (EBUSY);
    
  fibosc->sc_current = 1;
  fibosc->sc_previous = 0;
 
  /* increase device reference counter */
  fibosc->sc_refcnt++;
  
  /* increase module reference counter */
  fibo_refcnt++;
  
  return (0);
}

The close function has the same parameters with the same meanings as the open function described above. It is used to free the internal data structures of a minor device opened before. You do not need to worry whether the device was opened before or to do things like releasing the vnode associated with the device, all you need to do is to cleanup the module specific stuff. In our example this means decreasing the minor device and the global module reference counters and so that our close function is quite simple.

static int
fibo_close(dev_t dev, int flag, int mode, struct proc *p)
{
  struct fibo_softc *fibosc = (fibo_scs + minor(dev));
  
  /* decrease device reference counter */
  fibosc->sc_refcnt--;
  
  /* decrease module reference counter */
  fibo_refcnt--;
  
  return (0);
}

Last but not least the read function. This function has 3 parameters: the device major and minor numbers like in the open and close functions, a flag field indicating for example whether the read should be done in a non-blocking fashion or such things and a pointer to a struct uio defined in sys/uio.h. A struct uio typically describes data in motion, in case of a read(2) system call data moved from kernel-space to user-space. This may look a bit strange if you already did device driver progamming on GNU/Linux, but the uio concept used by the NetBSD kernel simplifies a lot of things and provides a generic and consistent interface for kernel-space to user-space and kernel-space to kernel-space data moving. See uiomove(9) for more information.

Back on stage, we should first have a look at the read function and discuss the details afterwards.

static int
fibo_read(dev_t dev, struct uio *uio, int flag)
{
  struct fibo_softc *fibosc = (fibo_scs + minor(dev));
  
  if (uio->uio_resid < sizeof(u_int32_t))
    return (EINVAL);
    
  while (uio->uio_resid >= sizeof(u_int32_t)) {
    int error;
    
    /* copy to user space */
    if ((error = uiomove(&(fibosc->sc_current),
                sizeof(fibosc->sc_current), uio))) {
      return (error);
    }
    
    /* prevent overflow */
    if (fibosc->sc_current > (MAXFIBONUM - 1)) {
      fibosc->sc_current = 1;
      fibosc->sc_previous = 0;
      continue;
    }
    
    /* calculate */ {
      u_int32_t tmp;
      
      tmp = fibosc->sc_current;
      fibosc->sc_current += fibosc->sc_previous;
      fibosc->sc_previous = tmp;
    }
  }
  
  return (0);
}

So the first thing we do, is to check whether the process requests less than sizeof(u_int32_t) bytes (actually 4 bytes). Our read function always reads a bunch of 4-byte blocks and to keep it simple and easy to understand we disallow reading less than 4 bytes at a time (uio->uio_resid holds the number of remaining bytes to move to user-space, automatically decreased by uiomove).

The function copies the current Fibonacci number into the user-space buffer, checks for a possible overflow (only the first 42 Fibonacci numbers fit into u_int32_t) and calculates the next Fibonacci number. If there is enough space left in the user-space buffer, the function loops and restarts the process of moving, checking and calculating until the buffer is filled up to the possible maximum or uiomove(9) returns an error. Note, that a read(2) system call on this device will never return 0, and so it will never reach an end-of-file (EOF), so the device will generate Fibonacci numbers forever.

If you're familar with GNU/Linux device driver programming you might have noticed that we do not return -ERRNO on failure, and in case of the read system call the number of bytes read, but instead we return 0 on success and the positive errno value on failure. Everything else is handled by the NetBSD kernel itself, so we do not need to care about.

Loading the module

Now that our device driver module is completed, we need a shell script that will be executed when the module is successfully loaded to create the required device nodes in /dev. This shell script (or program) is always passed three arguments: the module id (in decimal), the module type (in hexadecimal) and the character major device number (this differs for other types of LKMs such as system call modules). So our script is pretty simple:

if [ $# -ne 3 ]; then
  echo "$0 should only be called from modload(8) with 3 args"
  exit 1
fi

First check whether all three command line arguments are present and exit with error code if not.

for i in 0 1 2 3 4 5 6 7; do
  rm -f /dev/fibo$i
  mknod /dev/fibo$i c $3 $i
  chmod 666 /dev/fibo$i
done
exit 0

And finally (re)create the required special device nodes. Now we are ready to give our module a first test run. Compile the module and load the module with the following command (this needs to be run as superuser):

modload -e fibo_lkmentry -p fibo_post.sh fibo.o

If everything went well, the modstat(8) program should present you output similar to this:

Type    Id  Off Loadaddr Size Info     Rev Module Name
DEV      0   29 dca4f000 0004 dca4f260   1 fibo

Testing the module

In order to test your new kernel module, we need a small test program that does nothing more than reading a 32bit unsigned integer value from /dev/fibo0 and outputs the value to standard output. See the sample program below:

#define DEVICE "/dev/fibo0"
 
int
main(int argc, char **argv)
{
  u_int32_t val;
  int fd, ret;
  
  if ((fd = open(DEVICE, O_RDONLY)) < 0)
    err(1, "unable to open " DEVICE);
    
  while ((ret = read(fd, &val, sizeof(val))) == sizeof(val))
    printf("%u\n", val);
    
  if (ret < 0)
    err(2, "read(" DEVICE ")");
    
  close(fd);
  return 0;
}

When you run this sample test program, it will output Fibonacci numbers below 2971215074 until you interrupt or kill the program. To unload the kernel module, you need to run the following command (as superuser):

modunload -n fibo

The complete sources for the example above, including a Makefile, are available online at:

https://github.com/bmeurer/fibo_drv

A tar archive with the sources can be found here. I hope you like this small introduction to the NetBSD lkm system. If you have any questions or if you would like to give me some feedback, feel free to contact me.

Setting up KDE 3 on NetBSD

2002-10-28T00:00:00+00:00

Introduction

Like most other Unix(TM)-like operating systems, the K Desktop Environment (KDE) is also available for NetBSD. KDE is a powerful graphical desktop environment based upon Trolltech's QT library, and is similar to other desktop environments available for Unix(TM) workstations, such as the Common Desktop Environment (CDE) or GNOME. It tries to combine ease of use, contemporary functionality, and outstanding graphical design with the technological superiority of the Unix operating system. Like NetBSD itself, KDE is also an Internet project and is licensed under the GNU General Public License (GPL), and is therefore open source software.

Installation

It is quite easy to install the latest KDE 3 on a NetBSD system using either binary packages or building it from pkgsrc. As I wrote this, there were no official KDE 3 binary packages available on the ftp servers and I didn't have the space and bandwidth to put my packages online :-(. It would be nice, if someone could provide me with a few 100MB of web/ftp space to put my packages on, so that everyone reading this could use these packages.

If you are not lucky to fetch some binary packages for KDE 3, then you should fetch a recent pkgsrc from NetBSD-current (must be a post 20020830) and start building KDE from scratch. Therefore you should change to the directory x11/kde3 in your pkgsrc tree and start by typing make install. NOTE: Before starting to install KDE 3, you should remove any installed KDE package and the installed QT packages (if they're older than 3.0.5), and do a make clean on your pkgsrc tree, else the installation might fail. After starting the installation process, you'll need to wait up to 3 days, until the installation is complete, depending on the hardware of your machine. You might want to speed up the installation process by mounting the filesystem that contains the pkgsrc tree with the async option; e.g. type mount -u -o async /usr/pkgsrc, but beware, that mounting a filesystem asyncronous may have a bad effect on your data if the computer crashes. So, you have been warned, use this option at your own risk.

Postinstallation

Now, that KDE 3 is installed properly, all you need to do, is setup your X session to start KDE 3. Therefore edit (maybe create) the file .xsession in your home directory and put in the following lines:

#!/bin/sh
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
exec /usr/X11R6/bin/startkde

Then mark the file executable by typing chmod +x $HOME/.xsession, login as usual with xdm and feel happy about your new and fancy KDE desktop :-).

If you're using startx instead of xdm, you need to edit the file .xinitrc in your home directory instead.

Using antialiased fonts

You might also want to get KDE rendering those nice fonts you saw on all those screenshots all over the web. Therefore you'll need to have XFree86 version 4.x installed (this is the default for NetBSD 1.6 and above). Then you need to install some nice looking TrueType or Type1 fonts, therefore you can use the freely available webfonts provided by Microsoft, simply install the fonts/ms-ttf package and the fonts/ttmkfdir package. Then goto /usr/X11R6/lib/X11/fonts/TrueType and type:

$ ttmkfdir > fonts.scale
$ mkfontdir

After that add the following line to your /usr/X11R6/lib/X11/XF86Config-4 in the Files section

FontPath "/usr/X11R6/lib/X11/fonts/TrueType/"

and

dir "/usr/X11R6/lib/X11/fonts/TrueType"

to your /usr/X11R6/lib/X11/XftConfig. Logout from your X session and restart your X server by hitting CTRL-ALT-BACKSPACE at your xdm login prompt. Relogin to your KDE desktop and enable "Use Anti-Aliasing for fonts" in the KDE control center; logout again and relogin, and choose some nice antialiased fonts (the ones with the [Xft] in the name) for your desktop. Enjoy! ;-).

Feedback

I hope you liked my little KDE 3 HowTo and I would be pleased to get some good (or even bad ;-) feedback from you. If you have any problems or questions on this topic, I'll try to help you getting things to work.

How to use hardware monitors with NetBSD

2002-10-19T00:00:00+00:00

Today, there are various environmental sensor ICs available on modern mainboards, which are able of monitoring fan speed, cpu and system temperature, and voltage for example. NetBSD currently supports the National Semiconductor LM78, LM79 and compatible hardware monitors (the lm(4) device), the VIA VT82C686A hardware monitor (the viaenv(4) device) and ACPI aware hardware monitors (the acpi(4) subsystem) through its Environmental Systems API. These devices are not enabled by default, you need to recompile your kernel with the following additional lines in your kernel config file:

For the National Semiconductor LM78, LM79 and compatible monitors (you may need to adjust the I/O port settings):

 
lm0 at isa? port 0x290

For the VIA VT82C686A hardware monitor:

 
viapm* at pci? dev ? function ?
viaenv* at viapm?

For ACPI enabled monitors (thanks to Joel Carnat for the hint):

 
options MPACPI
acpi0 at mainbus0
acpiacad at acpi?
acpibat* at acpi?
acpibut* at acpi?
acpiec* at acpi?
acpilid* at acpi?
acpitz* at acpi?

After booting your new kernel, you can access your hardware sensors, using the envstat(8) command. For example, to display all supported sensors, type envstat -l, and to actually read the environmental sensors, simply type envstat. For more information about using the envstat(8) tool, refer to the manpage.

Why NetBSD?

2002-10-02T00:00:00+00:00

During the last years, I used to install a lot of different operating systems, looking for the system that fits my needs best. For example, I tried Microsoft Windows NT (3.51, 4.0 and 5.0 and had a quick look at 5.1), several Linux distributions (e.g. SuSE Linux, RedHat Linux, Debian GNU/Linux and Mandrake Linux), FreeBSD and OpenBSD. We also tried to write our own operating system (we named it "Socratix"), but soon we noticed, that it was an impossible task for us to write a whole operating system (from scratch).

All those systems I tried have their particular advantages, but of course they all have their native disadvantages. And not allowing me to fix these disadvantages (e.g. the Debian Policy is such a disadvantage, I think), makes me become very frustrated of open source software (and the philosophy behind it). So after all, I decided to give NetBSD another try (I had installed NetBSD several times before, for testing reasons, but never get really close to it). After reading Federico Lupi's excellent NetBSD Guide I fetched the NetBSD distribution, created an iso image out of it and burned it onto a cd. Starting off the very straight-forward installation procedure, I was very pleased with NetBSD. It allows to me to do exactly what I want to do, nothing more, and nothing less. The base system is very clean and includes only the main parts of the system, so soon I decided to fetch a recent pkgsrc.tar.gz and installed some packages (I cannot live without perl ;-). The only thing I'm still missing about pkgsrc is a tool like portupgrade; it is currently been worked on, and e.g. pkg_hack does nearly everything portupgrade does, but you know It doesn't work unless it's right :-).

After all, I think the main reason for using NetBSD is its clean design and clean development model. The problem with the mainstream operating systems such as GNU/Linux is that people always want to have the newest features, and so the main goal is to get this features implemented as soon as possible, without the need to get a clean implementation. With NetBSD, you may get this features up to one or two years later, after somebody worked out a clean and stable implementation and a lot of testing was done on it. And when you get it, you can be sure, it works! So, now you know, why I prefer NetBSD, and what about you? Are you still loosing time getting your Linux distribution to work? Tired of fixing Debian package dependencies everytime you type apt-get dist-upgrade? So, maybe you should give NetBSD a try, but beware of making the wrong decision: NetBSD is no mainstream operating system, so if you always want to get the latest (unstable) features, you're better off not choosing NetBSD to run your computer!

And last but not least: NetBSD rules :-).

What BSD gives to the world

2002-09-28T00:00:00+00:00

Today I read an interesting article on BSD and what it gave (and still gives) to the world, you can find it here, this is probably the best article about BSD, Unix and Linux, I ever read. Also the changes to du(1) have been commited to NetBSD-current, so we'll get the long awaited feature with 1.7 ;-).

NetBSD 1.6

2002-09-09T00:00:00+00:00

NetBSD 1.6 is finally at RELEASE.

BSD multimedia

2002-09-06T00:00:00+00:00

Today I read a very interesting article on how to turn your BSD box into a powerful multimedia workstation. Although it was written with FreeBSD in mind, it might also be useful to read for a NetBSD user interested in enjoying multimedia on its NetBSD machine.

The September Issue of Daemon News on-line E-zine includes a small Q&A guide on how to properly partition a disk for NetBSD written by Grey Wolf.

NetBSD 1.6RC3

2002-09-04T00:00:00+00:00

NetBSD 1.6 Release Candidate 3 available. Interesting article at BSDnewsletter.com: Taking MicroBSD for a test run (MicroBSD aims to be a hardened OpenBSD derivate). And finally agc explaining changes to pkgsrc in August 2002.

Setting up sendmail with Milter support on NetBSD

2002-08-31T00:00:00+00:00

Note that if you are using NetBSD 1.6T or better, the system sendmail already supports the Milter library. And pkgsrc supports sendmail installation (for 8.12.x, 8.12.9 at this moment) linked with Milter library. See mail/libmilter and mail/sendmail (use make USE_MILTER=yes command to build the last one).
(Thanks to Mishka for pointing this out)

This is a posting from Mishka to comp.unix.bsd.netbsd.misc on getting sendmail to work with libmilter using the devel/pth package:

 
From: Mishka <mishka@batraq.anything3d.com>
Newsgroups: comp.unix.bsd.netbsd.misc
Subject: NetBSD + Milter = friendship :)
Date: Fri, 30 Aug 2002 18:12:49 +0300
Organization: PACOnet ISP
Message-ID: <3D6F8B71.4050807@batraq.anything3d.com>
X-Complaints-To: abuse@paco.net
NNTP-Posting-Date: Fri, 30 Aug 2002 15:13:42 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.0) Gecko/20020816
X-Accept-Language: en-us, ru
X-NNTP-Posting-Host: batraq.anything3d.com
 
Hello!
 
I found that built-in sendmail (8.11.6 for NetBSD 1.6E) compiled without
Milter support. Next, in pkgsrc collection sendmail have the same version,
and have not Milter support also. It seems to be due to absence of POSIX
threads in system.
 
Anobody knows rightest way to enable Milter functionality in Sendmail?
It would be great if we can solve this problem without install other
version of sendmail, but use built-in one.
 
Having installed pth-1.4.1 before, I tried the following:
 
1) Add the following files and dir to /usr/src/gnu/usr.sbin/sendmail:
  libmilter/
  libmilter/Makefile
  libmilter/Makefile.milter
 
    With following contents:
  ---- libmilter/Makefile.milter BEGIN ----
  # $NetBSD$
 
  .if _FFR_MILTER
  PTH_CFLAGS!=    pth-config --cflags
  PTH_LDFLAGS!=   pth-config --ldflags
  PTH_LIBS!=      pth-config --libs
 
  CPPFLAGS+=      -D_FFR_MILTER
  CPPFLAGS+=      ${PTH_CFLAGS}
  LDADD+=         ${PTH_LDFLAGS} ${PTH_LIBS}
  .endif
  ---- libmilter/Makefile.milter END ----
 
  ---- libmilter/Makefile BEGIN (derived from libsmutil/Makefile) ----
  #       $NetBSD: Makefile,v 1.4 2001/12/12 12:24:21 lukem Exp $
 
  NOSHARE=        # defined
  NOPIC=          # defined
  NOPROFILE=      # defined
 
  .include <bsd.own.mk>
  .include "Makefile.milter"
 
  DIST=           ${.CURDIR}/../../../dist
  .PATH: ${DIST}/sendmail/libmilter
 
  LIB=            milter
 
  CPPFLAGS+=      -DNOT_SENDMAIL
 
  SRCS=           comm.c engine.c handler.c listener.c
  SRCS+=          main.c signal.c sm_gethost.c smfi.c
 
  libinstall::
 
  .include <bsd.lib.mk>
  ---- libmilter/Makefile BEGIN ----
 
    And have added the following line to Makefile:
 
  .include "libmilter/Makefile.milter"
 
2) Next, having installed libmilter/Makefile.milter I do:
 
  # pwd
  /usr/src/gnu/usr.sbin/sendmail
  # make clean
  ...
  # make -f Makefile -D_FFR_MILTER
  ...
  . at this stage i seen that libsmutil and other is compiled
  . with _FFR_MILTER flags and linked with -lpth
  ...
  # make install
  ...
  # ldd /usr/libexec/sendmail/sendmail
  /usr/libexec/sendmail/sendmail:
           -lwrap.0 => /usr/lib/libwrap.so.0
           -lutil.6 => /usr/lib/libutil.so.6
           -lssl.2 => /usr/lib/libssl.so.2
           -lcrypto.1 => /usr/lib/libcrypto.so.1
           -lpth.14 => /usr/pkg/lib/libpth.so.14     <--- look here
           -lc.12 => /usr/lib/libc.so.12
  # cd libmilter && make -D_FFR_MILTER
  ...
  # cp libmilter.a /usr/lib
  # ns -s /usr/lib/libmilter.asmfi_getpriv in smfi.o
  smfi_addrcpt in smfi.o
  smfi_addheader in smfi.o
  smfi_getsymval in smfi.o
  ... and so on ...
 
3) After two ones below, I have sucessfully compiled sample mail filter
    which uses libmilter library.
 
4) After all, I have added following lines to /etc/mail/sendmail.rc:
 
  O InputMailFilters=drweb-filter
  Xdrweb-filter,  S=inet:3001@localhost,  T=S:10m;R:10m;E:1h
 
    And errors for this moment wasn't detected :)
 
But i have ask you once more: is there exists more easiest way to do this,
and anybody know what we will do if some package uses Milter functionality?
(maybe syspkg ;)
 
Thanks in advance.
 
--
Mishka.

IRIX Binary Compatibility

2002-08-02T00:00:00+00:00

Emmanuel Dreyfus published the second part of IRIX Binary Compatibility with NetBSD.