Hacker News Reader

Comment by cbhl | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

Reply on news.ycombinator.com