I'm that friend. I said to Jonanin: "If you want to know exactly, it's a lot of very, very tricky code that's easy to get wrong, hard to get right, and even when it looks like it's working, there's a large perf cost if it's not 100% right.", but it seems he didn't paste that part of the chatlog.
I can't speak for why Christian Perch spoke the way he did, but he knows that he shouldn't do it anymore.
So, let's go into more details. There are a few ways to get real transparency for windows under X.
First of all, there's _NET_WM_OPACITY which is handled by the compositor window manager, and that's the replacement workaround suggested, but some think it's not appropriate enough. Fine.
Second, there's "psuedotransparency", which is expensive on a modern system. Basically, you copy parts of the root window, excluding your window, and then paint it under your window. Every time some other window updates, you need to re-fetch contents. This is wasteful, but it's how transparent terminals were implemented in the 80s. To implement it, there's a bunch of MMX (yes, MMX) code that's been copy/pasted to every project. The only existing program that uses pseudotransparency that's still maintained is XChat/HexChat.
Third, there's RGBA visuals, which require a compositing window manager. The issue here is that the RGBA visual isn't always around: it's dependent on your window being redirected to an off-screen pixmap. If the compositing WM restarts, or you close down the compositing WM and start up a traditional WM, or close down the traditional WM and start up a compositing WM, you have to basically close your window and re-open it. This is racy and bad to do at WM startup time, and accounts for a few bugs/crashes in the WM or in gnome-terminal. Furthermore, closing and restarting the window means that the new window is now on top of the stack whenever you restart the WM.
It's really ugly behavior all around, and we did an informal poll and found that almost nobody was using transparent terminals, and decided to drop the code.
| First of all, there's _NET_WM_OPACITY which is
| handled by the compositor window manager, and that's
| the replacement workaround suggested, but some
| think it's not appropriate enough. Fine.
This is the part that I don't understand. The whole point of 'terminal transparency' is to make the background transparent while leaving the text opaque. This 'workaround' makes everything transparent, which defeats the purpose of leaving the text readable.
I don't personally use terminal transparency, but it does not seem logical that someone could see _NET_WM_OPACITY as a replacement for this. This seems like a really weak (and poorly thought out) attempt to 'throw a bone' to the people that want the feature that's being removed.
Sure, we're removing the NY strip steak from our menu,
but there's always the hamburger, that has beef in it
too. You can even add steaksauce to the burger!
That's what we did with Konsole for KDE 4. KWin integrated compositing with a software fallback in case GL wasn't available, so there was simply no need to maintain the KDE 3.5-era fake transparency.
Nowadays GNOME Shell simply requires a compositor, or so I thought, so it seems like you could assume one is present.
The one issue is supporting the case of running gnome-terminal from non-GNOME environments that also don't have a compositor, but I think it would be fair to give up entirely on supporting that use case.
However you might still want to handle the case of the compositor crashing (I think one of the dev's comments in this thread mentioned that), which is admittedly going to be annoying since it involves dealing with X.
We'd love to do that, but sometimes it doesn't work that way. If you restart the compositor, in order to not crash, you need to unmap and remap your window with a different visual. So the code needs to be there anywhere if your compositor WM doesn't crash.
| Also, making a poll in your 50 people IRC channel
| is not a very meaningful sample size is it?
They just polled the IRC channel? Really? That just seems like the definition of a 'circle jerk.' Was the assumption that all or a majority of users technical enough to use the terminal would be in the IRC channel?
The old code didn't work after the port to GSettings. It crashed in weird places. That's why it was "#if 0"'d around in the GSettings port commit. As I said, the original intention was to fix it, but minds were changed.
With hindsight, yes, we'd love to do things differently. Saying "you should have done" doesn't really help the current situation here.
The gsettings port broke stuff and reintroduced problems. It was long overdue. This means that cutting features to get things out of the door might happen.
If I had to guess without debugging, I might guess that the 'changed' signals were firing at different times in comparison to when the slider was being adjusted that means that changing the background wasn't ordered 100% correct. The code stems back to 1996 -- it's possible that assumptions like these are being made.