You Got A Question? Ask    GNOME Community!

gtk-theme2
 12324   |  Oct 25
gtk_logo2
 9593   |  Mar 17
arch
 8147   |  Mar 28
 6644   |  Jun 17

Tabs design in Gnome 3

One of Gnome’s biggest targets is to maintain consistent design for even the smallest parts and elements used in creating user interfaces. This is done according to logical instructions on how to implement various things to work and look similarly very good.

Some upcoming new features concerning tabs in the next major GTK+ version, and some tentative designs of new tabs implementation for gedit have piqued my interest, so here is a quick look on what kind of tab design you should be expecting all Gnome core apps and utilities to have from now on.


Here is how gedit tabs look right now:

gedittab

 

The problems with this design are many. First, you can’t add a new tab just by clicking on a corresponding button found in a prominent position. Instead, you will either have to find the “add new tab” option in the “File” menu, or press Ctrl+N from the keyboard but that is not friendly for touch devices at all and generally confuses people that don’t use their keyboard for application functionality. Another problem is that there is a lot of empty space left to the right and no centralized way to access tabs that overlap (when window is small) fast and accurately.

The plans is to make all tabs under Gnome featuring the following abilities:

  • Support animated add, remove, and reorder
  • Support an optional close button on the active tab
  • Support drag and drop (as both source and destination)
  • Handle overflow where there are more tabs than available space
  • Provide a way to indicate a non-active tab has activity
  • Allow for both text, icon, and icon+text labels
  • Possibly have a way to add a new tab

Here is the gedit related tentative art that could be the vehicle for these new tabs to take form:

tabs1tabs2tabs3tabs9tabs10


As you can see from the above designs, the close button is only shown for the active/selected tabs, and the tabs can expand to use all the available width by automatically changing their size. Tabs have a minimum width though, and once there is no more space for additional tabs, they are added to an overflow menu on the right (three dot button).Also, a blank tab is always to be found on the right, allowing users to quickly take advantage of it when needed.

All this is great and modern looking, but the most important is that it is vital for use with touch devices where details like this one are more than critical. Great to see one more thing taking shape the way it should :)


 
  We can't watch comments unless G+ provides an API or if you send a notification, e.g +World Of Gnome
     Sometimes is better to place your questions on GNOME Community
  • Bert

    I would like the following key combinations to work for tabs ALWAYS (gedit uses Ctr+Alt+Page(Down/Up) )

    next tab
    Ctrl+PageDown

    previous tab
    Ctrl+PageUp

  • Marco

    I would like ctrl-tab and ctrl-shift-tab to work in GNOME apps. That’s the convention everywhere else, and a lot of laptops don’t have a PageUp PageDown anymore, and rightfully so because they’re stupidly useless. Middle click to close would also be fantastic.

    • http://varemenos.com/ Adonis K. (Varemenos)

      I believe you can modify the middle click action, I totally agree about ctrl+tab and I would also add the alt+drag action

    • Mike

      Today I discovered you can use Alt+1 Alt+2 and so on to switch between tabs.

  • http://connelhooley.co.uk/ Connel Hooley

    Don’t like it at all. With 3 tabs open on a maximised window on a large screen, you have to move the mouse quite a distance to switch between the two and back. Plus having one tab open taking up half the space and the add button taking up the other half of the space will look weird. Why is the add button inserted into the middle of the tabs? It should be to the right of the menu, or to the left of all the tabs. And I see no reason why you wouldn’t want to close an open tab. Maybe only show those close buttons on hover?

    • IsacDaavid

      Those are genuine concerns
      +1 for showing the close buttons of inactive tabs on hover or something.

  • Carlos Soriano Sánchez

    As I can see in my jhbuild environment with latest gtk+ and gedit, the current direction is something like this:

    https://raw.github.com/gnome-design-team/gnome-mockups/master/theming/experiments/gedit-tabs-whitespace-as-separator.png

    But it’s just in the early states and afaik that can change and of course improve. Not sure tough.

    • Pynix Wang

      sublime text nil theme….

  • David

    I often find myself trying to open a new tab in Gedit by using Ctrl-T, because that’s what Firefox uses.

    • Elchtest

      Me too. Luckily, Ctrl-T does nothing, though.

      (I also hate it when I mean to hit Ctrl-S, but then hit Ctrl-D which deletes the current line. Sometimes, I don’t even notice the missing line immediately, but on the second attempt manage to hit Ctrl-S, and hey, I’ve saved a corrupt file. Awesome.)

      • Alfredo Hernández

        Yeah, maybe they could change it to Shift+Del, as it is in Sublime Text, for instance.

  • Mark

    I don’t really like the fact that the inactive tabs have no visible separation between them. I think in general this makes it harder to figure out where to click when using a mouse, especially with tab titles that are short. IMO it would be better if separation lines are added to clearly mark inactive tab boundaries.

  • Rowan Lewis

    When tabs change width like in this design, it’s important to keep the
    size the same until the user has finished interacting with them.
    Otherwise users find themselves trying to hit a close button, only to
    find it’s moved.

  • Anon

    A bit off-topic, but is there plans for GTK and GNOME Shell to adopt standard and pure CSS? For example, replacing -gtk-gradient() with proper linear-gradient() and such, so we can ease our CSS development further.

    • lassekongo83

      linear-gradient works. The only thing that uses gtk-gradient is the animated .spinner.

  • hoschi

    I want see also Ctrl+(Shift+)Tab for switching between Tabs, in addition to Ctrl+PGUP/PGDN. It is a convention and is similiar to Alt+(Shift+)Tab. Good keyboard handling is very important.

    The Close-Button should be shown always. Firefox hide this button if there are “many tabs” open, it disturbs usage of tabs as the user needs to hover or even click on a tab to close it. Saving space for the sake of saving space is not a good idea.

    By the way:
    While the first mockups look fine, the last mockup looks ugly! Furthermore (and more important) that are not Tabs and I don’t recognize them as. Looks like StackSwitcher, a different (but similiar) concept. Different things shouldn’t look similiar!

  • Jessewb

    Man, I really love that second design! It looks so clean and it’s unique.