"If it was the only terminal emulator, there would be a good reason."
Gnome Terminal may (effectively) be the only terminal emulator available to you if you do not have rights to install software or to change default software.
If you are in an environment where you have to take what you are given, then whinging to the software developers to add in the functionality your boss won't let you have seems like the wrong move.
Yes, you're right. They should apparently be whining to their boss to use something other than GNOME instead instead of trying to fix their work environment at the source.
I'm assuming the said boss would not have approved the update to GNOME without first checking that all the features they require the workforce to have in order to work, are present.
Then yes, they should.
If the boss gives you lemons, you don't go to the lemon tree and ask if it can make lemons that read email, browse NFS shares and change screensaver settings. You go to your boss and say "just-lemons isn't good enough".
When you cook, do you just give people a bowl of nutrient paste, saying "that's all you need to remain functional"? But we'd like something with texture and flavour. "So what, it's not like those things are needed to be functional. You can get by without them."
You know, I understand wanting to put a little pressure back on the "make everything configurable" crowd; there are a lot of software engineers who go a bit overboard on the "just make it an option" approach to design, and then wind up with big, bloated, buggy software that tries to do everything but fails at most of it and is frustrating to configure.
However, "choice is poison" is a rather extreme over-compensation for this problem. Sometimes, options really do provide value. And many times, if they are designed correctly, they don't substantially increase cost; if the features are orthogonal and implemented independently, the additional complexity is only linear with the number of features, not quadratic or worse as happens if they are too interrelated.
I understand that we want to get away from the "you need to spend hours customizing your environment to make it usable" approach to design that plagues some open source project, but going to the other extreme and saying that "choice is poison" is just as bad.
There's plenty of precedent. The plan9 guys were very explicit about not having variable colours in acme. The suckless.org team say that you can configure whatever you like, but only through changing the source code. BeOS aimed to have no configuration and good defaults.
I'd rather have something that was well thought through and is internally consistant than a grab-bag of customisation, none of which coexists well - like most linux desktops.
I'm not baffled. Giving people fewer options seems like a pretty popular paradigm these days. We tried "Give people choice" in the '90s and '00s, and it turned out people were mostly unimpressed. "Opinionated software" is the paradigm du jour.
And still, a lot of seemingly smart people are baffled by the fact that Linux has failed to penetrate the mainstream OS market for personal computing...
Also relevant: http://www106.pair.com/rhp/free-software-ui.html
This text is the unofficial Gnome UI manifesto. If you don't agree with it then you probably will never be happy with Gnome and should use something else.
Choice may be good, but it always comes at a cost. Each choice takes time to design, to code, to test, to document, to support, and most importantly to learn. Software designers should aim to offer the smallest number of options they can get away with.
> Software designers should aim to offer the smallest number of options they can get away with.
That's should always be second to providing solutions. Solve the problems that transparency solved first. If you aren't aware of the problems that transparency in terminals provided, then removing it is purely an act of ignorance.
Try one of a dozen solutions which split your screen into two parts? screen and tmux both do this?
If your documentation isn't viewable in terminal, why do you insist of having a full screen all the time - resize your terminal? If you do insist of having a full screen all the time, why are you using gnome-terminal at all?
I already use tmux. It doesn't solve the problem in the least.
> why do you insist of having a full screen all the time
Because I'm actively working in my terminal. Why should I waste space moving something somewhere else, especially away from where I'm looking?
> resize your terminal?
Maybe you like limiting the size of your workspace, but I don't.
> If you do insist of having a full screen all the time,
Because I'm not always in the terminal, but when I'm in the terminal, I don't see a reason to limit the space it uses.
Anyways, not you are being willfully ignorant. Rather than try and understand the problem, and how transparency was being used, you are being dismissive. You aren't trying to help in the least.
So, unless you want to take the time to understand the problem, why waste your time, and others, adding a comment that is essentially worthless?
> The thing is transparency didn't solve any problem. It was just a nerdiness thing.
Um, do they know their market? I doubt grandma is clammoring for transparency in her terminal windows but she's not the primary user profile for Gnome, you know?
Do you also fail to see a single use case for politeness? The ticket responder could have taken like ~2 minutes to explain the decision to remove it instead of being exceedingly rude.
I quite commonly use it when I want to see an application behind the terminal e.g. I might be editing code in vim whilst the application or browser window is open in the background.
Also, it just looks nice! By having an appropriate background image and playing with the opacity it has a negligible affect on readability.
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.
I agree with most of your points. Within one product there should not be too much choice. But choice between different products i.e. Linux distributions or operating systems is ok IMHO.
edit: I think the question is relevant, because part of what is going on here is that projects like Ubuntu and GNOME are taking cues from Apple's success
Depending on which metric you chose, either iOS or Android is ahead. However, the data is not conclusive enough to warrant your statement. If anything, it seems to be leaning in the opposite direction.
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.
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.
Side by side so I have less editing space? I have emacs and terminator split 5 or 6 ways and optionally fullscreened if needed. Being able to read documentation, cheat sheets, watch videos, live reload, and handle issues while not switching windows through my terminal is a giant productivity boost. Side-by-side just makes both parts less enjoyable, especially on a small laptop screen.
I do the same. I make notes on a web page, book or slide deck in emacs by setting transparency. If someone came along and removed it to just because of internal code changes I don't care about I would also be angrily posting on bug reports. http://justinsboringpage.blogspot.ca/2009/10/transparent-ema...
I do the same, and setting terminal transparency is usually the first change I make to a new box after importing my .emacs. With your terminal split at least 4 ways stuffing it over on one side of the screen is a non-starter. And even with multiple monitors, I find I can work faster if I can glance at the API docs without having to change my gaze, rather than having to find my place in code again each time I look away.
If you use a big screen your brain will be able to refocus faster when you look from one side to the screen to the other and back again when there are more recognizable patterns in the background.
With aterm (transparent only to backgrounds, not other windows) and an imagemagick script to shade backgrounds, I get to have pretty much any photo I want as a background, and it doesn't impact my work.
Only exception: astronomical photos with lots of stars. Very hard to resolve a white '.' character.
Shading script is short. Here it is for reference:
#!/bin/bash
# should set my background and darken the image for aterm
# imagemagick documentation here:
# http://www.imagemagick.org/script/command-line-options.php#fx
convert $@ -fx 'u/2.0' ~/.shadedbackground.jpg
fbsetbg -c ~/.shadedbackground.jpg
And, my aterm options:
aterm -tr -sl 10000 -fg white -bg black
Terminals that permit a dynamic view of obscured windows are also occasionally useful. For example - keeping an eye on small process-monitoring gui while continuing to code.
Are you sure you're aware of how it's implemented?
In a good terminal (e.g. konsole) the text remains fully opaque while only the background becomes transparent.
This is more difficult than simply setting a window-wide opacity, which is why the terminal must have its own support for it.
So you maintain the readability benefit while still being able to see major changes to the window behind the terminal if necessary (something which I have found occasionally useful).
Yes! I never understood having transparent terminals before, but one day I discovered that configuring a slight amount of transparency, together with the blur, can be really useful. The terminal still stays clear to read.
Not if it's done subtly (5-8% transparency) - if you've got multiple windows in a screen, it greatly enhances context in terms of what windows are where.
> I fail to see a single use case for terminal transparency. It makes text less readable.
I've always liked it for the ability to see/read documentation on a window behind the terminal. Specific use cases include referring to man pages, API docs and the like where I can't just copy+paste something and/or need to check config.conf against the settings/defaults in online docs.
It's especially useful on smaller screens where I don't have the luxury of having a 80-char wide terminal side-by-side with a browser window (and avoiding horizontal scrolling).
You want a user case? To read code, check API information or shortcuts through the window you're working in. My screen estate at work is severely limited. Also, it just looks better, and that matters, because I spend a lot of time in terminal windows.
I haven't been a Gnome user for many years though... Exactly for reasons like this. They have removed a few features too many. IIRC, last time I tried to log in with a Gnome session to see if anything had improved, I couldn't turn off cursor blinking in the terminal.
I've been using Linux since way before Gnome existed, and it does piss me off that (from the perspective of a power user) it's less usable now after all those years than it was in the first few years of its existence. Gnome turned on its own users long ago, and I think the year of the Linux desktop might be further now than ever, especially for the Gnome project in its current form. It's an illusion to attract new users if even the old ones don't want to use it anymore.
I wish the Gnome project good luck, but they are clearly sailing a different sea.
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?
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.
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.
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!
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.
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.
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.
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.
But I still think that accessing the data of other windows to draw a transparent background is a great deal of complexity for a terminal emulator -- AFAICT it means the terminal emulator has to be innately aware of the innards of the graphics system it's drawing to.
The app doesn't need to be aware of the content under the widget it wants to have an alpha value < 1.0. Its the job of the compositor to render the app's content as provided, regardless of what is over or under it, that is what it exists to do.
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.
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.
If you really want a feature, I agree with you. You shouldn't have to learn how to code to prevent a feature that many people are using from being removed.
Regardless, given the attitude shown in the bug, do you really believe if somebody provided a patch, it would be accepted? And do you really expect people to become core maintainers in every project they want features to not be removed from? That sounds ridiculous to me.
Gnome can decide whether to have a feature or not. But, as a very popular open source project, they should respect their users enough to gather their input and take it into consideration. At the very least, they should communicate well enough that users can make informed decisions before a feature is yanked from under them.
To be honest, I don't believe that if someone provided a patch, it would be accepted. I also don't "expect people to become core maintainers in every project they want features to not be removed from".
But I also believe it is crazy to believe that simply using a piece of free software gives you any right to dictate the feature set of that software.
One, the freedoms granted by free software include the right to modify and redistribute code. If you want to re-add a feature, fork the code. If the community sides with you, you will become the de-facto upstream.
Two, just because a user is vocal doesn't mean his/her incentives align with those of the developer. If the developer is working in his/her own time, he might prioritize things that are important to him, like, say, porting the terminal emulator to Wayland, or keeping only features s/he cares about. Or, perhaps the developer is being influenced by an external body or benevolent dictator.
I also find your "users can make informed decisions before a feature is yanked from under them" comment confusing. Presumably a user could always downgrade the package, or use source control to build an older version, if the missing feature is indeed mission-critical. If this risk is really unacceptable, they can make an informed decision to not upgrade, or to purchase a support contract.
It seems to me that the developer's communication skills are reasonably adequate, so I don't object to continuing to use gnome-terminal. I assume that the people who approved them becoming a developer would feel that way too.
> 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.
Why? so they can argue will fellow core devs?
> 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.
NOPE. Setting the transparency by compiz would make the whole window transparent, including the text, which makes the transparency useless. You need the background to be (semi) transparent, and the text to be fully opaque. This is a non-solution.
So they can be an active participant in the decision-making process. Right now, they're powerless -- like serfs or peasants.
> You need the background to be (semi) transparent, and the text to be fully opaque.
I will admit that I didn't notice this distinction before -- I found the transparency too visually distracting to leave it turned on. I'll admit I erred here.
That's like saying it's a rampant layering violation for a .png to have an alpha channel. It's the job of the layer to say what it covers and what it doesn't cover.
The impression I had the last time I used this feature wasn't that it used RGBA -- if that was all that it was, then I'd expect you'd be able to set a transparent background with a gconf value or something.
What I recall was that it would somehow grab the bitmap of the area behind the window, and then draw that partially transparent as part of its own background. The way you could tell this was happening was to use a asymmetric image (like, a flower or some landscape photo) and notice the background "sticking" as you drag the terminal window around.
It bothers me that you consider it reasonable for the gnome developers to not care about the gnome users because the users don't contribute code. The only reason software exists is to be used. Without users, gnome has no reason for existing. Without users gnome developers have no reason for contributing. As a developer i would never treat my users with that little respect, because they are literally the only reason my code has value.
It's perhaps telling that you believe the issue here is that the developers didn't say it nicely enough or have some authoritative rule to fall back on. Many developers and systems guys think like this.
The issue many developers have is not with language, it's interacting with other human beings. And the issue here is that the developers don't communicate with their user base. There is no public discussion, poll, or even a heads up. When a user asked about it, he was effectively told, "There will be no communication about this change."
Advising users, no matter how technical they are, to dig through system internals or devote the time and energy to become core contributors of Gnome so they can have the blessed power to ask that something they depend on not be removed for "maintainability" (really, someone's OCD sense of elegance) is actively hostile to those users.
There is no public discussion, poll, or even a heads up. When a user asked about it, he was effectively told, "There will be no communication about this change."
Although there is an IRC channel, a discussion mailing list, and mentioned elsewhere in this comments page, there was a poll of some sort. And half a dozen duplicate bug reports with comments already in bugzilla.
Advising users, no matter how technical they are, to dig through system internals or devote the time and energy to become core contributors of Gnome so they can have the blessed power to ask that something they depend on not be removed for "maintainability" (really, someone's OCD sense of elegance) is actively hostile to those users.
Stuff changes, you can't absolve yourself of the need to deal with it changing just by waving the 'user' or 'busy' cards. If you depend on a feature, don't just go moving entirely to a new version with no way to revert, without testing that the feature is still there. What if it was present, but had a bug and didn't work on your system? Would you go to the developers and demand they consult you before having bugs because you depend on it?
"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."
It can be reasonable to #if 0 a block of tricky code during a refactoring, just so that you can quickly cross the bridge to a working state. But removing it at that stage will make it impossible for the VCS to track changes to that piece of code, which makes it much harder to restore the functionality afterwards.
The RAID/LVM removal from Palimpsest followed a similar pattern (code deleted during a rewrite of an underlying library), but the developer was willing to work on reinstating it. Here we don't really know what Persch thinks — though damn the users is a tempting guess.
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.
By "talk" you mean the link to the "prefs redesign" bug, right? That bug was a good place to discuss which way the redesign would go, but Persch had already decided and made a branch to remove the code.
I might be naive about collaborative software development or the way gnome dev handle things but I think bugtrackers should be about bugs and technicalities, not feature approval or UX discussion if user feedback is wanted otherwise everything that a given user finds annoying would be considered a "bug" and drama would occurs.
This "talk" is more shocking in my opinion than the one that made the headline.
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.
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.
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.
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)
Well, the point I suppose is the person filing the issue thought it was a bug. Apparently the removal didn't make any release notes, so why believe otherwise?
The reason you have these discussions on the issue tracker is so when the next person comes along to file the issue, he/she now has the relevant context. Randomly guessing at which group to search and post to hardly helps in discovery. If you don't want discussion, disable the comments. But that's hardly conducive to good community teamwork.
And I'm really not aware of any project that only uses a "bug tracker." They almost all track issues, ranging anywhere from bugs to new feature requests. Maybe Gnome is different in this regard, but I don't think it's crazy for someone to believe otherwise. Redirecting conversation smacks of a "bugger off" mentality.
There’s no gnome-terminal mailing list. Since "bike shedding" is struck down with regularity on the bug tracker I wrote the guy directly before he made the commits.
I asked why he wants to remove the feature. He said it’s loosely connected to other features that are buggy and he doesn’t see the point of the feature anyhow. Whether I had a justification for the feature to stay.
I replied and gave him two good reasons, one of personal merit, one of technical merit.
Then nothing else.
Then I discovered that it indeed had been removed, while I was following git snapshots. So I checked the NEWS and Changelog, ReleaseNotes and git. No mention. Could’ve been temporary or unintentional.
So I wrote the guy again to ask what’s up. No reply. Then he replied with a non-answer only pointing to a FAQ entry he made the same day with a distracting workaround.
So I checked out git locally to see where the code went.
It turned out among unrelated commits where the code was #if 0’ed out only to be removed a few commits later with "delete dead code" etc.
So I wrote him again to ask why he did this. No reply.
So I downgraded to the known-good old version and waited for release time. Same story repeats with other people. Apparently nothing personal because of my tone.
So. Conspiracy or justified puzzlement about this behaviour?
Olav, there were eight bugs filed and no explanation. I came back to the bugs irregularly to see wether there was anything new in terms of explanation.
Then this trainwreck happened and people were asking questions.
So I thought it worthwhile to add what I knew. I don’t think I disclosed anything personal. It was strictly technical matters relevant to the bug at hand.
So why did you ban me with a false accusation?
If anything the "removing type-ahead search from nautilus" bug should’ve taught the lesson that an information campaign works better than outright censorship.
When that bug got attention Jon McCann came in, explained, and then made a full blog post[1] to expound the directions they were taking. I still didn’t like it but I was satisfied with the explanation.
Stop digging in and realize that just slightly amending your policies and interactions with users would fix everything.
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.
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.
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.
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.
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?
"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."
OK, can you point to a Web page where you explain the scope, expected use cases and intended audience of your work? (perhaps then just set up an auto-responder with a link to the page)
Of course you're always going to have a bunch of annoying people who feel entitled. However, this is not the case here: somebody reports a regression, in a helpful and polite way. "No" is not an appropriate justification, especially when it comes to such a widespread, widely used feature. I don't even understand how this would trigger such an emotional reaction wrt to removing a feature (presumably) he hasn't coded.
Gnome is not a throw-it-on-Github-and-see-if-it-sticks project. Development shouldn't happen in a vacuum, and antisocial behaviour shouldn't be the norm.
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.
Veteran users of Gnome will recall the screensaver kerfuffle. IIRC, that preceded these browsers somewhat. In fact, Chrome didn't even exist at that time.
Wasn’t Gnome 2 already an attempt to clean up/remove features that had cropped into Gnome 1? I recall ‘veteran users of Gnome’ complaining about the lack of settings/options back in 2005.
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.
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.
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)
The moment your settings screen would benefit from a search functionality, you should reconsider "doing it all".
Have you seen the "GodMode" hack in Windows 7? It's really a nice counterexample. Sometimes, verbose flat interfaces are just what the doctor/user ordered.
The first one is that it become fashonable to remove features, and this is not just an open source trend, instead of making softwre that fills a ninche, everybody is trying to build the same 10% of the features that 80% of the people use 90% of the time. (And let's forget that those other 10% of the time are still important for 100% of the people, ok?)
Another problem is that unless the user develops it, open source development is not user oriented... Well, proprietary software development isn't either, (only softwre developed in-house is really made for you) and both will cut costs in places you don't like sometimes.
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.
Come on, we are all developers here I want to think If I see a feature is just for aesthetic reasons with little purpose, then I could be considered as code sanitization, nobody really needs a transparent terminal, in the contrary, it may be contra productive.
I don't agree that aesthetic features have little purpose in a desktop application - they are a major part of the user experience. In this case the transparency feature is clearly something that a lot of people consider worth having.
Yes, they do - there are lots of them in this thread. Either you are not paying attention, or you are making assumptions of the validity of other peoples experience that you have no basis for.
Everything in life is not about productivity. But even if it was, the aesthetics of your environment does impact productivity. Personally I do continuously tweak the appearance of my environment because being relaxed and at ease makes a big difference to my concentration, which makes a big difference for how easily I get in the zone and is productive.
To presume that a feature that is "just for aesthetic reasons" has little purpose is arrogant and/or implies a lacking understanding of other developers.
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.
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?
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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 :)
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...
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.
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!
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.
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.
"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.
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?
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.
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.
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.
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.
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?
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.
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").
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.
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)
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.)
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.
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.
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).
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.
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.
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.
I agree. The Tron-esque modern UIs look like they come from some Android theme from XDA. Earlier Gnome revisions were good looking, with colour cues, and a sort of homogeneity.
"The linux desktop" is not a meaningful phrase. There are many and Gnome is no longer as widespread a default as it used to be.
"The competition" have just screwed the pooch with Win 8 as well. I'm not an Apple user so you'll have to tell me how they're doing.
So... no.
I personally use XFCE, which is fast, pretty, fairly lightweight and doesn't seem to want to force me to change how I work. In Xubuntu, or on debian with a bit of effort and a couple of themes installed, it's a good looking, slick interface. If you want a decent linux desktop experience it's worth a try.
On the Win 8 subject - needing 3rd party downloads to fix the borked desktop is very much screwing the pooch, especially when the vast majority of your users are entry level and have no idea what a desktop extension even is. The 8.1 climbdown is further evidence of cockup. Not to mention the serious analysis in the mainstream press suggesting that win 8 has actually depressed the pc market. So yeah.
The point is there is no single linux desktop and the OP seemed only to be talking about gnome.
On the Win 8 subject - needing 3rd party downloads to fix the borked desktop is very much screwing the pooch
Sure, but who cares? Apparently not enough people, because nobody is leaving. While their position is certainly precarious in other areas, Microsoft's dominance on the desktop is pretty hard to excuse away; it seems to me that they could have another three or four missteps of this magnitude and few people would consider leaving even then. Their primary competition is their own operating system, and that's a great place to be.
The point is there is no single linux desktop and the OP seemed only to be talking about gnome.
There's no "single Windows desktop", either; stuff like LiteStep has existed forever. But when people say "Windows", they don't mean LiteStep. Which isn't to say the usage numbers for non-GNOME/Unity DEs are that dire--from what I can see, they're fairly dire but not that dire--but for a majority of Linux users, GNOME and GNOME-y things are the Linux desktop.
Or, put another way: You knew what he meant. He knew what he meant. Does being That Guy help anything?
>> Sure, but who cares? Apparently not enough people, because nobody is leaving.
Did you read the part where the whole PC market is being depressed by Win 8?
Either way this conversation was not about numbers - linux people probably aren't leaving because gnome's changing either.
>> While their position is certainly precarious in other areas, Microsoft's dominance on the desktop is pretty hard to excuse away; it seems to me that they could have another three or four missteps of this magnitude and few people would consider leaving even then.
This is absolutely nothing to do with the conversation at hand or the point I was trying to make! Of course they're not going to lose dominance anytime soon, you'd have to be a moron to think otherwise! The fact is that they've made missteps that negatively affect the desktop experience compared to previous iterations, that's the beginning and end of it!
>> There's no "single Windows desktop", either
Umm, yeah, there's the one Microsoft ship and don't really allow you to change very much, or. That is the windows desktop. That you can over-install third party bits and pieces is not really the same thing as the myriad of different desktop environments in Linux.
>> for a majority of Linux users, GNOME and GNOME-y things are the Linux desktop.
And I'd be surprised if that continues, and it still doesn't mean there's a single linux desktop, nor that talking about 'the ui' and then referencing Gnome icons is particularly useful.
>> Or, put another way: You knew what he meant. He knew what he meant.
Yeah, I know he meant Gnome, because that's all he talks about. If he did mean the umbrella term then it's not meaningful to talk about whether a highly disparate set of projects have got worse.
>> Does being That Guy help anything?
I don't know, why do you feel the need to be that guy and argue against a whole bunch of stuff I didn't even say?
I agree regarding the trajectory of the KDE and GNOME projects, but XFCE has made huge strides in the past five years and stands as a great model of evolutionary rather than revolutionary development (to borrow from Nimzowitsch's vocabulary). It is a very usable, attractive desktop environment. It even has a QuickSilver-like tool built-in these days (Alt-F3).
Part of the problem, I think, is that projects like Gnome don't seem to have clear goals, targets or ambitions.
In the beginning, Linux desktops were incomplete, but they were thriving, developers all keen to add new stuff and catch up with Windows/Mac. And naturally, most of it ended up as almost-copies of other OS's functionality, but with plenty of unique stuff in there too.
But then, the desktops slowly became closer and closer to 'feature complete'. So where do you go from there? It seems to me that Gnome has become a 'change for the sake of change' project. Maintaining and making incremental improvements to a desktop isn't that interesting for developers, I guess. So they strike out in all different directions, at the expense of existing users. But there doesn't seem to be any goal any longer in what they are doing. Certainly I can't find anything obvious on their website!
I personally feel all this "usability nightmare" started with Ubuntu Unity and GNOME 3. I'd suggest you to check out MATE (a fork of GNOME 2) and Cinnamon desktop environments.
---
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?
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.
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.
"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.
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].
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.
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.
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.
> 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.
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.
312 comments
[ 2.8 ms ] story [ 301 ms ] thread(Personally, I do leave my XFCE4 desktop on default settings, but I do alter defaults in some packages)
The person in the link commenting "PUT IT BACK EVERY OTHER TERMINAL EMULATOR HAS IT" is more baffling.
Both wanting choice and options, but at the same time not wanting to have to change when there are other options.
Gnome Terminal may (effectively) be the only terminal emulator available to you if you do not have rights to install software or to change default software.
Then yes, they should.
If the boss gives you lemons, you don't go to the lemon tree and ask if it can make lemons that read email, browse NFS shares and change screensaver settings. You go to your boss and say "just-lemons isn't good enough".
However, "choice is poison" is a rather extreme over-compensation for this problem. Sometimes, options really do provide value. And many times, if they are designed correctly, they don't substantially increase cost; if the features are orthogonal and implemented independently, the additional complexity is only linear with the number of features, not quadratic or worse as happens if they are too interrelated.
I understand that we want to get away from the "you need to spend hours customizing your environment to make it usable" approach to design that plagues some open source project, but going to the other extreme and saying that "choice is poison" is just as bad.
I'd rather have something that was well thought through and is internally consistant than a grab-bag of customisation, none of which coexists well - like most linux desktops.
That's should always be second to providing solutions. Solve the problems that transparency solved first. If you aren't aware of the problems that transparency in terminals provided, then removing it is purely an act of ignorance.
1) Have you searched the literature on perceptual defects and enablement? If so I'd love to see references.
2) Have you consulted widely on mailing lists that Gnome Terminal users use and checked use cases? If so, can you link to those? I'd like to see them.
> How can I use a full screen terminal window and still read documentation in that same screen?
I've asked this question. I've yet to see a reply.
If your documentation isn't viewable in terminal, why do you insist of having a full screen all the time - resize your terminal? If you do insist of having a full screen all the time, why are you using gnome-terminal at all?
> why do you insist of having a full screen all the time
Because I'm actively working in my terminal. Why should I waste space moving something somewhere else, especially away from where I'm looking?
> resize your terminal?
Maybe you like limiting the size of your workspace, but I don't.
> If you do insist of having a full screen all the time,
Because I'm not always in the terminal, but when I'm in the terminal, I don't see a reason to limit the space it uses.
Anyways, not you are being willfully ignorant. Rather than try and understand the problem, and how transparency was being used, you are being dismissive. You aren't trying to help in the least.
So, unless you want to take the time to understand the problem, why waste your time, and others, adding a comment that is essentially worthless?
Um, do they know their market? I doubt grandma is clammoring for transparency in her terminal windows but she's not the primary user profile for Gnome, you know?
I suspect the issue at hand is the removal of a feature that was available previously without explicit discussion or explanation.
Also, it just looks nice! By having an appropriate background image and playing with the opacity it has a negligible affect on readability.
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.
edit: I think the question is relevant, because part of what is going on here is that projects like Ubuntu and GNOME are taking cues from Apple's success
Like apple did with the iphone?
http://techland.time.com/2013/04/16/ios-vs-android/
Depending on which metric you chose, either iOS or Android is ahead. However, the data is not conclusive enough to warrant your statement. If anything, it seems to be leaning in the opposite direction.
http://www.jdpower.com/content/press-release/upO8vjP/2012-u-...
Go KDE.
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.
RTFA it does not make text less readable: https://bug698544.bugzilla-attachments.gnome.org/attachment....
Drag the windows side by side with the snap feature.
> RTFA it does not make text less readable
The text would be more readable with an opaque background.
With aterm (transparent only to backgrounds, not other windows) and an imagemagick script to shade backgrounds, I get to have pretty much any photo I want as a background, and it doesn't impact my work.
Only exception: astronomical photos with lots of stars. Very hard to resolve a white '.' character.
Shading script is short. Here it is for reference:
And, my aterm options: Terminals that permit a dynamic view of obscured windows are also occasionally useful. For example - keeping an eye on small process-monitoring gui while continuing to code.In a good terminal (e.g. konsole) the text remains fully opaque while only the background becomes transparent.
This is more difficult than simply setting a window-wide opacity, which is why the terminal must have its own support for it.
So you maintain the readability benefit while still being able to see major changes to the window behind the terminal if necessary (something which I have found occasionally useful).
I've always liked it for the ability to see/read documentation on a window behind the terminal. Specific use cases include referring to man pages, API docs and the like where I can't just copy+paste something and/or need to check config.conf against the settings/defaults in online docs.
It's especially useful on smaller screens where I don't have the luxury of having a 80-char wide terminal side-by-side with a browser window (and avoiding horizontal scrolling).
I haven't been a Gnome user for many years though... Exactly for reasons like this. They have removed a few features too many. IIRC, last time I tried to log in with a Gnome session to see if anything had improved, I couldn't turn off cursor blinking in the terminal.
I've been using Linux since way before Gnome existed, and it does piss me off that (from the perspective of a power user) it's less usable now after all those years than it was in the first few years of its existence. Gnome turned on its own users long ago, and I think the year of the Linux desktop might be further now than ever, especially for the Gnome project in its current form. It's an illusion to attract new users if even the old ones don't want to use it anymore.
I wish the Gnome project good luck, but they are clearly sailing a different sea.
I hate it when my development environment gets screwed with.
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!
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.
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.
I see no "rampant layering violation" here as the goal is not a transparent window, but rather a transparent background, big difference.
But I still think that accessing the data of other windows to draw a transparent background is a great deal of complexity for a terminal emulator -- AFAICT it means the terminal emulator has to be innately aware of the innards of the graphics system it's drawing to.
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.
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.
Regardless, given the attitude shown in the bug, do you really believe if somebody provided a patch, it would be accepted? And do you really expect people to become core maintainers in every project they want features to not be removed from? That sounds ridiculous to me.
Gnome can decide whether to have a feature or not. But, as a very popular open source project, they should respect their users enough to gather their input and take it into consideration. At the very least, they should communicate well enough that users can make informed decisions before a feature is yanked from under them.
But I also believe it is crazy to believe that simply using a piece of free software gives you any right to dictate the feature set of that software.
One, the freedoms granted by free software include the right to modify and redistribute code. If you want to re-add a feature, fork the code. If the community sides with you, you will become the de-facto upstream.
Two, just because a user is vocal doesn't mean his/her incentives align with those of the developer. If the developer is working in his/her own time, he might prioritize things that are important to him, like, say, porting the terminal emulator to Wayland, or keeping only features s/he cares about. Or, perhaps the developer is being influenced by an external body or benevolent dictator.
I also find your "users can make informed decisions before a feature is yanked from under them" comment confusing. Presumably a user could always downgrade the package, or use source control to build an older version, if the missing feature is indeed mission-critical. If this risk is really unacceptable, they can make an informed decision to not upgrade, or to purchase a support contract.
It seems to me that the developer's communication skills are reasonably adequate, so I don't object to continuing to use gnome-terminal. I assume that the people who approved them becoming a developer would feel that way too.
Why? so they can argue will fellow core devs?
> 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.
NOPE. Setting the transparency by compiz would make the whole window transparent, including the text, which makes the transparency useless. You need the background to be (semi) transparent, and the text to be fully opaque. This is a non-solution.
So they can be an active participant in the decision-making process. Right now, they're powerless -- like serfs or peasants.
> You need the background to be (semi) transparent, and the text to be fully opaque.
I will admit that I didn't notice this distinction before -- I found the transparency too visually distracting to leave it turned on. I'll admit I erred here.
What I recall was that it would somehow grab the bitmap of the area behind the window, and then draw that partially transparent as part of its own background. The way you could tell this was happening was to use a asymmetric image (like, a flower or some landscape photo) and notice the background "sticking" as you drag the terminal window around.
The issue many developers have is not with language, it's interacting with other human beings. And the issue here is that the developers don't communicate with their user base. There is no public discussion, poll, or even a heads up. When a user asked about it, he was effectively told, "There will be no communication about this change."
Advising users, no matter how technical they are, to dig through system internals or devote the time and energy to become core contributors of Gnome so they can have the blessed power to ask that something they depend on not be removed for "maintainability" (really, someone's OCD sense of elegance) is actively hostile to those users.
Although there is an IRC channel, a discussion mailing list, and mentioned elsewhere in this comments page, there was a poll of some sort. And half a dozen duplicate bug reports with comments already in bugzilla.
Advising users, no matter how technical they are, to dig through system internals or devote the time and energy to become core contributors of Gnome so they can have the blessed power to ask that something they depend on not be removed for "maintainability" (really, someone's OCD sense of elegance) is actively hostile to those users.
Stuff changes, you can't absolve yourself of the need to deal with it changing just by waving the 'user' or 'busy' cards. If you depend on a feature, don't just go moving entirely to a new version with no way to revert, without testing that the feature is still there. What if it was present, but had a bug and didn't work on your system? Would you go to the developers and demand they consult you before having bugs because you depend on it?
As chris_wot said,
> Your "informal poll" evidently didn't include the userbase.
"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."
The RAID/LVM removal from Palimpsest followed a similar pattern (code deleted during a rewrite of an underlying library), but the developer was willing to work on reinstating it. Here we don't really know what Persch thinks — though damn the users is a tempting guess.
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.
I might be naive about collaborative software development or the way gnome dev handle things but I think bugtrackers should be about bugs and technicalities, not feature approval or UX discussion if user feedback is wanted otherwise everything that a given user finds annoying would be considered a "bug" and drama would occurs.
This "talk" is more shocking in my opinion than the one that made the headline.
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.
Do users post to the firefox bug tracker when features are removed like in the gnome case ? How is it handled ?
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/
Yes, the original answer is "just" missing the link. As is also the answer to the why comment.
The reason you have these discussions on the issue tracker is so when the next person comes along to file the issue, he/she now has the relevant context. Randomly guessing at which group to search and post to hardly helps in discovery. If you don't want discussion, disable the comments. But that's hardly conducive to good community teamwork.
And I'm really not aware of any project that only uses a "bug tracker." They almost all track issues, ranging anywhere from bugs to new feature requests. Maybe Gnome is different in this regard, but I don't think it's crazy for someone to believe otherwise. Redirecting conversation smacks of a "bugger off" mentality.
I asked why he wants to remove the feature. He said it’s loosely connected to other features that are buggy and he doesn’t see the point of the feature anyhow. Whether I had a justification for the feature to stay.
I replied and gave him two good reasons, one of personal merit, one of technical merit.
Then nothing else.
Then I discovered that it indeed had been removed, while I was following git snapshots. So I checked the NEWS and Changelog, ReleaseNotes and git. No mention. Could’ve been temporary or unintentional.
So I wrote the guy again to ask what’s up. No reply. Then he replied with a non-answer only pointing to a FAQ entry he made the same day with a distracting workaround.
So I checked out git locally to see where the code went.
It turned out among unrelated commits where the code was #if 0’ed out only to be removed a few commits later with "delete dead code" etc.
So I wrote him again to ask why he did this. No reply.
So I downgraded to the known-good old version and waited for release time. Same story repeats with other people. Apparently nothing personal because of my tone.
So. Conspiracy or justified puzzlement about this behaviour?
Then this trainwreck happened and people were asking questions.
So I thought it worthwhile to add what I knew. I don’t think I disclosed anything personal. It was strictly technical matters relevant to the bug at hand.
So why did you ban me with a false accusation?
If anything the "removing type-ahead search from nautilus" bug should’ve taught the lesson that an information campaign works better than outright censorship.
When that bug got attention Jon McCann came in, explained, and then made a full blog post[1] to expound the directions they were taking. I still didn’t like it but I was satisfied with the explanation.
Stop digging in and realize that just slightly amending your policies and interactions with users would fix everything.
[1] http://blogs.gnome.org/mccann/2012/08/01/cross-cut/
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.
Open sourcing it does not mean that other people are entitled to control it.
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?
Well, thankyou for your work.
"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."
OK, can you point to a Web page where you explain the scope, expected use cases and intended audience of your work? (perhaps then just set up an auto-responder with a link to the page)
Gnome is not a throw-it-on-Github-and-see-if-it-sticks project. Development shouldn't happen in a vacuum, and antisocial behaviour shouldn't be the norm.
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.
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.
Have you seen the "GodMode" hack in Windows 7? It's really a nice counterexample. Sometimes, verbose flat interfaces are just what the doctor/user ordered.
The first one is that it become fashonable to remove features, and this is not just an open source trend, instead of making softwre that fills a ninche, everybody is trying to build the same 10% of the features that 80% of the people use 90% of the time. (And let's forget that those other 10% of the time are still important for 100% of the people, ok?)
Another problem is that unless the user develops it, open source development is not user oriented... Well, proprietary software development isn't either, (only softwre developed in-house is really made for you) and both will cut costs in places you don't like sometimes.
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.
Second, this is open source, hack it.
Also, in the case of a feature being removed I feel that the onus is on the remover to make the case for why it should go.
To presume that a feature that is "just for aesthetic reasons" has little purpose is arrogant and/or implies a lacking understanding of other developers.
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.
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?
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.
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.
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.
"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.
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.
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.
I have to learn more about KDE -> Gnome, since I remember it was the other way around :)
hmmm
here's the link: https://www.youtube.com/watch?v=4XpnKHJAok8
[1] http://en.wikipedia.org/wiki/Bitkeeper#Pricing_change
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!
http://www.quora.com/What-are-some-well-written-accounts-of-...
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.
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.
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.
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.
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.
Am I really defending the GNOME project now? ó.Ò
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.
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.
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?
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.
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)
Their attitude makes me want to switch to another desktop even more so that the software itself.
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.)
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.
Gnome is quickly making themselves obsolete.
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.
For example, I'm using the Trinity version of KDE 3.5. Works great for me.
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.
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.
"The competition" have just screwed the pooch with Win 8 as well. I'm not an Apple user so you'll have to tell me how they're doing.
So... no.
I personally use XFCE, which is fast, pretty, fairly lightweight and doesn't seem to want to force me to change how I work. In Xubuntu, or on debian with a bit of effort and a couple of themes installed, it's a good looking, slick interface. If you want a decent linux desktop experience it's worth a try.
Sure it is. It's an umbrella term for Gnome, KDE, etc.
> "The competition" have just screwed the pooch with Win 8 as well.
Nah. Not enough that people are leaving it in great numbers. People who want a Windows 7 experience download Pokki or Start8.
> I'm not an Apple user so you'll have to tell me how they're doing.
As a Mac user, I'm perfectly happy with Mac OS X, out of the box. Haven't upgraded to Mountain Lion yet, though.
The point is there is no single linux desktop and the OP seemed only to be talking about gnome.
Sure, but who cares? Apparently not enough people, because nobody is leaving. While their position is certainly precarious in other areas, Microsoft's dominance on the desktop is pretty hard to excuse away; it seems to me that they could have another three or four missteps of this magnitude and few people would consider leaving even then. Their primary competition is their own operating system, and that's a great place to be.
The point is there is no single linux desktop and the OP seemed only to be talking about gnome.
There's no "single Windows desktop", either; stuff like LiteStep has existed forever. But when people say "Windows", they don't mean LiteStep. Which isn't to say the usage numbers for non-GNOME/Unity DEs are that dire--from what I can see, they're fairly dire but not that dire--but for a majority of Linux users, GNOME and GNOME-y things are the Linux desktop.
Or, put another way: You knew what he meant. He knew what he meant. Does being That Guy help anything?
Did you read the part where the whole PC market is being depressed by Win 8? Either way this conversation was not about numbers - linux people probably aren't leaving because gnome's changing either.
>> While their position is certainly precarious in other areas, Microsoft's dominance on the desktop is pretty hard to excuse away; it seems to me that they could have another three or four missteps of this magnitude and few people would consider leaving even then.
This is absolutely nothing to do with the conversation at hand or the point I was trying to make! Of course they're not going to lose dominance anytime soon, you'd have to be a moron to think otherwise! The fact is that they've made missteps that negatively affect the desktop experience compared to previous iterations, that's the beginning and end of it!
>> There's no "single Windows desktop", either
Umm, yeah, there's the one Microsoft ship and don't really allow you to change very much, or. That is the windows desktop. That you can over-install third party bits and pieces is not really the same thing as the myriad of different desktop environments in Linux.
>> for a majority of Linux users, GNOME and GNOME-y things are the Linux desktop.
And I'd be surprised if that continues, and it still doesn't mean there's a single linux desktop, nor that talking about 'the ui' and then referencing Gnome icons is particularly useful.
>> Or, put another way: You knew what he meant. He knew what he meant.
Yeah, I know he meant Gnome, because that's all he talks about. If he did mean the umbrella term then it's not meaningful to talk about whether a highly disparate set of projects have got worse.
>> Does being That Guy help anything?
I don't know, why do you feel the need to be that guy and argue against a whole bunch of stuff I didn't even say?
In the beginning, Linux desktops were incomplete, but they were thriving, developers all keen to add new stuff and catch up with Windows/Mac. And naturally, most of it ended up as almost-copies of other OS's functionality, but with plenty of unique stuff in there too.
But then, the desktops slowly became closer and closer to 'feature complete'. So where do you go from there? It seems to me that Gnome has become a 'change for the sake of change' project. Maintaining and making incremental improvements to a desktop isn't that interesting for developers, I guess. So they strike out in all different directions, at the expense of existing users. But there doesn't seem to be any goal any longer in what they are doing. Certainly I can't find anything obvious on their website!
--- 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?
This is why in Gnome, all tab bars are on top, including in the terminal. Consistency for the sake of consistency.
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.
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.
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.
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.
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.
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.
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.
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.