Gnome Terminal restriction

I have often wondered why Gnome Terminal select all only selects the visible portion. This requires a workaround or a series of them that are often difficult to walk users through.

Well... I was looking into it and found this gem of a post:

Buddy, I feel ya.

I did wonder about that myself as well as I use Tilix which is based on Gnome Terminal. Luckily is not one of those features that I use frequently.

You may find "Black Box" more interesting. I'm not sure if it's meant to be a replacement for Gnome Terminal sometime in the future but it appeared on the "This week on Gnome" so it may be just that. If only it had the ability to split the view into multiple panes like Tilix...

PS: I checked for contributions from Chris Persch to this project in case you're wondering. There are none :smiley:

1 Like

In that thread, user rnturn typed a reply.

Wow.

You could always track down the sources for pre "select-screen-only" gnome-terminal and compile it for your system. Just a thought.

Just sayin'

I am going to address this here. I do not care to join a different forum just to pick a fight. But it is well worth publicly acknowledging this.

In a large part due to this being a common response to user feedback in Linux as a whole, even employed by Tobias Bernard when responding to complaints about Gnome feature removals.

Here are the Two Premises:

  • That the user could Select a Different Package, rather than giving feedback about the current package.
  • That the user could fork the package and write it the manner that they like. That's the beauty of FOSS.

Ok, on the surface these both seem reasonable and they both seem truthful.

But here are the Major Problems with this approach:

  • It shifts blame. It removes the responsibility of the Maintainer of a project and dumps it onto the user.
  • It places an absolutely overwhelming expectation onto the users.

The first point is clear and easily understood. So, let's focus on the second. By being a maintainer, that individual is undertaking a Specialized task, which conforms to modern society. Since individuals cannot have all-encompassing knowledge, tasks are divided into manageable specialties. For example, doctors might specialize in ENT (Ears, nose throat) or G.I. (Gastro-intestinal) or Cardio Vascular...
The maintainer of a project needs only be responsible for the coding needed for that project.

But to take that responsibility and dump it on the user places the expectation that this user must know and ably manage many different coding languages. They must be willing to learn all specialized knowledge needed for every app maintained by someone else that needs a bug fix, a feature, an improvement...
If a user reports a bug, missing feature or improvement idea, this behavior then expects the user to specialize in each and every app that they report on instead only adhering to their own specialty (much less balancing their specialty in their own time).

There is no way that kind of response can be positively received. The user might feel brushed off or they may feel that they are incompetent or inept since they cannot do superhuman feats.
This is not a good answer to a report.
Closing the report to further replies silences the users (upon whom such overwhelming expectations were placed on) to prevent the furtherance of feedback is not a good answer.
Shifting the responsibility as maintainer to everyone else is not a good answer.


I use the XFCE Terminal in Zorin OS Lite, so I do not have to personally deal with this bug. In the xfce4-terminal, select all selects all of the output on the terminal window.

2 Likes

Absolutely, and even if the possibility of taking the code and compiling is always there it should also be made simple and straightforward. I will use an example I've just run into myself:

I wanted to download this program: Contrast from the Software Store. It's only available as a flatpak so I used that option, but then I noticed that while the website states a download size of 1Mb, the reality was a bit different:

sc1

I only noticed this because the download was taking forever (must be nice to have top-notch internet I guess). So I canceled the download and went to the project's repository I linked above, thinking that if it's really only a few MB of installed size it must be really easy to compile so I'll just do it myself.
Unfortunately, there were no instructions on how to build the project at all. The only option I found was to download Builder which, as far as I can tell, it only produces flatpaks.

I had to go back and wait for the whole download for a really simple application. On top of that, being a Flatpak, the built-in color picker didn't work so I had to manually copy over the color codes I wanted to compare... Obviously none of this is the end of the world, but it just feels like such a waste of time and bandwidth.

Btw, and I don't mean to ruin your day but have you seen this yet? :smiley:

Yes. I am very familiar with that and have made a great deal of commentary on it- and the impetus behind it, many times. It is not about what they claim it is. It is about Brand Image Control.
From the link:

GTK Stylesheets can make applications look broken, and even unusable.

This is utterly untrue. The gtk.css stylesheets deal with styling only. They do not break apps. This misleading statement is worded in such a way as to agitate, rather than convey information.

Icon Themes can change icon metaphors, leading to interfaces with icons that don’t express what the developer intended.
App Icons are the identity of an app. Changing an app’s icon denies the developer the possibility to control their brand.

And these points openly admit that it actually is about Brand Image Control.

Interestingly, the Gnome Foundation has been for years expressing distaste over themers "undermining" Gnomes brand image. In fact, Gnome Devs got so caught up in it, that with each point release of gtk3, they changed the API calls in order to break themes, since their own Adwaita could be modified immediately to match their new gtk version as they release it, by themselves as the Adwaita devs.
By gtk3.20, they had created so much anger within the Linux Community with this behavior, the Stakeholders for Gnome made Gnome sign a pledge to stop breaking themes.
Gnome did honor this pledge (more or less)... But with the intro of GTK4, they locked theming again by developing and introducing libAdwaita, thereby dodging the pledge they had signed with a workaround. Persistent, aren't they?

So, if you scroll to the bottom of your link, you will easily notice that the majority of signors to the "Open Letter to Gnome" are... Gnome Devs.
And they realize that will look bad (Because it actually is what it looks like!), they add a disclaimer that says:
"Ok, yeah we're a bunch of Gnome Devs but we say this as individuals and not on behalf Of Gnome or anything...." As if that somehow makes it different!
They develop for Gnome and wrote a letter to themselves asking to stop theming their apps. Then published it for other people to see and think that independent devs were asking Gnome devs to put an end to theming.

These guys don't think much of our intellect, do they?


Signor:

Reality:
https://blogs.gnome.org/tbernard/

Tobias Bernard, a member of the GNOME Foundation, talks about theming

"Among others", huh?

You are most definitely not alone:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.