There are probably two dozen requests-for-preferences in here that are
more important, and the prefs dialog is already full... ;-) So I'm not
optimistic this makes sense.

I don't think it's a preference anyway; no user really wants it to
task always, or ask never. What you want is for the terminal to ask
for confirmation of close if closing would cause data loss. So the
right thing may be an escape sequence that Emacs or whatever is inside
the terminal can send to indicate that there's unsaved data or not.

Closing a tab when clicking the close button is just broken IMO, 
Acroread is the only thing I know of that does that, and it drives me
nuts. There's another bug open in here with a patch that adds a close
button to the tab itself, which is how I'd approach it.

I somehow aggree with your most of your remarks however I 
also believe that closing should be confirmed at least 
when multiple tabs are opened. 

I tried several times to use 'multi-sessions' terminals 
and I always gave up because I was loosing too much jobs 
this way.


 

OS/X has a fairly nice 'here is a confirm dialog'  popup for this
case. I admit I'd turn it off immediately but I could see it being
useful, I guess.

Confirmation if we have > 1 tab open might be a nice idea.

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

I was going to say whatever we decide here should be written into the
HIG, but of course in our Star Trek Future we want the window manager
to be in charge of tabbing in cases like this anyway so we shouldn't
have to ;)

Personally I like the way Galeon does it too, i.e. only asks for
confirmation if you have more than one tab open-- that's saved me a
couple of times...

Having just been bitten by this... here goes a patch that adds a
confirmation dialog when closing a window on which there is more than
1 tab open. 

It adds a gconf key (/apps/gnome-terminal/global/confirm_window_close)
which toggles this behaviour, but does not introduce ui to change it.
Latest mozilla has a ``don't show this again'' check-box in the
confirmation dialog...

Created attachment 17911 [details] [review]
add confirmation dialog when closing windows with > 1 tabs

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

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

Ok, this looks good to me except the dialog text.

Instead of "Do you really want to close this window?", which kind of
questions the users judgment in hitting the close button (i tend to
believe the user is always right and the computer makes all the
mistakes :-).

How about something like: "The other tabs in this terminal will be
closed as well"

Perhaps we can get some more comments on the wording and apply this
patch, although it won't make it for the current release.

Agree... how about something like (remembering that the HIG style is
for bold+large primary text, followed by regular secondary text):

<b+l>Close all tabs?</b+l>
This window has [n] tabs open.  Closing the window will
also close all its tabs.

                              [Cancel] [Close All Tabs]

Rock, Calum's the man.  I like the wording of this and it looks good
from a HIG perspective.

Follows a patch which implements Calum's wording on current HEAD and a
screenshot of the dialog window (a windowshot?)
If I get approval from the release team (we are past the feature
freeze) I'll commit this, if it's ok?

Created attachment 23718 [details] [review]
Use Calum's wording and move the patch to HEAD

Created attachment 23719 [details]
The confirmation dialog

Alert looks good, but is "Cancel" the default button?  It would
probably be better if "Close All Tabs" was the default, even though
that's the more destructive action-- keyboard users hate having to hit
Tab-Enter to confirm things that they knew they wanted to do anyway :)

Same point as Calum, should the dialog really use "Cancel" as the
default? Often when closing the dialog you really do want to close all
the windows, it's just a nice idea to have notification first if you
happen to close it accidentally.

You should be OK with doing
"gtk_dialog_set_default_response(GTK_DIALOG (dialog),
GTK_RESPONSE_YES);" before gtk_dialog_run to get that...

Also is "if (gtk_notebook_get_n_pages (GTK_NOTEBOOK
(window->priv->notebook)) <= 1)" really needed? You're doing casting
and using a much longer code route [ GTKNotebook vs. GList ] than just
simply using "if(g_list_length(window->priv->tab_menuitems) <= 1)"...

I'll change the default. I suspect the HIG's “Do not make a button the
default if its action is irreversible, destructive or otherwise
inconvenient to the user” will be invoked around next ui review time... ;)

Changing target so that I see this by 2.7 time.

-- 

Thanks for the gtk api reminder, I guess.

Counting menu items when what you want is to know how many notebook
pages there are is rather roundabout, don't you think? Also,
gtk_notebook_get_n_pages is a very descritive name, which makes things
pretty obvious, and does not depend on the rest of the app maintaining
an invariant (the length of the tabs menu is always equal to the
number of pages in the notebook). Note that g_list_length is rather
wasteful, too, if one wants be strict: “if
(window->priv->tab_menuitems && window->priv->tab_menuitems->next)
...” is an O(1) test that accomplishes the same thing, and, in fact,
the left side of the && can even be left out, since gnome-terminal
hopefully has “windows always have at least on tab” as an invariant.

I'm cleaning out the extra GNOMEVER keywords and adding the
BLOCKED_BY_FREEZE keyword.

I changed the default response to "Close all tabs", and committed this on HEAD.
Thanks all.

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

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