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 753071 - Tab switcher popover menubutton should have search entry (and ponies)
Tab switcher popover menubutton should have search entry (and ponies)
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: Tabs
3.23.x
Other Linux
: Normal enhancement
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
https://wiki.gnome.org/Design/OS/Tabs/
: 775046 (view as bug list)
Depends on:
Blocks: 417288 755388
 
 
Reported: 2015-07-30 18:13 UTC by Jean-François Fortin Tam
Modified: 2018-08-03 20:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2015-07-30 18:13:02 UTC
So the horizontal tabs metaphor is not perfect, and the fact that they scroll (instead of stretching) makes it difficult to have more than 5-10 open tabs in a given window (the good old bug #330676).

A way to mitigate this problem (short of implementing "context switching" à la Panorama de Firefox) would be to have a tab menubutton, much like what Firefox does when you have too many tabs to realistically shrink/stretch. Extra bonus brownie points if you can reorder the tabs from that menu.

If you want to solve bug #417288 at the same time, this menu could have a GtkSearchEntry at the beginning that acts as a filter that searches not only the current window but also other windows. So what I'm proposing is this, a popover containing a search entry + scrollable listview (but the popover should be autosized to make use of available vertical space below and avoid scrolling):


 ----------------/\-----------------
|                                   |
|   [ Search entry               ]  |
|                                   |
|  |-----------------------------|  |
|  |                             |  |
|  |                             |  |
|  |                             |  |
|  |     "tabs" listed here      |  |
|  |                             |  |
|  |                             |  |
|  |                             |  |
|  |                             |  |
          ...etc.
Comment 1 Michael Catanzaro 2015-07-30 20:47:49 UTC
FWIW this is very similar to what Builder did to get rid of tabs, and it works *VERY* well: it is much easier to use the menu button than a GtkNotebook.
Comment 2 Tassilo Horn 2016-09-16 15:07:48 UTC
I'm not sure if I understand this bug correctly but I just switched to GNOME Web as my primary browser and the only issue I have is that working with many (> 10) tabs is pretty inefficient with it.

What I imagine is a way to switch to an existing tab by its name/title.  That is, I press some button or preferably hit some shortcut key, then type "foo" and get a list of all open tabs having "foo" in their title.  I'd select one, hit enter, and that switches to that tab.  (In case I have multiple Web windows, it would be cool if all tabs of all windows were listed, and selecting a tab of a different Web window would select that tab in that other window and focus it.)

Is that what this bug is about?  If so, I'd very much suggest that such a feature was added.
Comment 3 Michael Catanzaro 2016-11-26 13:43:32 UTC
(In reply to Tassilo Horn from comment #2)
> Is that what this bug is about?  If so, I'd very much suggest that such a
> feature was added.

This bug is a bit simpler: the goal here is just to add a menu button that shows active tabs, which is quick and easy to do, hence I've tagged this as a newcomers bug. The UI you're describing sounds more powerful but also more complicated, not likely to happen unless a more experienced developer steps up to do it.
Comment 4 Michael Catanzaro 2016-11-26 13:47:19 UTC
*** Bug 775046 has been marked as a duplicate of this bug. ***
Comment 5 Dan Kasak 2017-02-06 05:02:23 UTC
I'm wondering if a simple gtk entry with an entrycompletion attached would at least be a good starting point. You can even put images in the completion things. Can't be that hard? If this seems an appropriate way forward, I'm happy to have a go at it.

To be honest, this would only provide a quick work-around for a pretty drastic issue with pretty basic functionality. IMHO switch tabs, which is primarily done with the mouse, requires that all tabs are visible if reasonably possible. We need these tabs to shrink.
Comment 6 Michael Catanzaro 2017-02-06 17:02:33 UTC
(In reply to Dan Kasak from comment #5)
> I'm wondering if a simple gtk entry with an entrycompletion attached would
> at least be a good starting point. You can even put images in the completion
> things. Can't be that hard? If this seems an appropriate way forward, I'm
> happy to have a go at it.

Go for it! We have the tab switcher popover menubutton now, but there is no search entry in it yet, so all that's needed is the search entry anyway. However, it should not attempt to solve bug #417288. The search entry should only filter tabs that are actually currently displayed in the popover (i.e. tabs that are in the current window).

Note: the search entry might not be easy to implement.
Comment 7 GNOME Infrastructure Team 2018-08-03 20:25:12 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/epiphany/issues/261.