Hacker Newsnew | comments | ask | jobs | submitlogin
Bug 698544 – Background configuration is missing in terminal profile editor (gnome.org)
336 points by Signez 341 days ago | comments


Udo 341 days ago | link

I think this bug report is an excellent example of how not to interact with your users.

1. Remove a long-existing feature without telling anyone, hidden in a minor update

2. A user reports it in a friendly and informative manner. Persch [dev] closes with a single word "No". That alone should make any user furious.

3. A discussion ensues with someone finally (and understandably) concluding that this was done intentionally. To which Mueller [dev] responds: "Please don't. Please give https://live.gnome.org/CodeOfConduct a read. And please consider that this bugzilla is not meant to be a discussion forum but rather a place where actual bugs are kept."

Holy crap, so we are to conclude that it was not done intentionally but it should not be fixed either and that nobody is supposed to complain because the developers' code of conduct states that they always mean well by definition.

4. Another user sheds light on the backstory by pretty much proving this was done on purpose (contradicting Mueller). To which a third developer responds indignantly that the "official" workaround for this issue is sufficient and that the user should head over to the corresponding wiki page and improve the workaround description. He then closes again with a statement about how all devs are well-meaning (just for the added cognitive dissonance I suppose).

What takes the cake: from reading their description, the suggested "workaround" seems to make the whole window transparent, including the terminal text.

-----

Udo 341 days ago | link

Also, the original title of this thread was about a thousand times more informative.

-----

mherdeg 341 days ago | link

In case anyone is curious, the title was "" Gnome 3.7 removes terminal transparency; closing bug with simply "No." ""

-----

coherentpony 341 days ago | link

Yes. This title changing business is infuriating.

-----

jabo 341 days ago | link

I agree. Changing titles decreases the quality of the submission since they are almost always uninformative and mundane compared to the originally submitted titles. And this thread is case in point.

Edit: I'm tempted to write a bot that will catch title changes and post the original title as a comment in the thread automatically.

-----

MichaelApproved 341 days ago | link

I tried something like that once. HNers were not fans of novilty accounts, even a useful one that added content like yours would.

Though, I'd be in favor of you trying and seeing the result. My test was limited and short lived so it may not be indicative of the full community.

-----

plorkyeran 341 days ago | link

The bot which automatically posted links to previous submissions of the same URL was also received pretty poorly despite often being useful, so I wouldn't have high hopes.

-----

beedogs 340 days ago | link

You'll probably be shadow-banned; there's another dirty little HN secret. The moderation here is pretty horrifyingly bad.

-----

ecaron 341 days ago | link

I keep coming back to this idea (https://news.ycombinator.com/item?id=5653878) of creating an API that stores the original titles and then just unleashing a GreaseMonkey scripts that compensates for editors that forget <h1> != story.

-----

stefantalpalaru 341 days ago | link

It's probably a social experiment.

-----

ivan_ah 340 days ago | link

It makes sense to keep the titles of the original articles. Otherwise you would be open for complete rewording of the title, and passing of comments by poster. Let the content linked to speak for itself.

As for how this happens, I don't know? Is this a from moderators import title_checking ... But then Arc is more functional so maybe it is done in code?

-----

akkartik 341 days ago | link

I recently found out that the guidelines explicitly say, "[barring exceptions] please use the original title". (http://ycombinator.com/newsguidelines.html)

I'm still sympathetic to the title-change complaints, and I think HN is leaving a source of creativity on the table to the community's detriment. But the guidelines are theirs to setup and enforce.

-----

lylejohnson 340 days ago | link

I assume that one of the motivations for this guideline is to prevent submitters from editorializing their submissions by altering the original titles (e.g. "Idiotic developers close perfectly reasonable bug report").

-----

akkartik 339 days ago | link

Yeah, I always thought the guidelines said, "Don't editorialize."

-----

Glyptodon 341 days ago | link

Gnome has always been this way. It's kind of sad, but if it was that way in 2006 and 2008 and 2010 it's hardly surprising that it's still that way in 2013. :/

In general, Gnome tends to make decisions internally and then refuse to communicate what's behind said decisions to the broader community.

That said, I don't think I agree with the people who seem to think of transparent terminals as massively important feature, though I do find them nice.

-----

laureny 341 days ago | link

> I don't think I agree with the people who seem to think of transparent terminals as massively important feature, though I do find them nice.

I don't like transparent terminals myself but the bottom line is that Linux users spend a lot of time in their terminal. Terminals are the #1 productivity tools for Linux. You just can't remove features from such tools willy nilly without consulting with your users.

-----

Someone 341 days ago | link

On the other hand, http://www.gnome.org/ describes itself as:

"GNOME 3: Ease, comfort and control

GNOME 3 is an easy and elegant way to use your computer. It is designed to put you in control and bring freedom to everybody."

From that, I don't think they aim to support the group of users that "spend a lot of time in their terminal". They might even look forward to the day they manage to ship a system without a terminal.

-----

pyre 341 days ago | link

If that's their stated goal, then they should just come out with it and let all of the users that spend a good majority of their time in terminals migrate to something else. I have a sneaking suspicion that GNOME usage would take a nosedive if they were to do this.

-----

mpyne 341 days ago | link

Honestly I don't think that would happen even if they plainly stated it. At this point the writing has been on the wall for years and yet the "power users" who would care about this still haven't switched. Whether it's Stockholm syndrome, or self-blaming, or "oh, that wouldn't happen to me" I don't know, but it's getting increasing harder to blame the GNOME devs... they've made their opinion very clear and they're the ones driving the ship.

If you're a passenger and you think you see icebergs you need to abandon ship, not whine with the Captain about where to steer.

-----

juhanima 341 days ago | link

> If you're a passenger and you think you see icebergs > you need to abandon ship, not whine with the Captain > about where to steer.

Really? Not even in the case you think the captain failed to notice the iceberg, and a simple heads up would save not only yours but all the other passengers' lives?

Nothing ot do with Gnome, I suppose, but this was a really bad analogy.

-----

mpyne 341 days ago | link

Perhaps I shouldn't have used "iceberg" as that implies some upcoming inevitable disaster, which I don't think is true of this situation. The GNOME devs could certainly end up very successful.

I happen to disagree with the course, but it's their right as developers to choose a different direction. At some point as a user you have to come to grips with the fact that their vision and yours have diverged. There are undoubtedly many other users who prefer this different direction and they can't all be right.

Find the boat going the direction you want to go and climb aboard and help out.

-----

nine_k 341 days ago | link

Linus wrote a few months ago that he'd switched to Xfce. Does he count as a power user?

-----

pyre 341 days ago | link

Linus is pragmatic though. He'll switch when it's necessary. E.g. BitKeeper => git, KDE3.5 => GNOME, etc

-----

nine_k 340 days ago | link

BitKeeper -> git was a painful necessity when BitKeeper started to want money. It's switching to BitKeeper was pragmatism over hardcore open-source principles, a 'lesser evil'.

I have to learn more about KDE -> Gnome, since I remember it was the other way around :)

-----

mpyne 340 days ago | link

Yes indeed, before Linus used GNOME he used KDE.

He switched from KDE 3.5 to GNOME 2 series when we were dicking around with KDE 4.

Then GNOME started their own process of dicking around and Linus tried KDE 4 (including rotating all the Plasma widgets ;).

Not sure if he stuck there or ended up on XFCE though.

-----

GhotiFish 340 days ago | link

Really? In when Linus did his talk about git for Google Tech Talks, he explained that the reason they parted ways because many of the linux developers were taking issue to working in a non-libre environment, I seem to recall...

hmmm

here's the link: https://www.youtube.com/watch?v=4XpnKHJAok8

-----

pyre 340 days ago | link

BitKeeper was non-libre for a long time, but they dropped the free-to-the-community version[1] which forced the move. Linus drew criticism for a long time over the usage of a non-libre version control system for the Linux kernel.

[1] http://en.wikipedia.org/wiki/Bitkeeper#Pricing_change

-----

mpyne 340 days ago | link

If no one has ever read the backstory behind this it's actually a good tale.

There was more to the issue than BK simply deciding to drop the free version. The short story behind that one of the Samba authors helped force Free Software along in more ways than one!

-----

GhotiFish 340 days ago | link

I went and tried to find some information. Definitely worth a read! Thanks. Actually. I'm gonna post it as a story.

http://www.quora.com/What-are-some-well-written-accounts-of-...

-----

sp332 340 days ago | link

He's been complaining about GNOME for a long time. I guess either they got bad enough Xfce looked better, or he figured out how to get Xfce to do what he needed. https://plus.google.com/+LinusTorvalds/posts/WTLyn7dqYoR https://plus.google.com/+LinusTorvalds/posts/UkoAaLDpF4i And the first comment on https://plus.google.com/115250422803614415116/posts/KygiWsQc...

-----

jcape 341 days ago | link

The terminal is a power-user feature. Unfortunately, there's too much fragile nonsense undergirding Linux to be able to do away with the CLI in the default install right now.

-----

kristopolous 340 days ago | link

There is a profoundly large number of people that prefer the CLI in every way shape or form for 99% of their computing needs.

They are the most absurdly productive and effective computer users I know and the most highly competent.

They can deal with thing abstractly and don't need to spatially visualize every type of manipulation on the screen.

The CLI allows you to create tiny on the fly programs, slicing and dicing small tools to do really useful things.

There is absolutely no way to do it quite as fast if you have to artistically draw the connections with a pointing device in a GUI.

-----

mercurial 340 days ago | link

I think you are severely underestimating the number of people considering the CLI to be a feature.

-----

pyre 340 days ago | link

Are you disagreeing with this:

  | The terminal is a power-user feature
I don't see any comment on the number of power users out there. Most of the people on this forum would probably be considered power users.

-----

saurik 340 days ago | link

I think you have to look at the actual market: Linux is primarily used by people who are power users; I'd go so far as to say that the vast majority of people using Linux are power users, and that the reason they switched to Linux in the first place was specifically because they were power users, and Linux catered to them better.

Now, the best software projects on Linux, ones that had previously been creating software that power users liked, and which became important at all because of the power users that switched over to using it, have apparently decided that power users are a minority segment of the overall market and that they are no longer worth optimizing for.

To make this clear: imagine if Windows, which currently is marketing itself to the "average computer user segment", a user segment that by-and-large were humans with some large subset of eyes, hands, and ears, and decided that the real money in the future was going to be branching out to take over the "any organism of any form" market.

Of course, that market has no real use for a keyboard or a mouse, as the majority of organisms don't have fingers. They can't see the screen, and they probably can't even reason in symbols. So the entire user interface starts getting converted into some kind of EM sensitive yes/no detector that is mostly useful for doing simple arithmetic.

Would this be reasonable? Would the people who currently use Windows not find this ludicrous? This analogy is obviously downright insane, but frankly I think it covers the situation here really well: the people who care about Linux are power users, so by forsaking power users they are forsaking their entire existing market segment.

For a simpler analogy, that I think also nails the core of the problem here while seeming really awkward: imagine if ALL the worlds best manufacturers of semi-trucks decided that cars were more profitable, and so decided to start marketing their products to them, not just by adding amenities but by making them less useful as semi-trucks.

So, over time, new models stop taking diesel, they force a back seat into the front, they add an optional trunk, and one they they decide to just remove the option to hitch things to the back at all. Would this be sane? This may even make sense on some kind of long-term strategy to take over the car market, but their market doesn't want a car.

Here, then: yes, I would agree with "the terminal is a power-user feature", but it is missing the point entirely to then argue that "I don't see any comment on the number of power users out there" here: claiming something is a power-user feature in order to justify its removal is indicating "small market segment", but power users are the market segment.

-----

daenney 341 days ago | link

"It is designed to put you in control and bring freedom to everybody."

That mantra should not just affect the product, it should be the way the whole project functions too.

How is it freedom if they decide that a feature I use is no longer relevant, necessary, chose to remove it and don't inform me about it? It also doesn't give me control, does it?

The whole behaviour of the devs on that thread is completely in-elegant, so much for that part.

I also fail to see how that mantra excludes users that do spend a lot of time in terminals? Don't we deserve nice and elegant things and to be brought control and freedom? They explicitly state everybody, that includes us terminal mungers.

-----

nine_k 341 days ago | link

Is it just me, or the quotation really sounds like some content-free marketing slogan?

-----

pschastain 341 days ago | link

How does removing functionality "put [me] in control" or "bring freedom"? It does exactly the opposite; it leaves me with less freedom and control.

-----

vacri 340 days ago | link

It is designed to put you in control

Clearly their marketing crew aren't talking to their development crew.

My favourite failure is that one of the few options left to the user is setting a default viewer for videos. A setting which it subsequently ignores.

-----

Udo 341 days ago | link

I'm with you. I'm not a Gnome user, nor is my terminal background (semi-)transparent. I just thought this was a great window into the attitude among the project's developers.

-----

foobarian 341 days ago | link

It's kind of ironic that a project with a non-transparent development process decides to remove transparency features in this manner.

-----

adregan 341 days ago | link

I often read discussions asking for designers to get involved in open source software, but maybe some PR folks are needed as well.

-----

SCdF 341 days ago | link

Is it me or has comments 19-24 been deleted? I'm guessing that's where the Mueller response used to be, but I don't see anything.

-----

towolf 341 days ago | link

I just looked at the bug again and it’s been sanitized. I commented 2 or 3 times in the linked bug to add backstory. Those comments are gone now. The attachment I added is still there.

Funny story, they banned me now because they think I submitted this HN story. I didn’t, I came here way later.

http://i.imgur.com/wCTh0MZ.png

Makes you think, doesn’t it? (The warnings refer to another bug a few months ago, where I tried to make another developer explain his removals, and good discussion and a full blog post resulted. All in all a good result. But still they said I was out of line because I named names)

-----

shmageggy 341 days ago | link

Wow... that is so weak.

Their attitude makes me want to switch to another desktop even more so that the software itself.

-----

bhitov 339 days ago | link

> to add backstory.

Didn't you accuse them of intentionally mixing up commits to make the changes hard to reverse? Calling that adding backstory is dishonest and the comment was entirely inappropriate.

(Sincere apologies if I am mis-attributing this comment to you.)

-----

towolf 338 days ago | link

Well, I added backstory, which extended two years before this unnecessary public outrage event. People were asking questions about where the code went. I explained there was no clear single commit and how to find where it was removed.

And then I overstepped and deduced that this may be assumed to be intentional, condering the backstory.

You might say that was inappropriate and I was banned with justification. But I’m a human too and this lack of proper communication frustrates me to no end. If the developer in question can be said to have a breaking point, I have one too.

None of this would have happened if the involved parties had a better standard of communication and of handling matters.

-----

bhitov 338 days ago | link

I empathize with your position, but I don't think it is fair to paint such a negative picture when the reality is, at worst, much less offensive.

-----

rorrr2 341 days ago | link

It's like a North Korea of development. Any dissent, real or imaginary, and you're gone.

-----

mercurial 340 days ago | link

More like 1984. Oceania has always been at war with Eastasia.

-----

vault_ 341 days ago | link

Mueller wasn't saying that it wasn't done intentionally. He was saying not to assume that its removal had been maliciously hidden.

-----

[deleted]
claudius 341 days ago | link

‘this’ refers to hiding the removal, not the removal itself.

-----

Udo 341 days ago | link

I stand corrected. However, Tobias Wolf shows that it was indeed intentional. Which makes sense to me as an outside observer, because if it wasn't intentional then why close it pertly as WONTFIX, why not just come out and say that this feature was scheduled to be removed?

-----

claudius 341 days ago | link

It is obvious that the removal of the feature was intentional. This easily justifies closing a bug as WONTFIX. Whether or not this was intentionally done in a particularly nasty/hidden way is not obvious, and while the commenter claimed that it was intentional, there is little proof, and even if there was proof, it wouldn’t change anything, hence why he was pointed at the CoC.

Am I really defending the GNOME project now? ó.Ò

-----

anonymous 341 days ago | link

And this is why I haven't been running gnome since 2.2

-----

beedogs 340 days ago | link

Stuff like this seems to be endemic to the Gnome project. It helps explain the lack of direction the project has taken in the past 2 years. Gnome has suffered greatly in many ways because of this.

-----

vidarh 340 days ago | link

Past two years? Gnome has been messed up beyond belief for much longer than that. I used to strongly support Gnome, but these days I'm just happy Canonical largely do their own thing with Ubuntu (for now they happen to do stuff that gives me a better environment than Gnome, but I'm ready to jump if they start doing stupid stuff too).

Gnome is quickly making themselves obsolete.

-----

rachelbythebay 341 days ago | link

I said "No." once, but it was in a code review, and there was a lot of context involved. It generated a pretty big backlash until I went to the trouble of explaining all of it. In retrospect, it worked out perfectly, because without the backlash, people might not have realized what had been going on.

I was responsible for keeping a LAMP stack running which ran a bunch of tests written by various other people in the larger department. Usually the benchmark would be C++, and that would be kicked off by a shell script, and that shell script would be kicked off by a Python program. Obviously this is pretty crazy already, but this one guy found a way to make it worse.

One day I noticed this machine was running out of disk space. It was also getting bogged down and was starting to swap since something was chewing CPU and memory. I found a benchmark program (one of the C++ binaries) running, and since it never shut down properly, it kept these giant log files open. Since they were still open, the log rotator couldn't reclaim the space.

I filed a bug with the test owner: please make this test not leave these processes behind. He didn't seem to know how, so I just said that you should make sure you've stopped anything you started. He didn't know how to do that either and booked an appointment in my calendar to see me in person (yes, really).

On that day, we chatted, and I told him that syscalls like fork() return the PID of what you started. You can just hang onto it and whack it later. If that process doesn't fork itself to become a daemon (which this one didn't), odds are it will be the value you want when the time comes. If it does fork or whatever, you might be able to get something done with process groups. I had to explain fork, kill, setpgrp, setsid and all of that to someone who was supposedly employed as a systems tester.

A couple of days later, he sent me a proposal for a fix. It amounted to this:

    ps aux | grep bin_name | grep -v grep | awk ... | xargs kill -9
I should point out that this machine would usually run multiple instances of the same test on different machines at the same time. They'd all have the same bin_name, and they all ran as the same user. At best, the script would kill itself. If we weren't so lucky, it would also bring down anything else which happened to match "bin_name", even if it was completely unrelated.

Even though I had shown him the low-level way to do the right thing, he fell back on this scripting monkey approach. I said that was unacceptable, and left him to figure it out.

Months passed. I'm not exaggerating here. It was something like four months later when I heard back from him. He posted a comment to the (still living) code review asking if things were okay now. I loaded it up to see what he had done.

Nothing had changed. It was the same "ps ... xargs kill -9" cruft he wrote originally. He didn't even try to change things. Maybe he was trying to sneak it past me and wanted to see if I'd forgotten, or didn't care, or what.

Well, given that his question was "is this okay now", my answer to the review was just: "no.". I was no longer interested in elaborating and spoon-feeding him.

He obviously didn't like this, because a few minutes later I had mails from both his boss and my boss saying how I needed to be more constructive and all of this.

I wasn't about to take this lying down, so I found all of our old communications where I tried to teach him how to do his own job: job control stuff fork, kill, and the like. I mentioned all of the back and forth we had and the time I had taken to explain it in person. I even dug up the example code I had written to demonstrate exactly what a session leader or process group winds up doing in practice.

I pasted all of this into the code review, making it public record for the entire company to see. The managers backed off and apologized to me.

A couple of weeks later, he disappeared into some other department.

-----

nolok 341 days ago | link

That's a nice anecdote, but it really doesn't have anything to do with the linked bug.

-----

ovis 341 days ago | link

Christian Persch replied No, which has made people angry. rachelbythebay also replied No and made people angry, but provided background to explain it. Although the circumstances seem different on the surface, I found it to be an instructive narrative.

-----

chris_wot 341 days ago | link

The difference here is that Rachel had extremely good reasons behind her answer, and she explained why in the bug. She wasn't a jerk, but Christian shows that he is with his response.

I've never been a big fan of jerk developers. Even Torvalds. But at least Torvalds explains why he does something.

-----

aaron695 341 days ago | link

How do you know?

Aren't you still at the managers stage where you just got an email fwd to you with someone just saying no?

Or do you know the entire Christian's side of the story?

-----

rachelbythebay 341 days ago | link

You nailed it. The point of my story was that there may be more going on which isn't evident from this response. I don't agree with what's apparently happened here, but we don't have the whole story, either.

Full disclosure: I have no horse in this race. I use fluxbox and eschew all "desktop environments" on Linux.

-----

mpyne 340 days ago | link

Fluxbox is my preferred fallback for the "Shit I Broke KDE" failure mode. It's highly recommended for those who just need to open Chrome and an xterm and don't need anything else fancy.

-----

markrages 340 days ago | link

That's my right-click menu in Fluxbox: Chrome or xterm.

-----

ww520 341 days ago | link

Oh I hate incompetent developers who play political game. It seems that's what they are good at.

-----

mappu 341 days ago | link

> ps aux | grep bin_name | grep -v grep | awk ... | xargs kill -9

I know this isn't the point of the story, but, friendly reminder to everyone about the existence of `killall`

-----

rachelbythebay 341 days ago | link

Please don't assume this will work on all Unixes. killall... sometimes... really kills all.

-----

kerneis 340 days ago | link

Contrary to pgrep and pkill, which do the right thing everywhere (as far as I know).

-----

keypusher 341 days ago | link

So basically, a junior dev came to you for help because he didn't understand how to solve the problem, you spent a lot of time showing off how much you knew about the subject but didn't actually help him solve it, then he went back and struggled on it for months, still couldn't figure it out, and finally got transferred to a different department. This sounds to me like you being unhelpful and condescending towards someone less experienced than yourself.

-----

chris_wot 341 days ago | link

Hardly. It was his job to resolve the issue, that's what he was employed to do. That wasn't Rachel's job, and in fact she went out of her way to explain to him how to resolve the issue.

What would you have her do? Do the fix herself? If so - phooey to you, that wasn't her job and she shouldn't have done so. If you don't think she should have done the fix herself, then the only other recourse here would be for Rachel to not give any help at all and let them struggle on themselves.

The developer attempted to push out a change that Rachel had already said wasn't acceptable, then made a massive fuss to his managers and attempted to make her look bad. Then Rachel explained, in detail, why she said no - developer got transferred due to his own incompetence. I can't feel any sympathy for that developer!

-----

eridius 341 days ago | link

Really? It sounds like he explained all of the relevant tools and APIs, and the junior dev decided he didn't actually have to learn any of that and instead could just code monkey his way through.

Basically, the junior dev sounds incredibly incompetent. Some people you just can't teach.

-----

chockablock 340 days ago | link

*she

-----

jamesaguilar 341 days ago | link

You've heard of the expression about leading a horse to water, right? At some point, if the horse won't drink, you take it out back and shoot it. It's no good to you if it can't feed itself.

-----

brown9-2 340 days ago | link

She told him how to solve it! Was she supposed to write his code, too?

-----

Jonanin 341 days ago | link

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 341 days ago | link

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 341 days ago | link

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 340 days ago | link

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 340 days ago | link

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.

-----

pgroves 341 days ago | link

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 341 days ago | link

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-termina...)

-----

chris_wot 341 days ago | link

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 340 days ago | link

You might be surprised what's hard to do, depending on what condition you happen to be in.

-----

mratzloff 340 days ago | link

For example, you might have a gunshot wound and are trying to make a tourniquet while you type. Did you ever consider that?

-----

GhotiFish 340 days ago | link

Or you could be trying to thread a needle while overdosing on PCP.

The possibilities are endless! :D

-----

Dylan16807 341 days ago | link

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_ 341 days ago | link

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.

-----

pyre 341 days ago | link

  | 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!

-----

Jasper_ 341 days ago | link

I didn't think that through 100%. You're absolutely right.

-----

stuaxo 341 days ago | link

I think it would be reasonable to start requiring a compositor for transparency, if it simplifies the code.

That way we can have our cake and eat it - most of the time if you don't have a compositor then transparency doesn't make sense anyway (performance is terrible) - instances include VNC.

I'd certainly be happy with this solution.

(Speaking as a transparent gnome terminal user).

-----

mpyne 341 days ago | link

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.

-----

Jasper_ 341 days ago | link

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.

-----

towolf 340 days ago | link

From what I’ve read on another bug from 2011 ARGB Visual could also just stay on even without a compositor.

-----

towolf 341 days ago | link

By the way. Ubuntu was using transparent background by default [1].

So it’s fair to say that at bare minimum tens of thousands of people were using this code path.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=692609#c2

-----

chris_wot 341 days ago | link

Your "informal poll" evidently didn't include the userbase.

-----

towolf 341 days ago | link

You forgot to mention that the ARGB Visual type was working well enough for years, ever since xcompmgr was around, all trough compiz and GS.

And the GS → metacity → GS cycle was not crashy here at all. It worked.

And now you’re getting into Wayland territory. All the more reason to make sure that windows with alpha maps work.

You can keep the old code around in the meantime.

Also, making a poll in your 50 people IRC channel is not a very meaningful sample size is it?

-----

pyre 341 days ago | link

  | 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?

-----

towolf 341 days ago | link

> Really?

No idea. That’s what I derive from "we had an informal poll". Since they hang out on IRC that is probably where it happened.

-----

Jasper_ 341 days ago | link

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.

-----

towolf 341 days ago | link

> but minds were changed.

So what does it take to make the minds change back again?

When I stare at opaque terminals all day I get severely perceptually understimulated to the point that I fear becoming an automaton.

But with some sliding animations and a bit of flower poking through it soothes my nerves.

Is that not enough reason?

-----

towolf 341 days ago | link

I can’t see how Gsettings has anything to do with opacity and the compositor.

Perhaps separating these things out in different commits would’ve been smarter to begin with.

-----

Jasper_ 341 days ago | link

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.

-----

jodrellblank 341 days ago | link

I can’t see how Gsettings has anything to do with opacity and the compositor.

You are implying that because you don't know about the connection, there must not be one?

Perhaps separating these things out in different commits would’ve been smarter to begin with.

20/20 hindsight criticism from someone watching from the sidelines? Helpful.

-----

towolf 341 days ago | link

Only looking for explanations. Really super grateful that Jasper_ added some, but it’s still not entirely clear.

-----

keenerd 339 days ago | link

> 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.

-----

More



Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: