GNOME Bugzilla – Bug 335453
Close buttons take up a lot of space and are easy to click by accident when selecting tabs
Last modified: 2021-06-10 16:30:10 UTC
If you have more than a few tabs open the close buttons get in the way. First of all their presence truncates the tab titles thus making it harder to identify a particular tab by name. Given g-t's use of horizontal tabs the space is tight to begin with. Also, the close buttons are extremely easy to hit by accident when clicking to select causing the tab to be closed without further notice. This behaviour assumes that individual tabs are disposable and often that's not the case. By comparison - say - gedit will ask the user for confirmation before closing a tab to avoid losing data. For readability reasons I'd like to see the close buttons become a preference. At the very minimum a requester should ask to confirm closure. That goes for the Close Tab option in the menu too...
Agreed, the close button should be a preference option, but if confirm-close behaviour is added, it too should be optional.
The idea since the beginning has been to realize whether what's running inside the terminal is a shell or not, and then be able to determine whether it should be closed without bothering the user or it should ask whether to actually close. It's not trivial, though, and I haven't had time to come up with code for that. Patches welcome :)
I agree that the close tab buttons should be optional. They add clutter (IMO) and are too easy to click on accidentally.
I also agree - I have no problem with them as a configurable option (although I'd prefer them to not be there by default), but the chances for error are too great with them on, in my opinion.
Ditto. It'd be nice to see it implemented like the close button in FireFox 1.5 - a single close button on the far right. 'Close buttons on tabs' is a fundamentally bad UI paradigm due to it leading to significant user error.
How about implementing a close button that just sends a ctrl+d. If that doesn't terminate the shell, it should ask for confirmation?
Instead of yet another preference, just show the close button on the active tab. That way, when a user clicks another tab there is no danger of accidentally closing it. We're forcing the user to see the contents of the tab before closing it, which I think is a good idea, and we save the user from another confirmation dialog from hell.
Correct me if I'm wrong, but it appears that the notebook object in gtk+ used by gnome-terminal doesn't allow a FireFox style close button. As such, I don't think going the FireFox route (which I also think would be a good idea) would be an option without a custom built notebook, unfortunately.
*** Bug 341074 has been marked as a duplicate of this bug. ***
Duarte Henriques said: > Instead of yet another preference, just show the close button on the active > tab. That way, when a user clicks another tab there is no danger of accidentally > closing it. No, the danger is still there as long as the close button is there. All it takes is a slight positioning inaccuracy when trying to select the neighbouring tab, or an accidental double instead of single click. These things happen and are the reason why I despise single-click close buttons in all their forms, but *especially* right in the middle of a tab bar where I have to click regularly, and *double especially* for a bloomin TERMINAL where in most cases it's not desirable to close if an application is running, and if you're at a shell prompt you can just use ctrl-D! *Please* make this a user preference. Some of us value the contents of our terminals too much to risk killing them with a misplaced click.
Btw a while ago I reported this as Debian bug #362156, but it looks like the maintainer of that package isn't currently active in forwarding to upstream.
The person effectively maintaining gnome-terminal for Debian nowadays am I, so it doesn't really matter... heheh
*** Bug 346789 has been marked as a duplicate of this bug. ***
This is a copy of the comments I made in duplicate bug 346789. It is very easy to accidentally close a tab by clicking on the tab's close button when switching tabs. There are several ways that this could be dealt with, 1) an option to disable or remove the close button on the tab 2) enable/display the button only on current tab Option (2) would be best, which would force the user to switch to the tab to be closed bfore the button would be activated. This would mimic the behaviour of the keyboard shortcut Shift-Ctrl-W or the menu item "File/Close Tab". FWIW, I agree with the other commenters that a prompt to close should be an option. My feeling is that the implementation would be perfect, if the close button were only displayed on the current tab, and that a prompt to close were used to prevent accidentally closing the tab. There should NOT be a close button on non-active tabs!
Created attachment 69436 [details] [review] patch to remove close buttons Here's an example patch (rather trivial) to remove the close buttons from the tab. Now if someone with some experience in adding config items in gconf could replace the if (close_button_on_tab) lines with something more appropriate, I think we're about there. The patch appears to work fine, I'll be using the patched version until a proper fix is accepted by the maintainer.
If this should be an option it seems like it should be a global thing that applies to e.g. tabbed browser, tabbed gedit, etc. as well. Though I'm 99% positive this pref is a classic example of a broken workaround; if the close button is too easy to hit and loses data, one could (radical thought here) fix that properly in various ways (all admittedly requiring more thought and coding than just adding a pref does) instead of requiring people to "unbreak" their terminal via prefs dialog prior to using it. If the close button is truly a problem, simply not having the close button would be better than a pref even. There is after all a close menu item and key shortcut.
Yup, this pref is basically a --do-not-be-broken option. Is the intention to add UI for this?
Are there plans to change the tab code in gtk+ to behave more like firefox? I mean if people are happy with how it's handled in FF which is one of the apps most people use all the time it should be more than good enough for use in a terminal or other apps.
I think Firefox is changing in 2.0 to have the close button on each tab? I seem to remember reading that...
In FF 2.0RC3, each tab has its own close button (but the tabs will not shrink indefinitely...)
It's just as annoying in Firefox, but a bit easier to recover from since you can reload the page (though it doesn't help if you were deep into some AJAX app). Confirmation is less of an issue with most GUI apps because the logic is to ask for confirmation if there are unsaved changes. Trouble is: gnome-terminal doesn't really know what "unsaved changes" means for the processes it's displaying (or even if the concept has any meaning). I'd suggest: - Confirmation is always on for usual methods of closing tabs (and, by implication, windows) by default. - For the "power user", provide (a) a configurable no-confirmation close keyboard shortcut, and (b) a preference to globally turn off the confirmation dialog for gnome-terminal. Bonus points for making confirmation override a per-profile setting :)
(In reply to comment #21) > It's just as annoying in Firefox, but a bit easier to recover from since you > can reload the page (though it doesn't help if you were deep into some AJAX > app). And firefox has the sense to add an option in it's about:config page that allows me to disable the close buttons on the inactive tabs, although the remaining close buttin is still on the active tab instead of safely tucked to the side as it was before. Although I agree with Havoc Pennington (comment #16) that the option is a case of a broken workaround (or the --do-not-be-broken option), I have to say that the time this is taking to get fixed is getting rather ridiculous. Either decide that the feature is broken and remove it again (file->close and control-w work fine), or add the option, please. In the mean time I've switched to xfce4-terminal (an apparent clone of gnome-terminal), as they have happily added the hidden configuration item to a config file. I greatly prefer that above maintaining my own patch for gnome-terminal to disable a broken new feature.
Regardless of the existance of these interface elements in firefox, which, as Hein Zelle points out can be trivially removed, the existance of this interface element in gnome terminal is a mistake. These close buttons should not be there. It is a major annoyance, at the least, and a royal bloody pain in the arse ,more normally, when when mistakenly hits one of these close buttons. There are three options, remove the broken feature, provide a method for disabling them in configuration (preferred), or add a prompt to ask the user whether they really want to close the tab. PLEASE someone commit something that will fix this bug!!!
I agree - especially if the preferred option (configurable on or off) forces the user to _enable_ the close buttons if they want them :) As an aside, Firefox 2.0 does allow the user to change back to the old behaviour of a close button on the right, not on the tab. Remember the configuration option for this in about:config is an integer, not a flag. Ideally, gnome-terminal would follow this style of configuration for close button behaviour - a choice of no close buttons, a close button on the current tab only, or close buttons on all tabs, with the default being the first.
I attached a patch for this bug in #425063. It works fine for me for a week or so. Patch is adding /schemas/apps/gnome-terminal/global/close_button_on_tabs entry which offer an abbility to a user to enable or to disable close buttons on a tabs.
See also bug #168320, 87764 is also related. Personally I much prefer having buttons on each tab, the Firefox 1.5 model used to drive me mad. "The object you're working on is here, but you have to move your mouse all the way over here to manipulate it". Bleah. But at the same time of course we should never allow the user to easily lose their data.
*** Bug 425063 has been marked as a duplicate of this bug. ***
*** Bug 425064 has been marked as a duplicate of this bug. ***
Setting patch status; the patch doesn't apply to trunk.
Created attachment 124343 [details] [review] src patch
Created attachment 124344 [details] [review] schema patch
I think bug 168320 is the right way to go here, not adding a pref.
why not to have 2 solutions? code here is not adding much, but it nice to have a hidden feature like that.
With all due respect to Christian Persch, I disagree completely with that statement. Close buttons on tabs should be off by default, it is absolutely unnecessary bit of interface clutter. What is the default interface for a gtk notebook control? Tabs without close buttons. Why are close buttons being added to tabs by default? If they are going to be enabled by default, then a simple pref to disable them should be an imperative to fix a broken, nonstandard interface feature. As far as bug 168320 goes, does bash count as an active foreground process? Who gets to decide what an active process is? If I spawn a process inside my tab on a remote machine the local machine won't know anything about that process. This is ridiculous.
Most Gnome programmes with *dynamically added* tabs have close buttons on them. Galeon, Epiphany, Gedit, Anjuta, Pidgin. The only one I found that doesn't is Gnumeric, which is also the only one that has its tabs at the bottom. Prefs should never be introduced to fix broken things. Read http://www106.pair.com/rhp/free-software-ui.html . If it's broken, it needs to be fixed, not preffed. The 'brokenness' here is that you may accidentally kill a running programme, which bug 168320 addresses adequately by requesting confirmation.
Then they are all wrong (once again, the majority are not always right). As Steeve clearly stated, the close buttons are unnecessary clutter. The bug title says it all. This is more than just a "accidentally kill a running programme"-style problem; it is also an aesthetic issue as well. The majority of people commenting on this bug are against the close buttons, and for good reason. I've got researchers in our department who lose valuable work because they've accidently closed a tab because of these close buttons. I'm sick of patching gnome-terminal every update because of this issue. Bug 168320 does not fix the actual issue for most of the people with this problem.
How is a gnome-terminal tab, dynamically added? I manually add every tab. Someone has taken the time to add the code to put the close buttons on the tabs, so therefore, a decision has been made, somewhat arbitrarily, to have close buttons on tabs. It is not a gnome standard, otherwise there would be close buttons on the tabs by default.
Steeve: the removal/addition of tabs to the existing window vs usage of 'tabs' in e.g. Appearance Preferences.
(In reply to comment #16) > If this should be an option it seems like it should be a global thing that > applies to e.g. tabbed browser, tabbed gedit, etc. as well. > > Though I'm 99% positive this pref is a classic example of a broken workaround; > if the close button is too easy to hit and loses data, one could (radical > thought here) fix that properly in various ways (all admittedly requiring more > thought and coding than just adding a pref does) instead of requiring people to > "unbreak" their terminal via prefs dialog prior to using it. > > If the close button is truly a problem, simply not having the close button > would be better than a pref even. There is after all a close menu item and key > shortcut. Yes, if people feel like not having an option for this is the way to go, so be it, as long as the default is not the pitfall it _still_ is.
(In reply to comment #36) > I've got researchers in our department who lose valuable work because they've > accidently closed a tab because of these close buttons. I've gotten used to closing tabs by mistake every month or two. Today though, a running process was just killed when I accidently closed a tab. I somehow accidently clicked the mouse as I moved it across the screen - I wasn't even trying to interact with gnome-terminal. I can restart the process, but I'll have to wait an additional 21 hours for it to complete. I took the time to track down this bug report, and read through the whole thing. There are lots of arguments as to how best to solve this problem. Please pick a solution and implement it. Until then, I'll moving to another terminal program. I'm sorry, but I can't risk this happening again.
(Ben, read the manpage for nohup)
Mariano, i dont think that this is a place to suggest read mans. avb@ds:~$ nohup top nohup: ignoring input and appending output to `nohup.out' avb@ds:~$ cat nohup.out top: failed tty get in a lot of ot cases nohup is not an option.
Setting patch status (from comment 35).
No updates for more than 3 years on such a trivial matter, which makes people lose their valuable work. Get rid of those close buttons already. Nobody needs them. You should be encouraging people to exit the applications, not clicking on the close buttons. And we are not talking about grandma/grandpa losing access to their favourite terminal application here! If konsole wasn't broken for me in 4.9.2, I wouldn't even be looking at gnome-terminal. And after having lost couple of tabs already in last two days, just because of these idiotic UI choices, which are supposedly arrived at by "usability experts", I am pulling my hair out. Why O Why!
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/3405.