I noticed I have a menu item for it. Still need some other way, but 
probably requires GtkNotebook extensions in GTK 2.2.

The way Anjuta handles this is pretty nice:

You have the close button in the tab, but you can only close the
current tab, this is, trying to close a tab that is not focused will
only bring that tab to front, then you will be able to close it.

Manuel,

That sounds reasonable.  Is this worth implementing, Havoc?  Also,
what did you mean when you said you "didn't know how" to implement the
close-button-on-the-side (Mozilla) style?  I like the Mozilla solution
too, but I do not understand the difficulty in implementation.

The Anjuta approach does sound nice.

The issue with the Mozilla approach is that the way GtkNotebook works
makes it tricky to implement.

I'm attaching a first attempt at a patch to add close buttons to the
tabs.  Like Anjuta, only the close button on the active tab is functional.

Things to consider if applying:
- Is it desirable to have it also switch to the desired tab if you
click on a desensitized close button (right now it does nothing)?
- This patch assumes you have a close-button.xpm installed in your
pixmaps dir, and doesn't make the necessary changes to the dist files.

Created attachment 8701 [details] [review]
First attempt at Anjuta-like tab close buttons

s/close-button.xpm/small-close.xpm in previous comment

Yes, it should move to the tab you click, it will be annoying if not.

Created attachment 8719 [details] [review]
Revised patch - fix mem leak and code format inconsistencies

I was going to make it switch to the tab when clicking on the disabled
close button, but then encountered a problem.

Desensitized buttons/widgets don't emit signals, so there's no easy
way to tell if it's been clicked on.  Possible workarounds are 1) Not
actually desensitizing the button, but just showing a different image
for the non-active tab's close buttons, 2) Some clever hack utilizing
Gtk/Gdk trickery.

How did Anjuta solve this?  It wasn't clear to me when browsing their
source.  I bet I'm missing something simple.

Indeed it is very simple, and anjuta is doing what I thinked:

browsing the anjuta code, in text_editor.c in:

GtkWidget* text_editor_tab_widget_new(TextEditor* te)
...
    gtk_box_pack_start(GTK_BOX(box), button15, FALSE, FALSE, 0);
    gtk_box_pack_start(GTK_BOX(box), close_pixmap, FALSE, FALSE, 0);
...

This is, both a button with the close pixmap and a close pixmap
(sensitive = false) are packed along with the label.

Then in anjuta.c:

void anjuta_set_current_text_editor (TextEditor * te)
....
        if (ote != NULL && ote->buttons.close != NULL) {
   		gtk_widget_hide(ote->buttons.close);
                gtk_widget_show(ote->widgets.close_pixmap);
        }
        app->current_text_editor = te;
        if (te != NULL && te->buttons.close != NULL) {
		gtk_widget_show(te->buttons.close);
                gtk_widget_hide(te->widgets.close_pixmap);
        }
...

Hope you can finish your patch now, as I like the way anjuta tabs work.

Created attachment 8730 [details] [review]
Yet another revision -- now with fixed behavior for close buttons in other tabs (like Anjuta)

Thanks Manuel, that was a good simple idea and I used it.  I was
actually looking through the Anjuta2 source, so I did not see that.

The last attached patch should be what you want.  I recommend copying
/usr/share/galeon/small-close.xpm to
$PREFIX/share/pixmaps/small-close.xpm if you want to get something
other than the Gtk+ broken image stock icon.

*** Bug 75029 has been marked as a duplicate of this bug. ***

*** Bug 96537 has been marked as a duplicate of this bug. ***

*** Bug 116829 has been marked as a duplicate of this bug. ***

adding PATCH keyword since there is no comment about it.

I didn't see this bugreport and I made a patch for the same thing...
when I posted it to desktop-devel Havoc asked me to attach it here.

Anyway note that my patch works like gedit and epiphany (all the
buttons are active) so Nate's patch it's probably better... nontheless
maybe there are a couple of bits you may want to integrate from my patch:
- it does not need to install an icon
- factoring the code in a build_tab_label function seems slightly
cleaner than a add_close_button function.


By the way, I'm fine either we choose to make it behave like anjuta
(only the current close button works) or like gedit and epiphany (all
the tabs may be closed), the important thing to me is that all the
apps work in a _consistent_ way.

Maybe this shuld be discussed on the usability list...

Created attachment 20218 [details] [review]
alternative patch (similar to gedit and epiphany)

I'd prefer to have a right-click menu on tabs. 

Clicking a close-this-tab button should not open a confirmation
dialog, because that'd become annoying very fast, but having any ui
wich does something which is not undoable in such a prominent place
does not sound right to me, even if it only works on the current tab.

I do think there's a need for a usability@ discussion on tab close
buttons, then sync these apps up - ideally by adding close buttons to
GtkNotebook natively, even.

I would say the confirm dialog or no should be the same as for window
close buttons. It _is_ a bit lame that you can lose your whole
terminal session without having to confirm, but having to confirm
would clearly be annoying, at the same time. So I kind of feel this is
a problem with no perfect answer.

Whichever behavior is chosen, if hidden tabs can't be closed without
raising them, the close button should be insensitive on those tabs so
the user knows clicking it won't actually close the tab.

It's also worth noting that you can kill ALL of your terminal
sessisons with the WM close button, without confirmation, even if the
terminal window is inactive and obscured by other windows.  So in that
sense, the gedit/epiphany behavior is consistent with Metacity's behavior.

My preferred behaviour is like the current one in epiphany and gedit,
where you can close every tab in every moment:
- if tab labels are so small that the close button takes so much room
that you can click it by mistake it is a bug anyway
- novice users don't use tabbed interfaces anyway

The proposed change (making possible to close only the current tab)
would be acceptable, but having a confirmation dialog is a NO NO. You
don't get a confirmation dialog when you close a window.

The only time when you should get a confirmation dialog is when you
are closing a modified document without having saved it (like it
happens in gedit), but this is peculiar of the application, not
something related to the tabbed interface.

The problem with the idea of only confirming exit when there is
unsaved work is that does not at all apply to things one does in
shells. No matter how hard we wish, ed(1) is not going to adapt to any
standard mechanism we may come up for apps to notify us of the
savedness of the files they are working on.

Indeed, there is an important difference between gnome-terminal and
gedit/mozilla/epiphany/etc which cannot be forgotten: these *are* the
applications that run in their windows, but gnome-terminal can be
running anything within the reach of a Turing machine in each of its
tabs... It follows that some differences are to be expected.


I really do not like close-me buttons on tabs. I am a tab freak in
Firebird, and I have never needed them; I think, also, that power
users will use keyboard shortcuts, anyways. 

I have a working patch which adds a Close Tab item to the context
menu, which would put closing a tab 2 clicks away (one if we made
right clicks on tabs raise them *and* pop up the context menu) and a
little drag.


Note this is not the only bug about this:

* Bug 87771 is about adding a confirmation dialog to closing windows
with > 1 tabs; it even has a patch which does that. IMHO this is good:
the points raised by Erik above are valid even for `power users.'

* Bug 109777: this requests and posts a patch to add `little X
buttons' to tabs. The patch needs works, though.

* Bug 72170: some more discussion on closing windows/tabs.

I'll mark only the second as a dup, because the other two actually
deal with differents aspects of closing (!)

*** Bug 109777 has been marked as a duplicate of this bug. ***

Comment on attachment 8701 [details] [review]
First attempt at Anjuta-like tab close buttons

Obsoleted by other patches.

I would vote for the gedit/epiphany style. But anyway there should be any
solution , soon. I am missing comfortable tab handling. I also like moving tabs
with clicking and holding left mouse button. I also think right click on a tab
should present some options (close tab,...). Why is this taking so long if there
do exist patches? I think any solution is better than none. it is also possible
to change the solution later...

tia.

Thilo

*** Bug 72170 has been marked as a duplicate of this bug. ***

Fixed in CVS HEAD.