I currently use GNOME 2.24, but I noticed the file hasn’t changed since 2.22 and it’s still the same in 2.26 other than a few comments; hence my inability to enter a version number for this bug report.

I’m sorry, after posting I noticed that this bugzilla doesn’t have the useful “Search for similar bugs first” box, so I didn’t check if it’s already known.

I now did search for it, and turns out that bug 521893 seems to be a duplicate of this (or rather, the other way around). I do provide a patch, though.

I also found out that this gnome-wm seems to cause more problems than it solves (including a rant by a gnome-session developer tired of updating it on every Compiz release :)

Isn't using compiz-manager the right thing to do?

(In reply to comment #3)
> Isn't using compiz-manager the right thing to do?

I don’t know... I remember only using compiz-manager when first trying to find out how to get compiz to run, but then I noticed compiz alone worked perfectly (until I run into the subject of this bug report), without the startup overhead of compiz-manager, which is a shell script and does quite a lot of preliminary checks and shows diagnostic info (which can be good if you’re starting Compiz for the first time, but I don’t really need that).

compiz-manager is 384 lines long, and the only relevant part is 3 lines long; is using it really *the* answer?

Also, no “case” statements in gnome-wm consider compiz-manager, so any arguments passed to it are not forwarded to compiz (talking about setting WINDOW_MANAGER='compiz-manager' instead of ='compiz').

(In reply to comment #4)
> (In reply to comment #3)
> > Isn't using compiz-manager the right thing to do?
> 
> I don’t know... I remember only using compiz-manager when first trying to find
> out how to get compiz to run, but then I noticed compiz alone worked perfectly
> (until I run into the subject of this bug report), without the startup overhead
> of compiz-manager, which is a shell script and does quite a lot of preliminary
> checks and shows diagnostic info (which can be good if you’re starting Compiz
> for the first time, but I don’t really need that).
> 
> compiz-manager is 384 lines long, and the only relevant part is 3 lines long;
> is using it really *the* answer?

Yes? :-)
Do you really think it has a real impact on your user experience?

The whole point of compiz-manager is to have a simple command so we don't have to care how to launch compiz, and so that it fallbacks on something that works when necessary.

My understanding is that it's now the best way to support compiz.

(In reply to comment #5)
> Do you really think it has a real impact on your user experience?
> 
> The whole point of compiz-manager is to have a simple command so we don't have
> to care how to launch compiz, and so that it fallbacks on something that works
> when necessary.
> 
> My understanding is that it's now the best way to support compiz.

Well, I don’t know it’s going to affect my experience, but right now gnome-wm *does* care to know how to launch compiz, so why not make it work?

Update: (conclusions at the end)

As GNOME 2.26 went stable on Gentoo x86 (that’s what I use), it looks like gnome-wm is completely disregarded.
Actually, at first the upgrade 2.24 » 2.26 was quite a catastrophe. At first, Compiz wouldn’t even start (Metacity was launched instead); after looking at gnome-wm (it’s still there), I found out the window manager is now determined by a value in GConf.
Still, after changing that to “compiz”, all I got was a naked (decorator-less) Compiz, and it was ridiculously slow (as if input and graphic output were only read/updated every 4 seconds or so).
I also tried “compiz-manager”, with similar results.
I finally realized (Googled) the key was to change compiz.desktop to start (learn by mistake) a tiny shell script that first starts the decorator, then exec’s compiz (unlike compiz-manager, that just sits there wasting memory).
After this, I still experienced a 10 seconds delay (black screen) with an error message in kmesg from gnome-session whenever compiz was started, and that turned out to be a lack of a session-id argument on compiz’s command line, so I also added that to the shell script.


Put shortly, I no longer feel the need that prompted me to open this bug. The solution I proposed here is of no use in GNOME 2.26, Vincent’s suggestion doesn’t work either, yet I found a way around the whole thing.

If you’re interested in any of the weird problems I run into, please let me know, as I can easily “reactivate” them, and I can provide more detailed information.

(In reply to comment #7)
> Update: (conclusions at the end)
> 
> As GNOME 2.26 went stable on Gentoo x86 (that’s what I use), it looks like
> gnome-wm is completely disregarded.

Err, no. I'm talking about 2.28, though; so 2.26 might be different.

> Actually, at first the upgrade 2.24 » 2.26 was quite a catastrophe. At first,
> Compiz wouldn’t even start (Metacity was launched instead); after looking at
> gnome-wm (it’s still there), I found out the window manager is now determined
> by a value in GConf.

Bug in gentoo packaging: compile with "--with-default-wm=gnome-wm" or "--with-default-wm=compiz" or... if that's what you want.

> Still, after changing that to “compiz”, all I got was a naked (decorator-less)
> Compiz, and it was ridiculously slow (as if input and graphic output were only
> read/updated every 4 seconds or so).
> I also tried “compiz-manager”, with similar results.

(won't work if you don't have a compiz-manager.desktop file)

> I finally realized (Googled) the key was to change compiz.desktop to start
> (learn by mistake) a tiny shell script that first starts the decorator, then
> exec’s compiz (unlike compiz-manager, that just sits there wasting memory).

That's an upstream compiz issue: there's no real & unique way to start compiz. As far as I've been told, the way is supposed to be compiz-manager. If it's not compiz-manager, then please tell me what it is. But it's certainly not launching the decorator and then compiz with some options that change with time.

[...]

> Put shortly, I no longer feel the need that prompted me to open this bug. The
> solution I proposed here is of no use in GNOME 2.26, Vincent’s suggestion
> doesn’t work either, yet I found a way around the whole thing.

As far as I can tell, you're just hitting a packaging bug and the compiz issue I mentioned in a previous comment (the fact that compiz is annoying to launch), which is why I prefer to only support compiz-manager in gnome-wm.

(In reply to comment #8)
> That's an upstream compiz issue: there's no real & unique way to start compiz.
> As far as I've been told, the way is supposed to be compiz-manager. If it's not
> compiz-manager, then please tell me what it is. But it's certainly not
> launching the decorator and then compiz with some options that change with
> time.
> 

I totally agree, imho, the simplest way to start compiz is to add fusion-icon or compiz-manager in autostart apps (System-> Pref -> Startup apps)

=> metacity will auto-detect that there is another WM, and that should work perfectly... (at least in full 2.28)

Okay, first let me apologize for committing error #1 in bug reporting: I forgot to mention which version I’m using.
So, at the time of the first post I was using GNOME 2.24; now I’m using 2.26.

From your comments, I gather there’s really no sure way to set Compiz as default WM; the closest you can get is to have it in your session, but that will start Metacity first, so I don’t like that :)

Since I know at least Fedora and Ubuntu do provide Compiz by default (as opposed to Gentoo, where it’s always been “unstable”), I decided to go take a look at an Ubuntu computer. So, the process tree is:

compiz
+ compiz.real
  + compiz-decorator
    + gtk-window-decorator
    + compiz (not sure about this last name)

(Sorry, did this last night, now memory might be betraying me already.)
Now, of those, at least two are shell scripts - too small memory footprint, while the others are at least 3 MB (which I inferred is what you get from linking with GTK).

My point being, the Ubuntu devs too seem to think compiz-manager is not the solution (unless one of the scripts is actually it, under a different name - very possible), except their solution is much more complicated than what it replaces. Of course in their case it makes sense, they want it to run handlessly on any computer.

Compare to compiz-manager:

compiz-manager
+ gtk-window-decorator
+ compiz

Or my solution, that’s an adaption of the last few lines of gnome-wm:

compiz (exec’d from compiz-start, my shell script)
+ gtk-window-decorator


(In reply to comment #8)
> (In reply to comment #7)
> > I also tried “compiz-manager”, with similar results.
> 
> (won't work if you don't have a compiz-manager.desktop file)

Right, in fact I believe all I got there was a WM-less desktop. My reporting mistake.


So, summarizing: you were told compiz-manager is the right tool, so that must be right, for how much I might not like it. The Gentoo package only install a non-working compiz.desktop (I’ll report this) that only launches Compiz, without a decorator; Ubuntu goes an entirely different and massive way (it doesn’t even seem to use gnome-session at all).

It looks like first the Compiz devs should standardize the “how to launch it” part; then it’ll probably be direct responsibility of each distro, how to make it easy to switch WM without having to mess around. I.e., Gentoo should provide a compiz-manager.desktop (or change the contents of compiz.desktop), for users to select compiz-manager as their WM.

Reopening as I think the requested information has been provided.

gnome-wm has been removed, so I guess this should be closed.