Comment by columbo | Hacker News Reader

Comment by columbo | Hacker News Reader

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.

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?

> there was a poll of some sort

As chris_wot said,

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

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.

That is not a valid workaround as it applies transparency to the text as well, not just the background.

I see no "rampant layering violation" here as the goal is not a transparent window, but rather a transparent background, big difference.

Hm, I see your point.

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.

I would argue your solution is exactly backwards.

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

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

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

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.

> Why? so they can argue will fellow core devs?

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.

That might be a fallback mode, but if it's the only mode then yes it's a problem but simply removing it isn't a very good solution.

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 bothers me that you think the opinion of the people in the original bug report is representative of all users.

Reply on news.ycombinator.com