GNOME Bugzilla – Bug 725123
Add ability to close tab by middle-clicking on it
Last modified: 2018-01-29 01:11:56 UTC
The new look of the notebook tabs is awesome. As a minor improvement, I would like to see the mouse middle click shortcut assigned to closing the clicked tab. This is already used by various applications (none of them being native GTK+ apps, and I found myself trying to use it again and again while migrating to Web 3.12) like eclipse, Firefox, Chromium/e.
*** Bug 319503 has been marked as a duplicate of this bug. ***
*** Bug 738998 has been marked as a duplicate of this bug. ***
IMHO it is a 'de facto' standard so could be a good choice to implement this. I'll try to use it every time in both nautilus and epiphany.
I'm not convinced that binding a destructive action to a bare click is a good idea.
(In reply to Matthias Clasen from comment #4) > I'm not convinced that binding a destructive action to a bare click is a > good idea. We could provide an undo operation here anyways. If we do that this is ok IMO, e.g. we have the same operation if the user clicks on the x or presses Ctrl+W. That we don't have an undo popup or so is a major design flaw and inconsistency on this IMO - be forgiving with the user. (Gets even worse with Ctrl+Q.) Let me try to summarize all the arguments for/against this, much of this coming from the long (heated) discussion on the duplicates: + "You leave a mouse button with NO FUNCTION when every other browser make it useful" + Many people will expect it to close the tab because they know it from other tabbed applications (not only browsers). + "It's especially useful if you're closing many tabs at once." + This feature is wanted by many people and keeps many from switching to epiphany, including me. - People may accidentally close tabs and panic. + A tab is just a view on some data, i.e. no data is lost for the user. + We can (and should) provide an undo operation as we do for all destructive operations. We should do this anyway when a tab gets closed. Related bug, although filed in the wrong product: https://bugzilla.gnome.org/show_bug.cgi?id=738997 + "It's no more destructive or undiscoverable than, say, Ctrl+W or Ctrl+Q" - It was stated: "it violates HIG", I didn't found any further reference or any reason. Please note that this summary is probably biased since I'm obviously in favor of adding this feature. I'm just trying to get and share an overview over pros and cons.
(In reply to Lasse Schuirmann from comment #5) > (In reply to Matthias Clasen from comment #4) > > I'm not convinced that binding a destructive action to a bare click is a > > good idea. > > We could provide an undo operation here anyways. Not really, without involving applications anyway. The notebook widget has not idea what a tab contains, or what the application may or may not do when the tab is removed. If we're getting into application functionality territory, then the application may as well provide a middle click pointer handler. > + "You leave a mouse button with NO FUNCTION when every other browser make > it useful" This is not a reason. We don't have a function for every one of the 105 keys on my keyboard either. > + Many people will expect it to close the tab because they know it from > other tabbed applications (not only browsers). > + This feature is wanted by many people and keeps many from switching to > epiphany, including me. These are the same reason. > + "It's especially useful if you're closing many tabs at once." That is debatable. > - People may accidentally close tabs and panic. > + A tab is just a view on some data, i.e. no data is lost for the user. That's unknown to the toolkit. A tab is a widget, from the perspective of GTK+; what the widget does, contains, or implies, it's all application-only knowledge. > + We can (and should) provide an undo operation as we do for all > destructive operations. We should do this anyway when a tab gets closed. The only way to do this is to keep a widget alive for a while after some user interaction, which means that from an application's perspective the widget is not destroyed immediately on close; since the widget is still alive, just "not visible" — with every complication that it entails. Do we mark it invisible? Do we just skip it when doing layout/draw operations? What about gtk_container_get_children()? — then the application may still try to operate on it because of timeouts or threads, at which point the tab may still try to do things like access the parent widget, or schedule an update.
(In reply to Emmanuele Bassi (:ebassi) from comment #6) > (In reply to Lasse Schuirmann from comment #5) > > (In reply to Matthias Clasen from comment #4) > > > I'm not convinced that binding a destructive action to a bare click is a > > > good idea. > > > > We could provide an undo operation here anyways. > > Not really, without involving applications anyway. > > The notebook widget has not idea what a tab contains, or what the > application may or may not do when the tab is removed. > > If we're getting into application functionality territory, then the > application may as well provide a middle click pointer handler. > > > + "You leave a mouse button with NO FUNCTION when every other browser make > > it useful" > > This is not a reason. We don't have a function for every one of the 105 keys > on my keyboard either. It is not indeed. IMO it is an opportunity, it provides a very short way for a very common action. (Primary actions for the tabs themselves are opening and closing.) Having the middle click as a close action and a "Reopen last tab" action makes, especially in web browsers, the tabs feel way more lightweight. It feels more like playing with them than working with them. Of course this only my perception. > > + Many people will expect it to close the tab because they know it from > > other tabbed applications (not only browsers). > > > + This feature is wanted by many people and keeps many from switching to > > epiphany, including me. > > These are the same reason. > > > + "It's especially useful if you're closing many tabs at once." > > That is debatable. Maybe we can agree on summarizing the above three points to one: many people would like this and find it useful, some consider it an important feature for daily use. > > - People may accidentally close tabs and panic. > > + A tab is just a view on some data, i.e. no data is lost for the user. > > That's unknown to the toolkit. A tab is a widget, from the perspective of > GTK+; what the widget does, contains, or implies, it's all application-only > knowledge. That is of course right. > > + We can (and should) provide an undo operation as we do for all > > destructive operations. We should do this anyway when a tab gets closed. > > The only way to do this is to keep a widget alive for a while after some > user interaction, which means that from an application's perspective the > widget is not destroyed immediately on close; since the widget is still > alive, just "not visible" — with every complication that it entails. Do we > mark it invisible? Do we just skip it when doing layout/draw operations? > What about gtk_container_get_children()? — then the application may still > try to operate on it because of timeouts or threads, at which point the tab > may still try to do things like access the parent widget, or schedule an > update. So considering that we seem to agree on: * This whole middle click discussion depends a lot on the undoability of the action. * An undoable tab close is desirable. * The application would need to be aware of the undoability. I'm not into the technical details here. Couldn't we offer the application to pass a parameter to make the closing undoable? Which would be hiding it somehow, call back to the application to let it show the undo switch. As the application is aware of this it would be its responsibility to not operate on/from this widget while it is in a hidden state.
Just to put this in perspective: We currently have no support for closing tabs in GtkNotebook anyway. If you see a close button in a notebook tab, its because an application put it there.
I would like to provide what I hope is a strong argument, since I would really like to see this feature implemented: Try asking your family and friends if they know that the scroll wheel is clickable. You would be surprised how many of them have no idea, and it's usually those kind of people that would close something by accident and panic. If you tell them that you can use it to close and open new tabs in a browser, some will say that's incredibly cool and will use it all the time, but most of them will never use the middle mouse button anyway, in case it breaks something.
I see, but I think that the button is in the tab is for new or casual users. An advanced user can find better to close a tab by using a middle click. If you need to work faster, any millisecond you can save, the better. It would be good to have it not only on gnome web, but also on every gtk app that it uses tabs.
(In reply to Sebastián from comment #10) > I see, but I think that the button is in the tab is for new or casual users. Note that I'm not arguing against the close button ;)
Sorry Juraj, my response was for Comment 8. I don't know how to do it properly. :)
(In reply to Sebastián from comment #12) > Sorry Juraj, my response was for Comment 8. I don't know how to do it > properly. :) S'all right ;) you just click the [reply] button on the right.
*** Bug 776539 has been marked as a duplicate of this bug. ***
*** Bug 784168 has been marked as a duplicate of this bug. ***
Users from ANY other browser moving to epiphany ALL will encounter this bug. Please fix it fast. Thank you. It is too hard to retrain oneself to use CTRL-w, as that is the only other way to close a tab that works in all browsers... as users do still use other browsers at the same time as epiphany.
Perhaps have a configuration variable for users who prefer some other behavior, but please fix it fast for the rest of us. Just today I have already clicked it like a dummy many times.
I even middle clicked again to close this window after completing this bug report. You know the only reason I'm using this dear browser is because I'm on an older computer, and midori is no longer maintained.
I recall other browsers probably don't even have an X anymore to close a tab as it wastes space on the tab, but I might be dreaming.
(In reply to Dan Jacobson from comment #19) > I recall other browsers probably don't even have an X anymore to close a tab > as it wastes space on the tab, but I might be dreaming. You are. Firefox has Xs, though it hides them at high numbers of tabs to save space. Chrome doesn't even do that, so eventually the Xs are all you can see at high counts. I don't know what IE/Edge/others do. As someone who myself needs to remember the same thing: Please try to wait a few minutes and collect all your thoughts to send in one message. That way, everyone else of us who is subscribed to the thread will only get 1 email, not 4.
The only reason this bug has been left open is because of bug 705487: if we are *ever* to add a way to show a way to remove a GtkNotebook tab from the tab itself, then we may reconsider this. Personally, I think it's pretty much pointless; bug 705487 is kind of lightweight on the details, and nobody has elaborated on that, either. Additionally, this is never going to happen for GTK+ 3.x, and for GTK+ 4.x we may start writing a new "tabbed" GtkStack switcher widget altogether. In any case, I'd still contend that this kind of behaviour ought to be in the application's territory, not in the toolkit, because the semantics around it are far too application-specific. To summarise: - if you want to add middle-click to close a tab to an application using GtkNotebook with close buttons on each tab, then open a bug against the application; putting a GtkEventBox as the tab widget is a fairly simple matter, and that allows intercepting middle-button clicks on the tab label. GTK+ has no involvement in this, and won't have, for the foreseeable future.
My bad. I used this as the dupe because I saw Michael did the same thing with a previous Epiphany bug. If anyone wants to reopen this for Epiphany, I guess they should use the oldest duplicate? The one I found was: https://bugzilla.gnome.org/show_bug.cgi?id=606386 For posterity: (In reply to Daniel Boles from comment #20) > Chrome doesn't even do that, so eventually the Xs are all you > can see at high counts. Chrome does also have Xs normally, until the tab count gets high. I was thinking of how it never makes its tabs scrollable or collapsed to a menu, so they pile up forever until you can only see the favicon. > I don't know what IE/Edge/others do. IE seems to reserve space for the X but only show it when the tab is active or hovered.
OK I tried to reopen bug 606386 as you said but I am not staff so please do it for me.
*** Bug 606386 has been marked as a duplicate of this bug. ***
This is not going to appear as a GtkNotebook feature. If you want it in an application, it needs to be implemented there. If you don't want it in the application, I would suggest closing bugs as WONTFIX, rather than duplicating them on this one, which is only misleading the bug reporters into blaming GTK+ for the failure of the application to implement this...
So it needs to be implemented in Epiphamy. So please reopen my Bug 784168.
OK I reopened Bug 784168.
Hm, I thought of this bug more as a design problem, as a destructive middle-click is a really powerful thing for advanced users, with almost no danger of accidental using by the casual user. Maybe it would be good to move this bug elsewhere?
It is a design problem, in the sense that it must be implemented by applications, and applications follow the HIG. Probably the best thing to do is ask on #gnome-design and see what current opinion is. I guess it's currently a 'no' though, otherwise we'd probably already have been linked to a wiki page on it or similar. I'm also not sure that an accident is as unlikely as you think. (However, having an action to undo the last closed tab makes it something of a moot point anyway.)
What's worse is in other browsers one can just **without moving the mouse** middle click many times to close many tabs. Even though each successive tab is a slightly different width, the wide target area ensures that each one slides over and can be hit. On the other hand, with just a X as target area, the mouse must be repositioned each time.