
Bug 698544 – Background configuration is missing in terminal profile editor - Signez
https://bugzilla.gnome.org/show_bug.cgi?id=698544
======
Udo
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.

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

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

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

~~~
nine_k
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 :)

~~~
GhotiFish
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
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
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
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-...](http://www.quora.com/What-are-some-well-written-accounts-of-the-Linux-
Bitkeeper-Git-story)

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

------
columbo
It's the attitude more than the bug. People (and to a greater extent
Developers) don't always have the greatest grasp on language. And this DOES
NOT mean everything needs to be 'sugar coated'.

Want something removed? Create a definition of when you should activley remove
something. Like this:

Candidates for feature removal of (SYSTEM)

* Does not impact how the application can be used

* Requires manual testing

* Is greater than 1% of the size of the application, or greater than 500 lines of code

If X meets all three candidates it's up for removal. Any bug created can be
referred directly to this list.

There. You don't have to come out and say "We're terribly sorry, but
unfortunately we've decided to remove this feature because of blah blah blah"
and you don't have to just say "No.". Instead you can say "Removal decision is
based on (INSERT LINK TO ABOVE), if you disagree (INSERT ACTION TO
CHALLENGE)".

What people want is something that gives the impression of a uniform set of
decisions. They don't want to feel that people/developers are just being petty
dictators.

~~~
cbhl
Conversely, it's the developers' time and energy. If the people requesting the
feature care enough, they should go through the hoops necessary to (edit:
learn how to code and) become part of the core team.

For this _particular_ feature, it's a "rampant layering violation" --
translucent windows have been available in compositing window managers
(Compiz, and whatever that thing that KDE uses) for at least three or four
years.

Assuming these users have a fast enough CPU/GPU, they can configure the
desired behaviour using the ccsm graphical tool.

~~~
vault_
I would argue your solution is exactly backwards.

The job of the compositor is to draw a window how it asks to be drawn. The
window in question is extending that choice to the user: "how do you want me
to look." It then tells the compositor to draw it in that fashion. I would
argue that this is the correct place for this choice.

If you use the compositor to control transparency, what you have is the window
asking to be drawn in a certain way and the compositor saying "Eh, you'd look
way better at 50% opacity". If it's the user controlling this it's even worse.
Now they have to be able to write a regular expression on certain window
classes for each application they want to modify, and have far less
granularity in how the window is modified.

The compositor exists to faithfully draw windows and place them on the screen
according to what is requested. Only in exceptional cases should it be asked
to do weird things with certain windows.

~~~
cbhl
Do you also then accept that it is okay for the window in question to have
access to the bitmap data drawn in _other_ windows in order to tell the
compositor "how I want to look"?

I'm not sure how else you expect the window to get the data for the background
(i.e. root window) (and/or other windows, as applicable) in order to make a
transparent background.

Edit: Although if it specified the background with an alpha channel, I suppose
I guess it would be okay.

------
NelsonMinar
If accurate, this comment by Tobias Wolf is the craziest part:
<https://bugzilla.gnome.org/show_bug.cgi?id=698544#c19>

"He hid the removal among very unrelated changes (gtk to gsettings switch) and
spread the rmeoval across more than one commit. Such that you cannot easily
revert it. I strongly assume this was done intentionally."

~~~
johnchristopher
It is stated in the previous talk he mentionned that removal of that feature
was planned. In they eye of 'Persch' this is not a bug, it is an improvement
to GNOME.

It's not a bug, it is the removal of a feature. Is a bug tracker really the
most appropriate place to discuss in which direction a software is to go ?

'No' and a link to the relevant reason and workaround should be fine in that
case but apparently that had already been discussed before (and a reason was
given).

I don't know if removing it through so much commits is good practice but if
the feature was to go it doesn't make a difference in the end, he sculpts his
piece of the software any way he likes it as long as it's feeature oriented,
right ?

Note: I have no advice on wether that feature should have been removed or not
in the first place.

~~~
eloisant
Actually I think the line between bugs and new features is thin enough so
everything can go to the bug tracker. They're both changes that need to be
made, tracked, to get to a better state.

Also, inevitably some people in good faith will believe they find a bug when
something doesn't work the way they expect it to behave. You can't expect
everyone to follow all discussions about features getting cut, so a link to
whatever discussion there was (if ever) would have been appropriate.

~~~
johnchristopher
Wouldn't that be a problem for large projects such as gnome or firefox ? Devs
would have to spend some precious time curating the bug tracker issues and
explaining decisions and educating users instead of using the bug tracker for
its intended use: to track bug.

~~~
Dylan16807
Would? I'm not sure about gnome but firefox definitely has feature requests
and planned features sitting in its tracker, with some of these created by the
devs themselves for coordination.

~~~
johnchristopher
Well... I am naive about collaborative software development :)

Do users post to the firefox bug tracker when features are removed like in the
gnome case ? How is it handled ?

~~~
shabble
Yep. There's one that bit me recently, where Esc key was previously able to
stop GIF animations, and was very handy.

Apparently, this behaviour was considered a bug, if a very long-lived one. So
a recent update 'fixed' that behaviour, although the justification is stronger
there, and the workaround (SuperStop addon[2]) is actually useful, although
still on a different keybind (Shift-Esc)

[1] <https://bugzilla.mozilla.org/show_bug.cgi?id=825486>

[2] <https://addons.mozilla.org/en-US/firefox/addon/superstop/>

------
ParadisoShlee
Sit down and let me tell you a story about Gnome of old - a very happy little
linux desktop with a bunch of happy users. For nearly ten years I was a gnome
user and there were many like me who looked at their DE and smiled because it
was good. but as time progressed, the desktop ecosystem got stale and most of
the other DEs were unchanged in any noticeable way for more than ten years
because people were happy enough.... then people started talking and decided
that this year or next was the YEAR OF THE LINUX DESKTOP and something had to
change to make it so.

So the gnome developers had a plan. "Linux needs a desktop for all of these
people who don't use linux". We need to build something for the non-users....
and the other developers looked at each other and agreed. "YES! Let's throw
away our current user base and focus on the users we don't have". The
developers were very happy with themselves.

We can focus on tablets and touch... everything can be round and safe and
nobody will be able to change anything because they will simply love our
environment so much.

and since that sad day, the gnome developers pretended that nobody actually
uses gnome and everybody who did were less than human. They waited for the
billions of people on the planet that would really really love using gnome
once they find it.

So I left..

Classic gnome developers and their little man syndrome.

------
btilly
Here is my theory/perspective.

I, and a lot of people, are willing to spend time configuring the environment
until it fits like a glove. When we have to upgrade, what we want is for that
to just continue to work, but with bugs fixed.

In practice we wind up having to reconfigure to get back to the same state as
before. And this makes us want to avoid upgrading. This also makes people who
care not be involved in development - after all our environments are as we
want them to be, and we want that to get out of our way so that we continue to
work. So developers never hear from us unless something breaks. And then we're
upset.

When an upgrade means getting rid of the way that we are used to working, we
get unhappy. Therefore people who develop desktops do not like people like me.
I can understand that. But I still do not appreciate the arrogance and
condescension that I see coming from desktop developers towards people like
me.

I personally have no idea why people get involved with developing desktops. It
is not something that interests me. It is clear when I read what they say that
they do not want anything resembling what I want.

My ideal desktop almost used to be fvwm2 - maximum real estate, multiple
screens, no "helpful (mis)features" that I didn't want. The only missing
feature on my wishlist is to have multiple monitors, with the monitors cycling
independently through screens. But many years back Debian integrated their
version of fvwm2 into Gnome, and things stopped working properly. (This was
long enough ago that I no longer remember what broke - just that it did
break.)

I developed a dislike of the Gnome project back then, which I've never seen
anything to dissuade me from.

~~~
pekk
No affiliation with Gnome or any desktop project here, so don't blame them if
you disagree with me.

The people complaining when they're upset do not necessarily represent
everybody. Actually the people who are so vocal as to post the same bug 8
times and tar the project on Hacker News with lots of misrepresentations of
what happened are probably not the most helpful to the community. Let those
determine the direction of a project and you will continuously add features
without any technical direction until it becomes bloated, a nightmare to fix
or extend, and the only tastes served are this one bitter, vocal minority that
becomes your entire community.

Maybe you should buy a commercial OS and try complaining to the salesmen, see
how much they will charge you to ensure that arbitrary custom feature X ends
up in the next release.

~~~
btilly
I'm fully aware of this. But the definition of a feature is "a bug with
seniority".

Transparent terminals are a feature that they used to have. I've used that
feature myself so that I'd be constantly looking at my daughter's happy face
rather than the blank background of my many terminals. No utilitarian purpose?
Perhaps. But a very real psychological one!

In fact this is valuable enough to people who spend time in terminals that
even commercial OSs that you disparage, like OS X, have realized this is a
valuable feature to include. So have the providers of other terminals.

But Gnome developers don't see things this way. They have a theory of what is
utilitarian for their users, and that is the direction that they pursue. In
the process they consistently ignore actual feedback from actual users, and
completely devalue the psychological needs of their own users. This is a great
attitude if you are designing a jail. Not so great if you are designing
something for humans.

~~~
j-kidd
The craziness started more than 10 years ago when Havoc Pennington declared
himself as the "usability expert" by writing this article:

<http://www106.pair.com/rhp/free-software-ui.html>

Excerpt:

> On hearing that preferences have a cost, some people get upset that we're
> going to remove every preference, or that their favorite one is gone, or
> whatever.

Sometimes I think the problem with Gnome is that the cost for them to do
anything is just too high, due to bad architecture. Thus they always opt to do
less. This is in contrast with KDE's approach, where they strive to improve
the architecture, so that it is easier to do more.

------
obviouslygreen
Regarding the removal itself, this is an unfortunate trend that, as far as I'm
aware, started in the last couple years with Firefox and Chrome
inappropriately and unapologetically removing features and options (and
changing standard behavior like the image view background color) that had
previously been present and in use. I don't think it's really curable, as it
always seems to be the result of inconsiderate people having too much sway
over what gets pulled/committed, and that's just a risk of open source.

The dev's attitude here is also shit... if you're not willing to reasonably
address valid concerns related to decisions you've made that were obviously
going to affect regular users, you have no place making those decisions and
forcing them on others in the first place.

~~~
jkrems
The trend towards a more concise feature set is I suppose a consequence of
open source software maturing from "hackerware" to proper, widely used
software. The moment your settings screen would benefit from a search
functionality, you should reconsider "doing it all". Maybe they want to
concentrate on a very basic Terminal solution, leaving more complex use cases
and features to other implementations.

At the same time: The reaction of the developer and they way it was done was
pretty unprofessional. When redesigning a settings dialog and dropping a
couple of 'em in the process, a proper changelog-entry would be the least.

~~~
return0
This is a terminal we are talking about, its never going to be widely used. It
makes sense to simplify things like the file browser, but a terminal?

~~~
Joeri
Everyone who deliberately chooses linux is also a terminal user. I cannot
imagine someone choosing linux and then never using the terminal. It is by far
the most widely used program on the system.

~~~
return0
By that logic, everyone who uses linux is a power user who will never be
confused, there is no need to remove any features in the first place. (btw, i
think that's true but gnome people don't get it)

------
kunai
While I don't personally think that terminal transparency is a big deal (just
switch to Xfce Terminal if you want it), the attitude of the developers is
rude and uninformative.

You don't have to be completely ingratiating; just say "This feature was
removed because of [reason], if you do not like this decision, comment on
[place to comment].

That's it. A "No." is unacceptable.

------
ultim8k
Is it me or linux desktop was better 5 years ago?

The ui was always inconsistent and ugly (e.g. Gnome icons are a joke), but it
was fast and had some cool features the competition implemented years later.

Now its behind the competition, terribly slow and still inconsistent and ugly.

Sorry devs, I don't mean to understate your work, but sometimes criticism is
needed to help evolution and improvement.

~~~
kunai
I agree that current UIs are inconsistent and ugly, but I would argue against
that ~2005-2008 UIs were inconsistent and ugly. The Gnome icons were
cartoonish, yes, but they were consistent AND informative.

If you remember using Ubuntu 8.04 (perhaps the greatest Ubuntu release of all
time), you'll remember it being VERY consistent, fast, and excellent all-
around.

I loved it so much, that out of nostalgia I had to VirtualBox it just to bring
back the memories.

Really, it was OS perfection. No other operating system comes close to the
intuition, the pure ease that 8.04 had.

~~~
keithpeter
Oddly enough, I still have the Hardy Heron wallpaper on my current Debian
Wheezy xfce4 based desktop.

CentOS 5.9 is a close analogue and CentOS 6.4 can be themed appropriately.

Interface Design Reflection: Go and watch a string quartet playing. Reflect on
the 'usability' of a couple of violins, a viola and a cello. Heidegger may
have had a point.

------
eblet
GNOME has been plagued with terrible maintainers and even worse management
that doesn't get rid of them immediately, leading to a drastic erosion of the
brand value it acquired during GNOME 2.

In any sensible project Mr Christian Persch would be stripped of all his
commit privileges immediately, but in GNOME there is no such oversight.

The root issue is probably that most GNOME people are employed by Red Hat, but
Red Hat doesn't really care about the consumer desktop GNOME is targeted for
because they focus on servers and enterprise.

As a result, these guys are paid to work on GNOME and thus have plenty of time
to influence it, but are left without any management, which results in these
guys directing the project according to their own whims, with total disregard
for users.

Over time, this culture eventually influenced even people like Persch which
appear to be independent maintainers.

~~~
keithpeter
_"The root issue is probably that most GNOME people are employed by Red Hat,
but Red Hat doesn't really care about the consumer desktop GNOME is targeted
for because they focus on servers and enterprise."_

Well, thanks to Redhat for paying the wages because we need developers working
on desktops.

In my experience, corporate clients are _conservative_ (blue shirt, suit,
pocket protectors). Many corporate clients will license Redhat servers and
perhaps use CentOS on the clients.

Can you imagine how a demonstration of Gnome 3.x would go with those kinds of
people? I suspect xfce4 will be available as an option in RHEL 7.

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

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

~~~
eridius
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
*she

------
jaseemabid
This is not the first time gnome developers are doing this. The project is in
a state where they just don't listen to the community and keep on doing really
bad things. Its not surprising that the whole gnome 3 is a huge failure. Here
is an example.

Quite some time back they removed the tree view[1] and nautilus extra
panes[2]. Reason? it is not good on touch screens! So what about all the
developers on normal laptops? I dont see a good future for the gnome project
with all this rude behaviour.

PS: I wrote a longer blog about this sometime back.
[http://jaseemabid.github.io/07-11-2012/thoughts-on-
gnome-3.h...](http://jaseemabid.github.io/07-11-2012/thoughts-on-gnome-3.html)

1\.
[https://git.gnome.org/browse/nautilus/commit/?id=ef467c87753...](https://git.gnome.org/browse/nautilus/commit/?id=ef467c8775392d0f0feb0e38f7a80f2d41719d84)

2\.
[https://git.gnome.org/browse/nautilus/commit/?id=b8d5b4a7bcf...](https://git.gnome.org/browse/nautilus/commit/?id=b8d5b4a7bcf47ed34a6343c95bcc3b079255c0a0)

~~~
vidarh
Personally what annoyed me was the removal of spatial features in Nautilus.
Fair enough, they were not that much used, but the amount of code needed was
minimal and a similar amount of code required to strip it out could also
easily have made it non-invasive. As it is, I use Nautilus rarely as most
Linux file managers are still primitive compared to Amiga filemanagers ca.
1990, and Nautilus is far from the top of the bunch of Linux file managers,
and so I resort to the shell most of the time, but to me that took away the
one redeeming feature Nautilus had.

Gnome developers seems to have been on a decade long ego-trip. Of course
that's their right - it's their project, but they shouldn't be surprised that
their decisions gets constantly questioned and criticised by people who
started using Gnome based on totally different assumptions of where they'd be
going.

These days, gnome-terminal is pretty much the only Gnome app I regularly use
left, and with apps like Terminology, and Ubuntu replacing more and more with
their own stuff, there might soon not be much Gnome left for me (and at least
I know Terminology won't strip the eye candy, coming from the Enlightenment
rew).

------
mseepgood
I fail to see a single use case for terminal transparency. It makes text less
readable.

~~~
dsr_
Allowing people to choose their own text colors and backgrounds is inefficient
and can make text less readable. There ought to be a small set of allowed
combinations that have optimal contrast, referred to by simple names.

Allowing people to choose their own fonts can make text less readable. There
are only 3 or 4 reasonable choices anyway, so all others should be dropped.

Allowing themes to change window decorations can cause confusion and reduce
usability. Let's drop that.

Having more than one window manager available is inefficient and means that
more developer time is wasted in duplicative effort. Only one window manager
is needed.

Having more than one web browser is inefficient and means duplicated effort.
Drop all other browsers.

Having more than one Linux distribution is inefficient.

Having more than one OS is inefficient.

Having more than one system architecture causes needless work.

Supporting any NIC that isn't the best makes the system less efficient. Drop
inferior NICs.

~~~
Joeboy
mseepgood's argument is that terminal transparency _always_ makes things
worse. None of your ironic statements illustrates a comparable case, or
constitutes a rebuttal to that claim. I can't see a worthwhile use case for
terminal transparency either, but I'm happy to be corrected.

~~~
nemo1618
Not 100% relevant, but there are quite a few people who like to keep inactive
windows semi-transparent.

At any rate, the only reason you need is user choice! User choice is always a
valid reason. Removing customization options is rarely the proper thing to do.

Of course, in this case, users still have a choice: they can choose to install
another terminal! Which it seems many of them have done.

------
eliben
It makes me sad how prone programmers are to condescension and dismissing
attitude towards other programmers. Especially leads of open-source projects.
Something about having all that influence gets into people's heads.

~~~
two
I run a large open source project. I don't think it's an ego thing. I wake up
every morning with around 50 e-mails of people complaining and criticizing
something I devoted a lot of time to writing, while asking nothing in return.
Of course, there are many more happy users of the software. However, I can
totally relate to his "No." response. I would cut him a little slack... he was
probably just having an off day.

~~~
shubb
First of all, thank you for your work!

I think this kind of angry dialogue isn't helpful. It won't bring people
closer to agreement.

But I don't think you can say "I made this thing, and gave it to you, so you
can't criticize my actions regarding it".

The core team of an open source project control what code gets into it.

Some core team members are great programmers, or contribute a lot of time.
Others are the real world friends or bosses of important team members.

It's not like you could get up tomorrow, go full time on Gnome project, and
expect to be able to put this feature back in.

Regarding your 'I get nothing back, so go easy on me' point, this isn't always
true.

On some open source projects, many of the biggest contributors are working on
the project for a company, and use their influence to take it in the direction
the company wants. They are being paid, and changing what the project is in
return that. If I don't like those changes, I'm not sure your argument
applies.

More generally, strong contributors to popular projects often consult or get
jobs on the back of them.

I can see how this stream of complaints could be disheartening. But you do
have power. You have been entrusted with other peoples work. I think being
held to account (politely) is sort of fair enough.

~~~
pekk
If I put a lot of work into making something, it does not make me accountable
to do whatever you want to that work. Sorry, it does not work that way. But if
I open sourced it, you can make the change yourself.

Open sourcing it does not mean that other people are entitled to control it.

~~~
shubb
There is a contradiction in your post, and in this story:.

The developer in this case is part of a self appointed core team who have the
keys to infrastructure bought with other peoples donations.

He has removed functionality written by someone else.

In neither case does this "it's my ball, don't tell me how to play with it"
thing apply.

The wider problem-

Zooming out from this specific case, from open source projects to standards
organizations, unelected cabals have a great deal of influence over what
happens in technology.

Why is it important? Try this scenario - What if a key player at Mozilla (who
got the position because his company bought them servers) decided to delete
FTP support. Would that be okay?

Sure, we could fork Mozilla, add FTP back in. But if our fork didn't get much
adoption, then it wouldn't make it into linux distributions, wouldn't have the
manpower to merge in bugfixes from the mainline. It would fizzle, Chrome would
drop it, then IE, and FTP would be gone from the world.

So these people do have power that the ability to fork doesn't nullify.

The community gives them power and resources (especially in the case of large
projects where the project lead wrote less than 1% of the code). Can you
really say they shouldn't be held to account for how they use them?

------
c-a
To quote the maintainer in another bug.

\--- The reason is that these settings make no sense. Why should a terminal be
transparent, or have an image behind everything, but the same not apply to,
say, gedit, or firefox, or evolution?

~~~
j-kidd
That's the problem with self-proclaimed usability experts. They see the word
"consistency" and think to themselves "Oooooh, I shall make everything
consistent".

This is why in Gnome, all tab bars are on top, including in the terminal.
Consistency for the sake of consistency.

------
aristidb
Because mentioning that it's Gnome 3.7 is so much less important than the bug
number. (The original submission title did include some editorializing
perhaps, but at least the reader had a chance of knowing that it was about
Gnome 3.)

------
cpdean
Why did the title of this link get changed? Now it's generic and doesn't
highlight why this is a big deal. It's glossing over the most salient part of
this narrative.

------
wladimir
This is the final straw, I'm switching to KDE/Kubuntu in next release.

Even if a transparent terminal is a weird thing to like, I like it, and have
always used it. Taking it away just because you think it's useless is not
acceptable to me. Really you can come with 1000's of arguments why it's non-
productive, "just aesthetic", "not in web browsers either" and so on but I
don't care. And I'm sure I'm not the only one.

(as an aside I think it could be a interesting feature in web browsers to
support window-level transparency. Use a background with partial transparency
and render web content directly to the background. For example, for desktop
widgets)

We're in 2013 right with super-powerful GPUs of today (and even the crappy
i945 in your old laptop) it shouldn't be too much to ask to do a small bit of
composition. Sure, X's archaic architecture may be at fault, it may be tricky,
but now there's Wayland, Android Surfaceflinger, ... Please don't go backward
to better support archaic APIs.

For me, open source is about choice and customization and possibilities, if I
wanted a platform with a single vision I'd go for Apple.

~~~
vidarh
Frankly, I think Ubuntu will soon enough have so little of Gnome left in its
standard version that you shouldn't worry too much about switching.

------
Kjeldahl
I like transparent shell backgrounds. I recently upgraded to Ubuntu 13.04
using Gnome 3.8 (using the team-gnome3 ppa), and my terminals still has
transparent backgrounds (with a setting in the profile menus that allow me to
modify it as well). So I guess either Ubuntu or team-gnome3 patches Gnome to
keep the transparent stuff in?

~~~
xiaomai
The gnome3 ppa is still 3.6 for the most part unless you are also using
-staging.

~~~
Kjeldahl
Ok, thanks. That's quite confusing. I'm using the Gnome 3.8 shell, with mostly
3.6 Gnome packages. Looks like I'm in for a surprise when I upgrade in the
future.

------
GhotiFish
It its core. I don't disagree with what gnome is doing.

Removing an old feature is fine by me if you have something better.

 _If you have something better._

but... If you're just trying to homogenize your user base, then you deserve
the acrimony you're going to get. I'm glad this story got some publicity.
Thanks Signez!

------
raverbashing
Thank you Gnome

Next time I get into a discussion about how Gnome doesn't give a rat's ass
about user experience, I'll just point to the article link.

Here's (another) proof of that.

And that's why switching to XFCE is the first thing I do in my Linux
installations

------
rjh29
If you want a workaround, install xfce4-terminal. It's a fork of GNOME
terminal and retains all of the settings that GNOME removed, including
background transparency. It also appears to be faster.

~~~
cmccabe
It's worth installing Xfce in general. It really ought to be the default
desktop environment for Linux.

------
anonymous
I think it's telling that even before clicking the link, I knew precisely what
it was about, even though I haven't used Gnome in years and never knew the
terminal ever gained or lost the ability to have a transparent background.
Actually, compare and contrast with this bug report
<https://bugs.kde.org/show_bug.cgi?id=198175> about a similar feature in kde's
terminal.

------
gfodor
Meanwhile, Apple added improved terminal transparency support in Terminal.app
in the last OS update which allows the user to control not only the
transparency but also the blur. (I've found transparency goes from distracting
to slick if you include blur.)

I guess the question is why is it that GNOME developers are cutting features
in the name of simplification when a company known for obsession with
simplicity is adding those very same features?

------
_ak
Well, Desktop on Linux has been shitty in the last 10 years, and it will be
for the next 10 years, exactly because an attitude like that. 10 years ago,
after faffing around for several years with Linux desktop environments, I
simply decided to move on to OSX, and have been happy since then.

Downvote me as much as you want, but some developers will never learn how
malicious their attitude is to all of the OSS community.

------
tripzilch
Aside from whether they were right to remove it and whether this was
communicated properly or not,

can anyone explain me what's so useful about having a transparent terminal?

I agree that it looks pretty and sci-fi, which is a fine reason, but from the
general backlash I get a feeling there's more to it than that. I personally
always found semi-transparent terminals harder to read, and prefer a plain
dark background (I've tried subtle textures, but found them to be more effort
to get right over how much they improved visual style).

I'm assuming it might be something about the ability to read what's behind the
terminal window? But every time I encountered such a situation, the letters on
the terminal were interfering with the info behind it (probably a browser),
and even if I could make out what it said, a quick alt-tab switch back and
forth was so much easier.

The only real advantage I can think of might be the ability to _roughly_
determine what application is running behind the terminal, or whether there is
in fact an application running or not. Which is nice but most WMs have other
ways of indicating that information (taskbar, etc).

~~~
tripzilch
Plucked a few reasons I found here and there in this discussion in case
anyone's interested, turns out I may have underestimated the functionality of
pretty & shiny!

<btilly> "I've used that feature myself so that I'd be constantly looking at
my daughter's happy face rather than the blank background of my many
terminals. No utilitarian purpose? Perhaps. But a very real psychological
one!"

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

------
D9u
There's a simple fix for this, and other, GNOME related issues...

 _Get rid of GNOME!_

I can do as much, and be as productive, without using a specific DE, by
setting up my GUI to use a simple tiling Window Manager (DWM) along with
dmenu.

Seriously, there are a myriad of Terminal Emulators available which are not
desktop specific, and configuration is merely accomplished by editing a plain
text file.

Why is this crap even on the front page of HN?

~~~
bowyakka
Just wait, gnome is slowly removing features I think the plan for gnome 4.x is
to simply not exist

------
fixxer
I don't use transparency and I think it smells like feature creep... but
taking it away from those who have become semi-dependent on it is very
different from having the foresight to have not added it in the first place. I
think those users have a legitimate gripe.

I hate it when my development environment gets screwed with.

------
drill_sarge
For general Gnome3 stuff (I don't care much about the look of my terminal):

I know they are trying to make it very easy to use for average useres
(whatever this is) but why do I have no access at all to not even really
"advanced" options directly from gnome? I need tweak tool for nearly
everything. Where did the menu bar go in Nautilus 3.8? Why do I need to
download a gnome extension to disable this hot spot in the upper left corner?
same for window list. No minimize/maximize buttons, need tweak tool for it.

I think the concept of gnome 3 is nice and worth a try but why are they trying
to block users who are not absolute beginners? and even those beginners maybe
want to change their window theme or have other icons.

------
virtualwhys
I've given Gnome 3 a fair shot despite the fail whale cries from community at
large, but after a couple of months it's really starting to wear on me,
particularly drag & drop support, which is straight up GONE, system-wide,
ouch.

On the plus side, Nautilus has become pointless as I've switched to Midnight
Commander, a great FM.

I do have background transparency set for gnome terminal, a nice touch, I
quite like it.

Currently hiding Gnome behind I3 WM, but it does creep up to the surface at
times, like the odd mid-beer bomit (burp -vomit).

Oh well, nothing is perfect on Linux, there must be some pain involved;
otherwise it would be OSX where pain is replaced with happy spinning beach
balls ;-)

------
oakaz
Yes, welcome to the reality.

You can never talk about user friendliness, simplicity, aesthetic with Linux
maintainers and their best friends.

Their religion is robustness. And having a religion leads you believe that
what your religion tells you is always more important than what other people
would like.

He probably has a good reason and doesn't want to explain that because you are
not smart enough to listen him.

Welcome to the Linux community. I use Arch Linux for 8 years and recently was
advised to stop using Linux because I asked maintainers to not break things
and listen their users.

All they care is more robustness. It's their religion and you can't discuss
about this with them.

------
DanBC
I understand why Gnome don't want huge configuration dialogues.

Still, it's stupid and they're wrong. They should have a big "[return to
default configuration] button that people must use before filing bugs or
asking for support. But they should then also have a nice config file with
configurations for everything.

That allows tinkerers to tinker and to set up alternate support. It allows
God_Designers_Coders to lock down everything in the
One_True_Environment_Config.

It certainly avoids threads shown in the OP, which are just a turn off for
some developers.

------
chris_wot
Funny. The Gnome guys got rid of desktop icons too... took me a while to find
how to add it back with Gnome Tweak.

Gnome developers are like that: they like to remove useful features.

------
Tomdarkness
I understand that Bugzilla may not be the appropriate place for the
discussion. However, the reporter did not seem to be impolite in any way and
may of not been aware there was a more suitable location to discuss the change
so I'm not sure what warranted the blunt reply from the first developer who
replied. The reply later on from Tobias Mueller seems much more appropriate.

~~~
bkor
Agree it was too blunt and not appropriate. The cause was that he was upset
after various bugreports and private emails accusing him of all sorts of
things. At one point it'll get to you.

------
drbig
The point with terminal transparency is that people who use them a lot tend to
look at them a lot, and having something more appealing than white-on-black is
in many cases a necessity for their happiness and well-being.

And we already have a 'simple' default terminal - xterm. We also have twm, but
not many people seem to be using it daily either. Guess gnome's going there
too.

------
hcarvalhoalves
The good thing about FOSS is that the developers own the code. The bad thing
about FOSS is that the developers own the product.

------
bryceneal
I can think of an open source project for a popular node.js debugger that has
similar problems.

[https://github.com/dannycoates/node-
inspector/issues?labels=...](https://github.com/dannycoates/node-
inspector/issues?labels=&milestone=&page=1&state=closed)

------
chumpalump
Several terminals are my IDE. The font and the transparent background are my
theme. If you're staring at terminals for 4 to 8 hours-a-day a good
combination of font, text colors, and background keep the text from floating
away on your burned-in retina.

------
laureny
> Persch was very devious with this one. He hid the removal among very
> unrelated changes (gtk to gsettings switch) and spread the rmeoval across
> more than one commit. Such that you cannot easily revert it.

What is wrong with these people?

------
digisign
Disgusting. Linux desktops are lacking as it is, the destruction of mature
features has it moving backwards... and now weaker than Windows 95.

------
lnanek2
I don't really know why anyone wants transparent terminals anyway. Don't they
just make the text harder to read?

------
ChuckMcM
Wow, and all it takes is one smart angry 'user' and blam! you've got a fork
and yet another window system.

------
Taranis
No is a fine answer, if an explanation accompanies it. I am surprised GNOME
still has a user base really.

------
Aardwolf
How about forking it?

~~~
JamesMcMinn
Forking doesn't fix the issue at hand here, which is the lack of communication
between Gnome developers and everyone else.

~~~
watt
The fork provides way forward for the rest of us, while Gnome developers
rapidly make themselves irrelevant.

------
adrianlmm
first of all, the users are not giving any argument of why they need the
transparency back, just "because I like it".

Second, this is open source, hack it.

~~~
TheCowboy
An example of a group of users who find this feature valuable is [new] users
who might want to have documentation open in a browser while navigating the
commandline. I've definitely found it useful, especially when on a small
laptop screen.

The response that it's open source, don't complain, you fix it, doesn't even
seem to apply here. Does it even make sense to commit a patch to put a feature
back in that a maintainer with power over the direction of the project decided
to remove without explanation?

Additionally, open source is also about community and wanting people to use
your software, not alienate users out of some misguided ideal that sounds good
in your head but just makes you out to be a selfish jerk in practice.

~~~
adrianlmm
Then the terminal would need to be really transparent allow text reading,
honestly, I find that improbable.

The fix it argument is valid in any open source project that you don't
contribute, and if you want to contribute show first valid arguments.

Open source is about many goals, a simple terminal transparency is not one of
them, and why would a user alienated because it doesn't have a transparent
terminal?

------
xyproto
I like it XD

------
sublimit
Why was the title changed? It was much more descriptive of the appeal of the
link (the developer's response). Now it looks like the bug report itself is
the focus.

~~~
cpdean
Maybe someone at Gnome is a moderator here. A generic title about a bugzilla
bug makes me less interested in clicking.

