4 ms·

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 h

by cbhl 14y ago

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.

mbell 14y ago
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.
- cbhl 14y ago
  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.
  - mbell 14y ago
    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.
vault_ 14y ago
I would argue your solution is exactly backwards. The job of the compositor is to draw a window how it asks to be drawn. The window in question is extending that choice to the user: "how do you want me to look." It then tells the compositor to draw it in that fashion. I would argue that this is the correct place for this choice. If you use the compositor to control transparency, what you have is the window asking to be drawn in a certain way and the compositor saying "Eh, you'd look way better at 50% opacity". If it's the user controlling this it's even worse. Now they have to be able to write a regular expression on certain window classes for each application they want to modify, and have far less granularity in how the window is modified. The compositor exists to faithfully draw windows and place them on the screen according to what is requested. Only in exceptional cases should it be asked to do weird things with certain windows.
- cbhl 14y ago
  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.
deleted 14y ago
[deleted]
SoftwareMaven 14y ago
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.
- cbhl 14y ago
  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.
gabipurcaru 14y ago
> 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.
- cbhl 14y ago
  > 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.
Dylan16807 14y ago
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.
- cbhl 14y ago
  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.
  - Dylan16807 14y ago
    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.
Joeri 14y ago
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.
- cbhl 14y ago
  It bothers me that you think the opinion of the people in the original bug report is representative of all users.

by cbhl 14y ago

mbell 14y ago

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.

cbhl 14y ago
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.
- mbell 14y ago
  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.

vault_ 14y ago

I would argue your solution is exactly backwards. The job of the compositor is to draw a window how it asks to be drawn. The window in question is extending that choice to the user: "how do you want me to look." It then tells the compositor to draw it in that fashion. I would argue that this is the correct place for this choice. If you use the compositor to control transparency, what you have is the window asking to be drawn in a certain way and the compositor saying "Eh, you'd look way better at 50% opacity". If it's the user controlling this it's even worse. Now they have to be able to write a regular expression on certain window classes for each application they want to modify, and have far less granularity in how the window is modified. The compositor exists to faithfully draw windows and place them on the screen according to what is requested. Only in exceptional cases should it be asked to do weird things with certain windows.

cbhl 14y ago
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.

deleted 14y ago

[deleted]

SoftwareMaven 14y ago

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.

cbhl 14y ago
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.

gabipurcaru 14y ago

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

cbhl 14y ago
> 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.

Dylan16807 14y ago

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.

cbhl 14y ago
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.
- Dylan16807 14y ago
  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.

Joeri 14y ago

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.

cbhl 14y ago
It bothers me that you think the opinion of the people in the original bug report is representative of all users.