The Answer Gang

By Jim Dennis, Jason Creighton, Chris G, Karl-Heinz, and... (meet the Gang) ... the Editors of Linux Gazette... and You!

---

please share your experience

From J.Bakshi

Answered By: Thomas Adam, Mike Orr, Jimmy O'Regan

Hi,

some of you already have done some experiments with different window managers . I request you to share your experience. I was a KDE user.

[Thomas] You're asking for a fight, yes? Joydeep, I/we have already pointed you to past articles in the past, about different window managers. Heck, I even published it in TAG for you. Here it is:

http://linuxgazette.net/114/tag/4.html

(hint: look at the footnotes, and the URLs therein)

Thanks for the link. I am also grateful to both Thomas and Mike Orr to let me/us know about their valuable experience about different WMs as well as their positive as well as negative ( I should use less feature) sides. specially Mike's reply makes me sentimental for going back to KDE -:))) . but at the same time I have a question in my mind ( may be a common question ) that we generally, I repeat generally don't go for a H/W up-gradation frequently. I used my first self-assembled PC for roughly 10 years. KDE becomes gradually more hungry as a result fatty too -:) . so it may happen that KDE makes your 2/3 years old H/W ( cpu, RAM) obsolete . and then you may fell switching over to other small and fast WM to continue with your existing H/W. only KDE themselves allow you to continue with KDE by providing fast and a little fatty code.

[Thomas] Well, yes. My own opinion is that you shouldn't have to upgrade your PC from a few years ago, to satisfy the working of KDE (or some other application.) If it is programmed well, then it ought to handle lower-end system just fine. I suspect it's a trade-off though between users wanting more features, and the fact that the developers of KDE themselves have a lot of new shiny hardware, such that they're not aware of the slowness issues on older hardware.

definitely they have latest H/W , so they don't bother about the older -:(. but the term latest depends on time factor. those who have latest H/W have no problem to run KDE. and soon their H/W become older with respect of KDE . so if KDE doesn't control its intention to become more hungry and fatty , it gets new users who own latest H/W at the same time loose its users who had latest H/W once with respect to KDE and are not able to do frequent up-gradation for KDE.

[Jimmy] "The trend in desktops, across all operating systems has been to continuously add features and graphics with each new release. Unfortunately, cool icons, animation and complicated multi-paned desktops have usually required increasingly capable machinery. For various reasons, Linux desktops seemed to have suffered less from this performance crunching bloat than other packages, such as Windows XP.

KDE 3.1 has actually reversed the trend. To prove my point, I loaded it on an antique 133 Mhz. Pentium desktop machine. The box had 128 MB of RAM, 256K of L2 cache, a 2.5 GB disk and Debian. Even though KDE took about two and 1/2 minutes to load, most of the programs, menus, icons and animations seemed to appear almost instantly and ran without a hitch."

http://www.linuxplanet.com/linuxplanet/reviews/4676/1

KDE developers do know about the slowness of KDE. Heck, back in 2001 Waldo Bastian wrote this paper (http://www.suse.de/~bastian/Export/linking.txt) about part of the reason behind it (ld.so isn't great at resolving C++ symbols) and wrote a module for KDE to work around it (http://webcvs.kde.org/kdelibs/kinit). Michael Meeks is currently doing similar scary things with OpenOffice: "Spent some time examining C++ symbol table creation in some detail; slightly amazed to see the amazing C++ vtable construction inefficiency in terms of bulk of symbols; GObject for all it's failings is extremely symbol efficient in that way." (http://www.gnome.org/~michael/activity-to-2004-06.html)

My local LUG in India has reported me that KDE 3.3 is more faster than its previous version. so hope for the best -:) any feed back is welcome

recently I have switched over to icewm. icewm runs comparatively faster than kde -:)

[Thomas] Of course it runs faster -- it's a WM and not a DE. That, and DEs tend (not always, but in the case of KDE it does) load up core libs that are needed to run a small part of KDE (or sometimes a large one) that you might never use. Then there's konqueror -- the libs for that are much the same. So you can see how the memory factor escalates as time increases. You want to know how I got on the "straight and narrow", eh? Well, read on:

Slackware 2.0: Twm

This was the first ever distro I used. I has absolutely no idea what I was doing, but I do remember being able to get XFree 3.x up and running, having spent a few months prior to that using the console, as I really didn't know any better.

When X started, up popped twm. Coming from a Windows background at the time, I thought that maybe I had broken my computer. Whilst something had obviously loaded, it was not what I was expecting. The menus were not very well defined, and for me to see them, I had to click and hold the mouse button. Hardly user-friendly...

[Jimmy] IIRC, I've only used TWM three times: first, Summer '98, when trying out VNC for the first time (with the Java applet), then again researching an article about CoLinux, using Cygwin, then a few weeks later with that setup, trying out Metasploit: injecting a VNC server using an RPC vulnerability, and viewing the results from the VNC viewer on CoLinux, viewed through Cygwin's X server (I was able to see it worked by the window-in-window view :)

[Thomas] ... or so I thought. But at the time, I just assumed twm was all there was. I got to know it, and tweak things about it. Surprisingly enough, twm is more customisable than people tend to realise. Ok, so I know the default look-and-feel of it is enough to make anyone vomit (the green really does remind me of the sea), but if one goes digging about ~/.twmrc, it becomes obvious of the things one can change about twm. I started off by changing the colour, to a deep red. Since the foreground colours were white, the contrast this gave was pleasing to me.

Twm also has an icon manager. I didn't know this was the name of it, and why should I? Whenever I iconified a window, it just appeared on the root window as a text label almost. But even that's customisable... The end result, was that although very primitive, it functioned, and I was happy with it.

I ended up staying with twm for about a year. I didn't know any different, and it was only after leaving Slackware, for this then new distribution RedHat, that things changed slightly... RedHat 5.0: KDE

[Jimmy] That was my first distribution! February '98, in college.

[Thomas] Anyone reading this that knows me, will laugh at the thought of me ever trying KDE, let alone using it. But it's true, one might say, almost unavoidable that I would use it at some point. Of course, I'm referring to KDE 1.x the version of KDE that actually worked. My main PC (up until very recently) was a P166. KDE 1.x actually ran on it at a not unreasonable speed, all things considered. KDE was still in its infancy compared to the over-weighted and monsterous beast it has become today).

But (and you can quote me on this) I liked KDE 1.x. I liked its style, and speed, even on a P166 and that matters when that machine was old, even when I was using it. Compared to the twm jail-house I had been in previously, this thing was immense.

Sure, I had a few issues with it. I remember distinctly that the icons on the desktop were tempermental. One moment they'd work, and the next moment, they wouldn't, or they'd disappear completely, etc. But I didn't let this bother me too much. It was useable. It worked very much like windows, which meant I didn't have to think about what I was doing -- KDE made all the choices for me.

I then switched distros a lot thereafter. I tried GNOME, and various other WMs, before settling on FVWM -- actually, this was on RH4 using their 'AnotherLevel' package. (The Lesstif theme)

[Jimmy] And that was my first WM (though with the FVWM95 default theme). Then Afterstep, Enlightenment+Gnome/KDE/Afterstep, Sawfish+Gnome/KDE/Enlightenment/WindowMaker, KDE/Gnome, now Gnome with whatever it uses now -- Metacity, I think.

[Sluggo] You used KDE before FVWM? That's a trip.

[Thomas] Oh no. I used TWM before I used anything else -- by "settled", I meant that I went back to FVWM having tried KDE. I guess the ordering was too vague in my description.

[Sluggo] Although I guess now that KDE is the default on many systems, it's pretty common.

[Thomas] It is more common now than it used to be. For years RH (through releases 4-6) pushed FVWM into the forefront. Indeed, the classic "desktop" competition that RH held in 1996 spawned the (in my eyes) infamous AnotherLevel theme. How I loved it. It was only very recently (say RH 8 onwards) that used KDE as the de facto upon installation. Although now that GNOME is the GNU desktop, that has seen its way to the top on some distros (Ubuntu is noticeable for this.)

[Sluggo] The first encounter I had with a GUI (besides Macintosh) was when the university computer lab replaced its h19 terminals with X-terminals. I thought it was a ridiculous waste of money at the time. The terminals came with a built-in window manager (Motif) and a menu to telnet into the frequently-used hosts.

[Thomas] Hehehe, what a cool thing to do. Bet it was slow though?

[Sluggo] Slow, no. What do you mean? All the hosts were on the campus network, which was no slouch.

[Thomas] Ah, I see. I just had problems trying to picture the scale of it in my mind -- whether the more users were on it at anyone time might have meant things were fairly slow (at University here, you can always tell when there's too many people logged on. :))

[Sluggo] This was the University of Washington, so pine was encouraged. But you could do xdm login to a BSD/ULTRIX host and get twm. That's what the cool people did.

[Thomas] Nice bit of history you've detailed there, Mike. I'd really love to see an article of how Unix was used in the past. Now, with PCs so cheap and popular, it's all the same method. You don't often hear of people saying they're using a dumb-terminal (unless they have an XDMCP server running.)

[Sluggo] The tradeoff was it took more CPU time on the host, so after eight hours you got nice'd and things slowed way down. That was late 1990. Most of what is now blogs and chatting and eBay was done on Usenet. I'd go down Friday evening to read news and get home Saturday afternon. We didn't really use the GUI at all except to set the background image and run a clock.

A few people played MUDs.

[Thomas] If you ever get the time, I would encourage you to write an article about it -- things like that fascinate me.

[Thomas] You don't have to look very far for the WM I use. Just look at the recent articles I have written, as well as recent TAG entries from a few months past. Indeed, you can see my config file on the fvwmwiki:

http://www.fvwmwiki.org

... as well as other examples on the fvwm-forums:

http://fvwm.lair.be

my H/W config is AMD semapron 1.5GHZ with 128MB DDR , 256KB L1, UDMA HDD . I have also tested fluxbox which is based on blackbox and slower than icewm.

[Thomas] The speed issue is largely dependant on a number of things, Joydeep. Typically, it could be that you're running extraneous applications along with the window manager you're loading, or it might be that the WM itself is loading them, providing you with the default theme it ships with (Englightenment used to do this -- no wonder I hated it.)

Indeed, I often get asked this question about FVWM -- and why that's so slow. Typically in FVWM's case, it can usually be attributed to the over use of colorsets. Colorsets (in FVWM parlance) are a means of specifying (in a lot of detail) the colours that can be assigned to various parts of a window (and all aspects thereof) as well as background colours. Colorsets can be told to use gradient colours, and the like, that, on lower-end systems take up a lot of memory.

Also, colorsets when used with transparency can cause a slow-down, due to the way the Xserver handles it (remember that colour management is the responsibility of the Xserver.) You can tell colorsets to buffer the transparent images as well -- this can be slow. Where colorsets use pixmaps (and other graphics colours as opposed to single block colour) then more memory is used. Indeed, when specifying colorsets in FVWM the numbering is important. If one were to use:

Colorset 100 fg white, bg blue

Then in memory, there would be allocated space for 101 colorsets, irrespective of whether they've been defined or not -- so keeping the numbers low, in their definition is often important. (I'll be discussing colorsets in FVWM properly in an article.)

But I digress.

There are of course, some general things one can try to reduce slowness. It's not so much of a problem on 2.6 kernels (as the scheduler is much better), but the Xserver used to be reniced when it was running so that it was more responsive -- but such things waere only ever negligable at best -- and renicing a process is NOT a general ideal to making things run faster -- but for really low-end systems, it might.

Going back to the subject of colour, running one's Xserver with a low colour-depth is advisable, something like:

startx -- -bpp 16

Which can reduce memory consumption. Note that colour-handling in FVWM (and colour limiting, where it is applicable) is now done automatically in FVWM where those applications try and steal the entire colour-pallette (netcape 4 used to be notorious for this.)

[Sluggo] I suppose you mean where the window has a different palette than the window manager, so everything around the window turns psychedelic colors when you move the mouse into the window.

[Thomas] That's the one, yep. I'm glad you're aware of the difference between a colour palette (of a window) and that of the overall Xserver. :)

[Sluggo] That was cool too. We used to do it on purpose just to watch the colors change. (Stop snickering, Ben.) It wasn't just Netscape. I think xloadimage (an image viewer that comes with X) did it too. It's not "stealing" the palette.

[Thomas] Indeed not. Where a palette is "stolen" what tends to happen is that the application defaults to black and white.

[Sluggo] It's just a fact of life that if the image has a different palette than the environment, one of them will have the wrong colors. The program rightly assumes that if the mouse is in its window, you want to see that image properly. Of course, now that everybody's video card has enough memory for 16 million colors, palettes don't matter anymore.

[Thomas] I'd agree, except for the fact that palettes do matter, as they're ultimately affected by the overall colour-depth the Xserver runs in. I don't run mine in so-called "true-colour". Mine's in 16 bit (sometimes eight.) But then I don't have a great graphics card... :)

[Sluggo] I don't remember if I first used FVWM before or after Linux (1993),

[Thomas] It wouldn't have been before -- FVWM 1.24 (?) was released in 1993.

[Sluggo] but it was my second window manager and I used it for years. Used WindowMaker for a while, tried a bunch of others. At work (1998) I used KDE so that any unfamiliar thing I might need was under the menus.

[Thomas] I think a lot of people that used Linux early on, followed this path. KDE despites all its faults now, really was something of a revolution back then. In fact, as I said in my commentary before, I actually liked KDE 1.X -- it really did look promising. And then they added cruft to it...

[Sluggo] That seemed better than wasting time finding something equivalent and installing it. Then I switched to KDE at home too, and Thomas knew I was lost.

[Thomas] Don't worry, you'll come back to your roots eventually. :)

[Sluggo] For speed, there are pretty much three classes of window managers/desktop environments:

1. KDE, Gnome, Enlightenment: slow.
2. WindowMaker, fluxbox, uwm, and a dozen others: much faster.
3. FVWM, twm, wm2: slightly faster still.
4. larswm, ratpoison: fastest.

[Thomas] That's a fair comparison. Mind you, when you wrote it, what was you thinking when categorising by speed?

[Sluggo] The delay between when you initiate an action and it happens. KDE opens and closes windows noticeably slower than FVWM.

[Thomas] Ah, I see. That might be to do with how the windows are decorated in KDE. But I can't say for sure (typically what happens is that the WM will grab the window before it is mapped visibly onto the screen -- and then apply the decorations. The details of which I am not about to delve into. :P)

[Sluggo] You'll notice a direct tradeoff between speed and features, and between using xlib directly vs a widget library. But xlib programs also look like crap and have idiosyncratic input behavior (whether you can tab between fields or press Enter for OK, whether you can replace text by selecting it, etc), so there's another tradeoff.

[Thomas] Umm, yes, but the speed of the window manager (at the root level) depends how it is implemented. Most WMs have to be written in Xlib if they have any chance of running smoothly. But the speed of the WM doesn't care for what widget set the application was written in.

Well, let's see. Most of the x* apps that are bundled with the XFree86 release are written using the Xt widget set (one level of abstraction up from pure Xlib.) Yes, they might look ugly, but there's some things you can do to "tart" them up.

X apps should (where they've been programmed properly) respond to resource settings. These are values held on the Xserver that makes customisation of the application's widgets available to other uses of the program. When the Xserver loads, it will often process the files stored in:

/usr/X11R6/lib/X11/app-defaults

... the program responsible for that is 'xrdb'. Indeed, like any command one can customise it for theirselves. Whereas most commands when they load look for a config file in $HOME to use instead of the global-wide one, xrdb doesn't since one can use multiple files for different programs. Instead, one can use a ~/.Xresources file or a ~/.Xdefaults file (they're the same file -- one is often a symlink to the other.) As to what they can contain, let's take an example.

xclock.

That's a simple application. If we wanted to, say, tell it to use a red background, then to our ~/.Xresource file, we could add:

xclock*background: red

... and note that the syntax. The "*" matches anything after xclock in the resource name, whereas, I could have used:

xclock.background: red

... which would have stopped the matching at the full word 'xclock'. The colours are looked up via the RGB.txt file, so as long as the colour names are listed there, things will be fine.

Note that it's traditional amongst resource names to be lower case. Indeed, the resource name can be ascertained via the 'xprop' command (or FvwmIdent module, should you use FVWM.)

Going back to the xrdb file though -- save it. In order for those values to be applied to the server, we have to tell xrdb to load the file. The command that should be used is:

xrdb -merge ~/.Xdefaults

... indeed, that does what you think it does. If you were to use: "xrdb -load ~/.Xdefaults" --- that would work, but you'd overwrite the global definitions stored in /usr/X11R6/lib/X11/app-defaults -- so -merge is always the best one to use. I also add this to my ~/.xsession file.

[Sluggo] Another question is memory. Your computer (1.5 GHz, 256 MB) is passable for KDE, but another 256 MB would be more comfortable.

[Thomas] Indeed. X11 by itself takes up a fair chunk.

[Sluggo] I tried wm2 and other minimal window managers, assuming they would use less memory than FVWM, but they didn't. So FVWM is amazingly efficient given its wide configurability.

[Thomas] It's fast because a lot of the more "niftier" features aren't part of the core FVWM -- they're modules. All that's in the FVWM core is enough to get FVWM useable, without bloating it out.

[Sluggo] And the speed it pops up windows and restores them is about as snappy as you can get without losing the "overlapping windows" paradigm.

[Thomas] There's lots you can do about that. Overlapping windows can be a thing of the past, depending on the window placement policy in use. In FVWM parlance:

style * MinOverLapPlacement

[Sluggo] No, I mean losing the capability of overlapping windows.

[Thomas] Ah, that's err, rather a big difference from what I was rambling on, earlier. :)

[Sluggo] Most Unix, Mac, and Windows users are used to moving a window anywhere and letting other windows partially sit on top of it.

[Thomas] Yup -- I do it all the time under Windows at University. Alas, it's the only way of working.

(At University, I usually embarrassingly keep typing in my Linux username and password that I'd use at home, and then getting frustrated when the netadmins ask me who "n6tadam" is, and why am I trying to "crack their account".)

[Sluggo] Windows 1.0 had only tiled windows, meaning a window could never cover another, and they all covered 100% of the screen so there was never a background peeking through.

[Thomas] I liked this way of working (IIRC, the same paradigm was true under Win 3.1 with progman.exe)

[Jimmy] Not quite. It was the default for each application to use the full screen, but it was possible (if damn near unworkable) to have multiple programs overlapping.

[Sluggo] larswm returns to this as a way to maximize productive space and performance, although it also allows some windows to "float". Normally you'd use tiled windows for xterms, editors, your clock/biff/meter panel, etc, and floating windows for graphical applications like Firefox and the GIMP.

[Thomas] That sounds like an interesting way of working, actually. Was that the default way of working under larswm? (I'll try it under FVWM and see if I like it. I currently use 'MinOverLapPlacement', and although I have 9 pages avilable, they almost all look too cluttered, and feel it in operation.)

[Thomas] ... tries to achieve that. That will try and place windows in a linear fashion filling up as much screen as it can, as in:

[window1     ][window2]
[window3][window4][win5]
[         window6      ]

... one can set placement penalties -- to place windows away from others, based on the edge of them and such like -- I don't want to go into too much detail as it can get boring.

Other placement policies one can use is: "TileCascadePlacement", that works like MinOverLapPlacement, but will start tiling window, when all of the available screen space has been used. There's countless others...

[Sluggo] I'm mostly satisfied with KDE. Of course, everybody wishes it started up faster and opened windows faster. But the features, themability, and integration is a good tradeoff. As the KDE developers have pointed out, KDE is "bloated" only in the sense that it has more features.

[Thomas] Sure -- but how useful are they? :)

[Sluggo] You haven't spent years struggling to get programs to input and display non-English characters. Every program did it differently, you needed special fonts, and some programs didn't do it well at all.

[Thomas] Oh, I can well imagine though. It's bad enough now (although considerably easier, I'm sure.)

[Sluggo] Now with KDE you just click the keymapper icon in the bottom right and the keyboard changes language. I don't use that feature -- I got so burned out that I do everything in ASCII now -- but it's nice that it's there without having to dig through a HOWTO and configure a bunch of programs.

[Sluggo] But the features are implemented efficiently, compared to running equivalent programs standalone. konsole with one session uses more memory than xterm, but konsole with two or three sessions uses less memory than two or three xterms, and it has convenient tabs and font selection. FVWM can't be beaten for manual window placement (why doesn't KDE have that?), and it's more intelligent about not giving new background windows the focus when you don't want it to. On the other hand, it only has one flat list of windows per desktop, whereas KDE groups them by application. The latter is important when you have fifty GIMP windows open, a couple konsole sessions and a few Firefox windows. And FVWM can show windows without decorations -- e.g., biff and transparent oclock -- and you can use the root menu to move them or kill them. But you have to set up the menus yourself (unless you're using Debian, which has a WM-independent menu configuration). But I like KDE's panel and klipper and grouped window list, so that usually clinches it for me.

openbox is another WM performs well but lacks of theme . UWM ( unix window manager) with UDE ( unix desktop environment) though based only on xlibs to speed up but I have found hardly any speed difference between icewm and UWM ( with UDE ).

[Thomas] Any good WM can only be written in pure Xlib (as FVWM is.)

fvwm is there but setting its configuration is terrific .

[Thomas] "Terrific"? That's a new one. :P

I have not tested the enlightenment window maker yet.

[Thomas] Enlightenment and "Window Maker" are two different programs.

If any one use any window manager faster than icewm (and configurable like icewm ) please share the experience.

[Thomas] That's a matter of personal bias -- and indeed, see my ramblings above.

[Sluggo] But speed isn't the only criterion. If speed is the only thing you care about, try one of the minimalistic window managers like larswm (http://home.earthlink.net/~lab1701/larswm) or ratpoison

---

This page edited and maintained by the Editors of Linux Gazette
HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/

---