5 ms·

A friend of mine works on gnome, and I asked him about it. The actual explanation for this is a lot more reasonable: "Him: OK, I figured out what happened. It

by Jonanin 13y ago

A friend of mine works on gnome, and I asked him about it. The actual explanation for this is a lot more reasonable: "Him: OK, I figured out what happened. It wasn't ideal in terms of commits. So, we have an old configuration system GConf, and we replaced it with our new one, GSettings, for N reasons. GSettings was missing a feature for gnome-terminal to implement, so it went without GSettings for a long time, until the 3.8 cycle, when we ported it over with a workaround. The port wasn't 100% complete, so it landed with the intention of adding feature parity, like with terminal transparency support. However, after asking our team, we decided it wasn't worth it keeping the support code around for terminal transparency, and dropped it. It's an unfortunate thing that happened where the reasoning wasn't relayed entirely in commit messages, and you're right -- it was dropped in a seemingly unrelated commit. But that's after intentions changed -- a broken port to new tech with the intention to fix it, then that changed, and thus it got dropped under the guise of "Remove dead code" me: fair enough. so the only wrongdoing really was persch's response. Him: Yeah. So, it turns out that he was just tired. That was the 7th or 8th bug report about it, and he didn't feel like explaining it again."

farmdawgnation 13y ago
So, the moral of this story is "communicate clearly the first time or you're going to end up having to communicate clearly about seven or eight times." That said, I don't understand why he felt he had to keep explaining it. He could have just copied and pasted the answer or closed the bug as a duplicate of the original one that reported the bug. In the original he could have posted a kind explanation about it, and linked to it from the duplicates that followed. I understand what it's like to get tired and short tempered. I used to moderate an online community primarily of middle schoolers and high schoolers. But ultimately, you end up hurting the community you're supporting more by not doing things The Right Way™ the first time around. You hurt it even further when you fail to acknowledge that you're tired, short tempered, and should probably just go to bed and deal with it in the morning. Maybe I just expect adults to behave like adults, but "he didn't feel like explaining it again" doesn't float with me as a valid justification for how he handled the issue. It would have taken a comment and a link to deal with it the correct way. Live and learn, sure, but the attitude reflected in his response appears (to me, at least, with my limited visibility) to be reflective of a systemic attitude surrounding GNOME development. And that's no good.
- mpyne 13y ago
  I was going to recommend "closing as a dupe" as well. One nice thing about that is it makes it very easy to see which bugs are causing anguish with the users. Also it makes it clear which single point of discussion contains the rationale for the changes so that the developer doesn't have to re-explain (something to which I'm sensitive myself, having been on the dev end of changes like this).
  - vacri 13y ago
    Close-as-duplicate is the right answer, though there's a special place in hell for people who close-as-dupe without referring to which ticket is the dupe. In my previous role as a software tester, there'd be all sorts of tickets closed-as-dupe, yet I couldn't find them. Turns out that they had no common search terms and were (usually) not actually dupes, just that the coders didn't want to think too hard on the issue. I'm fine with "won't fix" or pushing to backlog, but let me see what the dupe is.
    - azernik 13y ago
      I'm mostly used to the equivalent functionality in Launchpad, but my impression is that most bug trackers have a special "duplicate of bug N" closing reason that requires a link to another bug.
Dylan16807 13y ago
I find it interesting that you use the word 'guise' in a post defending the code removal. There is still no explanation for the removal except for "wasn't worth it", which is pretty lacking by itself. And the way you resolve a repeated bug report is to link it to the last one and close-duplicate. You don't even need to respond at all. In short: What you've explained is more reasonable but it's still opaque and unhelpful; someone involved should summarize why it was removed and if it could be rewritten and put back in.
- Jasper_ 13y ago
  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. X just isn't meant for modern graphics.
pgroves 13y ago
I just searched for a few different mutations of the phrase "background transparency" in their bugzilla and didn't see any. I was expecting this to be a case of an end user not taking the time to see if their issue was already in the bug tracker, but if it's in there, it's hard to find. If there were really multiple bug reports (which I'm not saying there weren't) then bugzilla has a pretty bad search feature. It's a pretty big problem when bug trackers are exposed to a group of non-technical users. Stackoverflow has a nice feature where it does a real time search of existing questions as you type yours in to prevent duplicates. I wish that was a considered a must-have feature of bug trackers.
- towolf 13y ago
  You have to use an advanced search to find NOTABUG, WONTFIX, and DUPLICATE and similar bugs. Otherwise you turn up empty. There’s even more discussion in the other bugs. For some reason they didn’t dup all those bugs consistently. Maybe that would’ve lead to a criticla mass. But who knows why not. [List of bugs mentioning problems related to background transparency](https://bugzilla.gnome.org/buglist.cgi?product=gnome-terminal&query_format=advanced&short_desc=background%20transparency%20opacity%20transparent&short_desc_type=anywords&order=bug_id%20DESC&query_based_on= https://bugzilla.gnome.org/buglist.cgi?product=gnome-termina...)
chris_wot 13y ago
So if it's a duplicate bug report, mark it as such. Do just type in "No." as your answer and close as WONTFIX. Point the reporter back to the original bug! How is that hard to do?
- GhotiFish 13y ago
  You might be surprised what's hard to do, depending on what condition you happen to be in.
  - mratzloff 13y ago
    For example, you might have a gunshot wound and are trying to make a tourniquet while you type. Did you ever consider that?
    - GhotiFish 13y ago
      Or you could be trying to thread a needle while overdosing on PCP. The possibilities are endless! :D
keenerd 13y ago
> However, after asking our team, we decided it wasn't worth it keeping the support code around for terminal transparency, and dropped it. Um, isn't this all handled by VTE? And as a Gnome project, does this mean transparency will eventually be removed from VTE? I know of about 20 VTE-derived terminals that will not be pleased to hear this.

by Jonanin 13y ago

farmdawgnation 13y ago

So, the moral of this story is "communicate clearly the first time or you're going to end up having to communicate clearly about seven or eight times." That said, I don't understand why he felt he had to keep explaining it. He could have just copied and pasted the answer or closed the bug as a duplicate of the original one that reported the bug. In the original he could have posted a kind explanation about it, and linked to it from the duplicates that followed. I understand what it's like to get tired and short tempered. I used to moderate an online community primarily of middle schoolers and high schoolers. But ultimately, you end up hurting the community you're supporting more by not doing things The Right Way™ the first time around. You hurt it even further when you fail to acknowledge that you're tired, short tempered, and should probably just go to bed and deal with it in the morning. Maybe I just expect adults to behave like adults, but "he didn't feel like explaining it again" doesn't float with me as a valid justification for how he handled the issue. It would have taken a comment and a link to deal with it the correct way. Live and learn, sure, but the attitude reflected in his response appears (to me, at least, with my limited visibility) to be reflective of a systemic attitude surrounding GNOME development. And that's no good.

mpyne 13y ago
I was going to recommend "closing as a dupe" as well. One nice thing about that is it makes it very easy to see which bugs are causing anguish with the users. Also it makes it clear which single point of discussion contains the rationale for the changes so that the developer doesn't have to re-explain (something to which I'm sensitive myself, having been on the dev end of changes like this).
- vacri 13y ago
  Close-as-duplicate is the right answer, though there's a special place in hell for people who close-as-dupe without referring to which ticket is the dupe. In my previous role as a software tester, there'd be all sorts of tickets closed-as-dupe, yet I couldn't find them. Turns out that they had no common search terms and were (usually) not actually dupes, just that the coders didn't want to think too hard on the issue. I'm fine with "won't fix" or pushing to backlog, but let me see what the dupe is.
  - azernik 13y ago
    I'm mostly used to the equivalent functionality in Launchpad, but my impression is that most bug trackers have a special "duplicate of bug N" closing reason that requires a link to another bug.

Dylan16807 13y ago

I find it interesting that you use the word 'guise' in a post defending the code removal. There is still no explanation for the removal except for "wasn't worth it", which is pretty lacking by itself. And the way you resolve a repeated bug report is to link it to the last one and close-duplicate. You don't even need to respond at all. In short: What you've explained is more reasonable but it's still opaque and unhelpful; someone involved should summarize why it was removed and if it could be rewritten and put back in.

Jasper_ 13y ago
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. X just isn't meant for modern graphics.

pgroves 13y ago

I just searched for a few different mutations of the phrase "background transparency" in their bugzilla and didn't see any. I was expecting this to be a case of an end user not taking the time to see if their issue was already in the bug tracker, but if it's in there, it's hard to find. If there were really multiple bug reports (which I'm not saying there weren't) then bugzilla has a pretty bad search feature. It's a pretty big problem when bug trackers are exposed to a group of non-technical users. Stackoverflow has a nice feature where it does a real time search of existing questions as you type yours in to prevent duplicates. I wish that was a considered a must-have feature of bug trackers.

towolf 13y ago
You have to use an advanced search to find NOTABUG, WONTFIX, and DUPLICATE and similar bugs. Otherwise you turn up empty. There’s even more discussion in the other bugs. For some reason they didn’t dup all those bugs consistently. Maybe that would’ve lead to a criticla mass. But who knows why not. [List of bugs mentioning problems related to background transparency](https://bugzilla.gnome.org/buglist.cgi?product=gnome-terminal&query_format=advanced&short_desc=background%20transparency%20opacity%20transparent&short_desc_type=anywords&order=bug_id%20DESC&query_based_on= https://bugzilla.gnome.org/buglist.cgi?product=gnome-termina...)

chris_wot 13y ago

So if it's a duplicate bug report, mark it as such. Do just type in "No." as your answer and close as WONTFIX. Point the reporter back to the original bug! How is that hard to do?

GhotiFish 13y ago
You might be surprised what's hard to do, depending on what condition you happen to be in.
- mratzloff 13y ago
  For example, you might have a gunshot wound and are trying to make a tourniquet while you type. Did you ever consider that?
  - GhotiFish 13y ago
    Or you could be trying to thread a needle while overdosing on PCP. The possibilities are endless! :D

keenerd 13y ago

> However, after asking our team, we decided it wasn't worth it keeping the support code around for terminal transparency, and dropped it. Um, isn't this all handled by VTE? And as a Gnome project, does this mean transparency will eventually be removed from VTE? I know of about 20 VTE-derived terminals that will not be pleased to hear this.