Talk:Comparison of X window managers

Why moved to article

Separate article for inclusion to Category:Software comparisons. --Mykolas OK (talk)

references in the table

Comments for version 2007-10-01T12:03:02 by 86.56.48.141 said, "rv - the new edit made the link invisible; even in articles where the table is transcluded. I agree that having a footnote in a table is not ideal, but show us a better solution that actually works." Actually, it made the (Blackbox) link/reference show up only in the Blackbox page. This seemed to me a reasonable way to compromise. After all, you don't want references displayed that aren't completely applicable to the article being viewed—that doesn't make sense. Maybe this shouldn't be a template but its own article. ⇔ ChristTrekker 15:47, 2 October 2007 (UTC)

Why include Matchbox?

Including Matchbox in this table gives the false impression that these projects are related. As far as I can tell, they are completely different, similar only in naming and somewhat by size. The Blackbox derivatives are minimal by design whereas Matchbox is minimal as a side effect of being targeted at PDAs. --IanOsgood (talk) 15:12, 22 January 2008 (UTC)

It shouldn't give that impression. They are similar in naming, and they do share some similar goals (being small and lightweight, hence good for limited-resource applications). That's all that's implied. One can infer that people would want to compare/contrast them to see which is right for them. ⇔ ChristTrekker 20:03, 24 April 2008 (UTC)

Context needed

This article needs some explanatory text so that the general public will at least have some idea of what it is about. - Realkyhick (Talk to me) 18:58, 29 March 2008 (UTC)

Probably a result of having started life as a template rather than an article. I'll see what I can do. ⇔ ChristTrekker 20:04, 24 April 2008 (UTC)

Heavyweight/Middleweight/Lightweight

How are the window managers being classified as "heavyweight" or "lightweight"? Is there a defined criteria, or did someone just put them there arbitrarily? inclusivedisjunction (talk) 05:16, 14 June 2008 (UTC)

It's essentially arbitrary, based on "conventional wisdom" as well as descriptions in the respective articles. I'd love to find a reference that gave some hard numbers regarding binary size and memory used. These can be very hard to determine in normal usage, though, as most apps these days use shared libraries. The only good way to do it (AFAIK) would be to build all the apps statically. However, it would be OR if we did it ourselves. Note this discussion is also taking place on Template talk:X desktop environments and window managers. Whether or not it's entirely accurate objectively, it's a very useful metric for readers interested in this subject. That said, I hope the accuracy of this classification can be improved. ⇔ ChristTrekker 16:54, 24 July 2008 (UTC)

Surely XMonad should be considered “lightweight”, I think even wmii wouldn’t be considered as being in the same class as Fluxbox. fophillips (talk) 22:48, 26 July 2008 (UTC)

I'd consider Xmonad farily heavyweight with all the configuration options it has. I really don't think there's any way to objectively classify things like that.

Binary size and memory usage are objective measures. Unfortunately, it's hard to track down comprehensive sources for these. ⇔ ChristTrekker 14:25, 11 August 2008 (UTC)

Butbut, xmonad has like 500 lines of code, and is a tiling window manager - which is pretty lightweight visually. I guess the other tiling wms will fill the lightveight category, so its conceptually a better fit. Are you saying its slow and large when compiled? Still it should definitey be be in that category.--193.198.7.30 (talk) 11:28, 19 August 2008 (UTC)

I make no comment on xmonad. I merely stated that disk/RAM footprint are objective measures. LOC doesn't tell much, because it may depend on 50 libraries for the bulk of functionality. However, I do tend to agree that tiling-type super-minimalist WMs seem to be distinct from other lightweight varieties such as IceWM and Blackbox. ⇔ ChristTrekker 13:17, 20 August 2008 (UTC)

Metacity licence

Why is Metacity listed as being LGPL? Marnanel (talk) 06:31, 11 January 2009 (UTC)

Also, what are these C++ parts of Metacity? Marnanel (talk) 12:52, 9 March 2009 (UTC)

Virtual Desktop features

One of the most important features hasn't been mentioned in the comparision: Virtual desktops and the option to configure the window manager so that moving the mouse pointer over the edge of the screen will switch to another virtual desktop. Neither the window manager that comes with KDE, nor the one that comes with Gnome allows switching desktops by moving the mouse --- and the simple lack of a basic feature that fvwm (before it was fvwm2) already had like 15 years ago makes these window managers useless to me. Enlightenment can do it, and fvwm; I don't know which others can. Lee-0 (talk) 07:46, 12 July 2009 (UTC)

I agree, I came to this page hoping to find a WM that implements fvwm2-style virtual desktops. It's such an amazing productivity enhancer that I've found it hard to believe that it's never been implemented in other WMs ... but I've been looking for about 10 years with no luck. (I'll have to try Enlightenment, thanks Lee-0!) For those who don't know, the fvwm desktop model has the multiple virtual desktops arranged in one continuous 2d-plane, potentially much larger than the physical monitor screen, as opposed to the typical virtual desktop solution which has multiple topologically disconnected planes which are all the same size as the physical monitor. (FVWM can also have multiple disconnected desktops, too.) Yes, many WM's or 3rd party apps allow you to arrange the various desktops in a 2d grid, and switch between them in a way that implies a directionality, but that's not the same thing. In fvwm, you can scroll the "glass" in arbitrary ways around the desktop, either with mouse or keyboard. You can move around in whole screensize units, or in small fractions of a screen size. Windows default to being at some location on the virtual desktop, but can also be assigned as "Sticky", that is, stuck to the glass of the monitor. There's more to it, but that's the gist of it. So the questions: should this functionality be added as a column to this table? Does anyone know enough about other WMs to be able to populate this column reliably? --Spatrick99 (talk) 14:19, 18 May 2010 (UTC)

Oi, update! I just tried out Compiz, and it does in fact handle virtual desktops just like fvwm, and then some. I'm sold! The question of whether/how to include this feature in the comparison table still stands, however. --Spatrick99 (talk) 16:10, 19 May 2010 (UTC)

Compositing vs. Stacking

What makes a compositing WM different from a stacking WM? It seems to me like compositing should be a feature column and not lumped in with window management type. Compositing WMs still act like stacking WMs, they just add effects. Special effects to not change the way you manage windows the same way a tiling WM does. What happens if/when a tiling WM starts using compositing?

From Stacking window manager: "A stacking window manager is a window manager that draws all windows in a specific order, allowing them to overlap, using a technique called painter's algorithm. All window managers which allow the overlapping of windows, but are not compositing window managers are considered stacking window managers"

The difference cited here is "Overlapping windows" - a thing which compositing WMs certainly allow.

Compositing window manager has this to say about the differences between compositing and stacking: "While not noticeably different to the naked eye, 2D compositing creates a more realistic model of the windowing system than traditional stacking window managers, which allows for features like window translucency and eliminates the need for chroma keying or green screening in the X video extension."

Again, I see a false distinction being made here; compositing is a possible WM feature--as are window rollup and multiple desktops--but not a new type of WM. A stacking WM with compositing is not a different kind of WM from a stacking WM without compositing. A tiling WM with compositing would still be a tiling WM.

Can someone provide evidence (citation) describing why a compositing WM is not a stacking WM and why they should be classified absolutely as distinct? If no justification for this arbitrary division can be made then compositing should be separated from window management type and moved to its own column in the comparison table.

--Sorpigal (talk) 13:37, 23 September 2009 (UTC)

wmii change 21/10/09

Changed wmii to supporting tabbed windows, because it does. —Preceding unsigned comment added by 84.13.209.15 (talk) 16:41, 21 October 2009 (UTC)

Non-auto-raising windows feature?

Being a GNOME user, I use Metacity, and I like it, but I would like to know if there's another window manager that I might possibly like more, or about the same. For future reference, you know. Every other window manager I've ever used, including Mutter (because I tried GNOME-shell a little, which I like except for Mutter) and KWin don't solve one of my two biggest gripes with Microsoft Windows: when you click on a window it automatically comes to the front. Metacity can be configured to do so, but my preference is to leave the window where it is, and bring it to the front only if I click the title bar or click the window anywhere while holding down my Windows key.

My question is, what would this feature be called (I've searched around for Metacity features), and do any other window managers use this? I would think this would be worth adding as a column in the comparison table. D. F. Schmidt (talk) 01:34, 1 November 2009 (UTC)

I think you have it correct, in a sense, but I'm not an expert. I believe the feature which auto-raises windows when they have focus, as typical in MSWindows and MacOS, is called "auto-raising". You're asking if there's a name for being able to turn off auto-raising, yes? "configurable auto-raising" maybe? "optional auto-raising"? A related feature is whether window focus follows the mouse or whether focus requires a click. --Spatrick99 (talk) 14:31, 18 May 2010 (UTC)

Update: I now see that Compiz has this feature explicitly, and calls it "Raise On Click". It also has "Auto-Raise" and "Click To Focus". --Spatrick99 (talk) 16:13, 19 May 2010 (UTC)

Tabs in metacity

Are you sure that there is a "tabbed windows" feature in metacity? —Preceding unsigned comment added by 83.28.49.169 (talk) 05:21, 2 April 2010 (UTC)

Xmonad

Xmonad requires GHC installed to be able to run all the time, most xmonad users also install additional packages to give it more functionality. Shouldn't Xmonad be classified as middleweight because of this? Regardless of how many lines of code there are?