I have Gentoo installed with Xfce4 and Fluxbox. Under Fluxbox, if I open thunar and try to drag the thunar window, it lags significantly. If I drag other windows around (i.e. eterm), it is lightning fast. I've only seen this slowness (so far) with thunar. Thunar is not automatically added to my menu using several menu configuration programs...so I added it manually just using {thunar} for the command. I don't have this problem with thunar on Xfce4 - it is just as fast as any other window when running Xfce4 (which is a little slower then Fluxbox since this is pretty old hardware). Any help or suggestions is greatly appreciated!

-Scott

Last edited by Spectre85 on Sat Nov 07, 2009 3:43 am; edited 1 time in total

Perhaps I should also mention that I had added "xfce4-mcs-manager &" to the fluxbox startup file. This is supposed to give me icons in Thunar, but it makes NO change in thunar for me (icons work find in Xfce4). Furthermore, I've tried disabling this flag, but Fluxbox still lags with Thunar.

EDIT: Also, if I shrink the window (double-click the the title bar) so it becomes just the title bar, then it moves around all zippy as expected.
EDIT2: I changed (gtk-fallback-icon-theme = "gnome") to (gtk-fallback-icon-theme = "Tango", or "Rodent" to look like the new Xfce) in the /etc/gtk-2.0/gtkrc file. This solved the icon problem and thunar now displays correctly. But when I drag it, it is still very slow/laggy.

Not really sure about the lag problem, but thought i'd try to explain a couple of the other points raised above...

Xfce4-mcs-manager is Xfce's equivalent to Gnome-settings-manager - it sets gtk-themes, fonts, and, as you've discovered, icon-themes used by gtk-based applications (plus keyboard/mouse settings and some other stuff). The gtk-settings are stored in ~/.config/xfce4/mcs_settings/gtk.xml. If you have different settings also defined in the more 'xdg-compliant' ~/.gtkrc-2.0, then a session started without a settings-manager will use the latter configuration-file; If you then open Xfce4-settings-manager or Xfce4-user-interface-settings, the mcs-manager will start in the background and your gtk-settings will switch to those defined in the former file - did that make sense..?

I don't use any menu-generation software here, but i'd hazard a guess that such software reads the various '.desktop' files in /usr/share/applications, and some of those files contain variables which tell menuing programs to ONLY display them under specific desktop-environments - for example, 'xfce-settings-manager.desktop' contains:-

Code:

Categories=X-XFCE;Settings;DesktopSettings;
OnlyShowIn=XFCE;

...Having said that, i've got 2 systems using older versions of thunar, and neither one inhibits it's use in this manner, presumably because it's developers know that it's popularly used outside of Xfce - if you're using a newer version than 0.9.3, it might not hurt to check it's '.desktop' file...

I use thunar in fluxbox on both of my systems at the moment (without mcs-manager), and i'm not seeing the lag problem, but if rolling the window up with a double-click on it's title-bar stops it, then it would seem to be related to the window contents only, and i'd expect to see it from other gtk-based apps like Firefox as well - do they drag okay? If not, i think i'd be looking at gtk+ or cairo as a culprit, as they handle the rendering inside those app-windows...

EDIT: Another thought - are you using a 'desktop-manager' of any sort? The type of thing that allows you to place icons on the desktop and set the wallpaper? They can sometimes cause conflicts...

It might also highlight something if you post the output of "emerge fluxbox thunar gtk+ cairo -pv" so that the versions and also the USE-flags are listed. _________________"Anyone who goes to see a psychiatrist should have their head examined!"

Thanks for the info about managers - I'll look into that some more when I have some time.

taipan67 wrote:

I use thunar in fluxbox on both of my systems at the moment (without mcs-manager), and i'm not seeing the lag problem, but if rolling the window up with a double-click on it's title-bar stops it, then it would seem to be related to the window contents only, and i'd expect to see it from other gtk-based apps like Firefox as well - do they drag okay? If not, i think i'd be looking at gtk+ or cairo as a culprit, as they handle the rendering inside those app-windows...

EDIT: Another thought - are you using a 'desktop-manager' of any sort? The type of thing that allows you to place icons on the desktop and set the wallpaper? They can sometimes cause conflicts...

It might also highlight something if you post the output of "emerge fluxbox thunar gtk+ cairo -pv" so that the versions and also the USE-flags are listed.

As for this...I just tried firefox - it lags the same way thunar does. So perhaps it is a gtk+ problem as you suggested. I have no desktop-manager installed (well...on Xfce there is I guess, but I don't for Fluxbox). Perhaps I need to change some certain use flag for gtk+...

I also noticed...if I drag an eterm around (which works fine as I've said)...when the MOUSE is over the TITLE bar of the GTK app (thunar, or firefox now too), then it acts the same way and goes really slow. If the MOUSE is just over the desktop though, it works just fine and fast. If it is over the main window of thunar/firefox, it goes slightly slower (you see a little blur on the sides of the eterm window). Very weird!

I just realized - that the problem just depends on the size of the window! I didn't notice it before since the eterm window is so much smaller then the thunar or firefox...but if I make any of them small, then they are all quick and have no problems. If I make any of them "big" (even eterm), then it lags. Perhaps my computer just can't keep up (although they are find in Xfce...even large windows of thunar and firefox...).

I'd be quite depressed to learn that Xfce is more resource-efficient than fluxbox. I wonder if it might be because in fluxbox you're using different renderers to paint different parts of the screen - in Xfce, everything is gtk+, hence rendered by cairo. If that hypothesis were true, you'd get the lag if you opened a large Eterm in Xfce and tried dragging it around (i'm guessing you use 'Terminal' in Xfce normally)...

If it doesn't lag, another speculative idea is that the app used to set the wallpaper, or root-window contents, in fluxbox might not be playing nice with the higher-level windows. If you're using Eterm, i would guess you use 'esetroot' for the job, either directly or indirectly through 'fbsetbg' ("fbsetbg -i" will tell you what it's using). Maybe another app would play nicer (i use 'feh', personally)..._________________"Anyone who goes to see a psychiatrist should have their head examined!"

In my experience, moving windows in this way with Fluxbox has always displayed a lag. It doesn't seem to be a big problem with other window managers. (Openbox, for example, doesn't have any issues with this.)

For Fluxbox, I always turn it off:

fluxbox menu -> Configure -> Opaque Window Moving

This shows a window outline for moving/resizing and it is, of course, very fast.

I've gotten so used to this look that I often use the outline/wireframe for moving/resizing when I'm running other window managers (even when they don't have a problem with moving/resizing).

I'd be quite depressed to learn that Xfce is more resource-efficient than fluxbox. I wonder if it might be because in fluxbox you're using different renderers to paint different parts of the screen - in Xfce, everything is gtk+, hence rendered by cairo. If that hypothesis were true, you'd get the lag if you opened a large Eterm in Xfce and tried dragging it around (i'm guessing you use 'Terminal' in Xfce normally)...

If it doesn't lag, another speculative idea is that the app used to set the wallpaper, or root-window contents, in fluxbox might not be playing nice with the higher-level windows. If you're using Eterm, i would guess you use 'esetroot' for the job, either directly or indirectly through 'fbsetbg' ("fbsetbg -i" will tell you what it's using). Maybe another app would play nicer (i use 'feh', personally)...

I still didn't get any worse lag under Xfce with eterm...I am using esetroot for the background...

RedSquirrel wrote:

In my experience, moving windows in this way with Fluxbox has always displayed a lag. It doesn't seem to be a big problem with other window managers. (Openbox, for example, doesn't have any issues with this.)

For Fluxbox, I always turn it off:

fluxbox menu -> Configure -> Opaque Window Moving

This shows a window outline for moving/resizing and it is, of course, very fast.

I've gotten so used to this look that I often use the outline/wireframe for moving/resizing when I'm running other window managers (even when they don't have a problem with moving/resizing).

This does make it MUCH quicker
I'll stick with this solution for now...still seems weird to me though that it works find under Xfce