On 2/20/08, Don Stewart wrote:

Hmm. Very interesting. The app must be polling for something, or spinning. Maybe it doesn't like being unmapped.

I thought about that, seeing it uses fam/gamin for file file modification monitoring. But in it that case shouldn't it just use as much CPU after the directory change?

On Wed, Feb 20, 2008 at 07:27:22PM +0900, semdornus@gmail.com wrote:

* On Wednesday, February 20 2008, Spencer Janssen wrote:

...

Can you elaborate on which other WMs you've tried?

Sure,

I've now tried xmonad, dwm and awesome in combination with the file managers Thunar, pcmanfm and emelfm2.

dwm and awesome don't have this behaviour at all with any of the file managers. I know awesome was derived from dwm, but recently it's strongly diverging so I tried that one as well anyway.

One major difference between xmonad and dwm is that xmonad unmaps non-visible windows (standard WM behavior), while dwm merely moves them offscreen. I'm not sure whether awesome unmaps windows too.

xmonad with Thunar does as described, pcmanfm has the same behaviour although the intial idling is lower; it goes between 0 and 1%. After I change the directory in pcman it idles at 0%, just like Thunar. Although emelfm2 also uses fam/gamin it doesn't display this behaviour at all.

I haven't tried other WMs/FMs yet since I don't want to pull in anything too big and traditional WM's are probably not comparable in this aspect anyway. If someone has Thunar and can check it that would be great. I'm interested to see if it's really my system or xmonad who does this.

Yep, I think it will help if someone else could reproduce this. Also, testing with other, more traditional, window managers might help. Cheers, Spencer Janssen