After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 335453 - Close buttons take up a lot of space and are easy to click by accident when selecting tabs
Close buttons take up a lot of space and are easy to click by accident when s...
Status: RESOLVED OBSOLETE
Product: gnome-terminal
Classification: Core
Component: general
2.14.x
Other All
: Normal enhancement
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Welcome to all those slashdot lovers....
: 341074 346789 425063 425064 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-03-22 05:50 UTC by Martin K. Petersen
Modified: 2021-06-10 16:30 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
patch to remove close buttons (2.91 KB, patch)
2006-07-23 19:28 UTC, Hein Zelle
none Details | Review
src patch (2.51 KB, patch)
2008-12-10 14:10 UTC, Alexander V. Butenko
rejected Details | Review
schema patch (674 bytes, patch)
2008-12-10 14:10 UTC, Alexander V. Butenko
rejected Details | Review

Description Martin K. Petersen 2006-03-22 05:50:45 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...
Comment 1 Paul Kelly 2006-03-26 14:49:00 UTC
Agreed, the close button should be a preference option, but if confirm-close behaviour is added, it too should be optional.
Comment 2 Guilherme de Siqueira Pastore 2006-04-08 13:51:53 UTC
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 :)
Comment 3 Matt Doyle 2006-04-23 03:44:06 UTC
I agree that the close tab buttons should be optional. They add clutter (IMO) and are too easy to click on accidentally.
Comment 4 Chris Palmer 2006-04-23 23:05:25 UTC
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.
Comment 5 Steven Brown 2006-05-01 05:32:58 UTC
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.
Comment 6 Anders Brander 2006-05-01 06:37:31 UTC
How about implementing a close button that just sends a ctrl+d. If that doesn't terminate the shell, it should ask for confirmation?
Comment 7 Duarte Henriques 2006-05-01 08:49:28 UTC
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.
Comment 8 Chris Palmer 2006-05-01 21:47:23 UTC
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.
Comment 9 Luca Cavalli 2006-05-08 21:23:21 UTC
*** Bug 341074 has been marked as a duplicate of this bug. ***
Comment 10 Ben Wheeler 2006-05-09 12:39:27 UTC
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.
Comment 11 Ben Wheeler 2006-05-09 14:51:28 UTC
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.

Comment 12 Guilherme de Siqueira Pastore 2006-05-11 20:39:58 UTC
The person effectively maintaining gnome-terminal for Debian nowadays am I, so it doesn't really matter... heheh
Comment 13 Luca Cavalli 2006-07-06 21:53:39 UTC
*** Bug 346789 has been marked as a duplicate of this bug. ***
Comment 14 Steeve McCauley 2006-07-07 14:45:23 UTC
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!
Comment 15 Hein Zelle 2006-07-23 19:28:11 UTC
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.
Comment 16 Havoc Pennington 2006-07-23 20:43:00 UTC
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.
Comment 17 Mariano Suárez-Alvarez 2006-07-24 00:19:12 UTC
Yup, this pref is basically a --do-not-be-broken option. 

Is the intention to add UI for this?



Comment 18 Kjartan Maraas 2006-08-12 12:04:19 UTC
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.
Comment 19 Havoc Pennington 2006-08-12 14:54:34 UTC
I think Firefox is changing in 2.0 to have the close button on each tab? I seem to remember reading that...
Comment 20 Mariano Suárez-Alvarez 2006-10-17 23:38:22 UTC
In FF 2.0RC3, each tab has its own close button (but the tabs will not shrink indefinitely...)
Comment 21 Andrew Reid 2006-10-31 00:07:06 UTC
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 :)
Comment 22 Hein Zelle 2006-10-31 11:21:22 UTC
(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.
Comment 23 Steeve McCauley 2006-10-31 14:24:43 UTC
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!!!

Comment 24 Chris Palmer 2006-10-31 19:47:49 UTC
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. 
Comment 25 Alexander V. Butenko 2007-04-09 14:40:50 UTC
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.

Comment 26 Calum Benson 2007-08-14 14:49:40 UTC
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.
Comment 27 Christian Persch 2008-05-29 20:13:33 UTC
*** Bug 425063 has been marked as a duplicate of this bug. ***
Comment 28 Christian Persch 2008-05-29 20:13:41 UTC
*** Bug 425064 has been marked as a duplicate of this bug. ***
Comment 29 Christian Persch 2008-05-31 20:37:49 UTC
Setting patch status; the patch doesn't apply to trunk.
Comment 30 Alexander V. Butenko 2008-12-10 14:10:17 UTC
Created attachment 124343 [details] [review]
src patch
Comment 31 Alexander V. Butenko 2008-12-10 14:10:49 UTC
Created attachment 124344 [details] [review]
schema patch
Comment 32 Christian Persch 2008-12-10 14:17:56 UTC
I think bug 168320 is the right way to go here, not adding a pref.
Comment 33 Alexander V. Butenko 2008-12-10 14:37:35 UTC
why not to have 2 solutions? code here is not adding much, but it nice to have a hidden feature like that.
Comment 34 Steeve McCauley 2008-12-10 14:54:16 UTC
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.
Comment 35 Christian Persch 2008-12-11 19:25:23 UTC
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.
Comment 36 Chris Palmer 2008-12-11 19:33:33 UTC
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.
Comment 37 Steeve McCauley 2008-12-11 21:00:58 UTC
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.
Comment 38 Olav Vitters 2008-12-11 21:05:41 UTC
Steeve: the removal/addition of tabs to the existing window vs usage of 'tabs' in e.g. Appearance Preferences.
Comment 39 Arnaldo Carvalho de Melo 2008-12-28 17:53:52 UTC
(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.

Comment 40 Ben B 2009-02-04 00:15:55 UTC
(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.

Comment 41 Mariano Suárez-Alvarez 2009-02-09 00:17:48 UTC
(Ben, read the manpage for nohup)
Comment 42 Alexander V. Butenko 2009-02-09 01:52:44 UTC
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.
Comment 43 Christian Persch 2009-05-26 20:29:06 UTC
Setting patch status (from comment 35).
Comment 44 devsk 2012-10-15 16:51:30 UTC
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!
Comment 45 GNOME Infrastructure Team 2021-06-10 16:30:10 UTC
-- 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.