GNOME Bugzilla – Bug 72101
Hig should specify a tab implementations
Last modified: 2020-12-04 18:18:58 UTC
Tab implementations in the various gnome programs very. For instance the new gnome terminal uses a different style than galeon does. galeon ----------------------------------------- ------ ------ |tab1 x| |tab2 x| gnome terminal ----------------------------------------- ------------------- ------------------- | tab 1 | | tab2 | There should be a detailed specification as to how tabs are to implemented, including what options should be included for tabs etc.
widget bug
Last I checked there was a library for this; the problem is not 'specify how it should work', most likely, but 'specify that everyone should use the stock library' and then fix that. [Not saying this as bugmaster; just putting on my usability/hacker hat for a bit. :)
See bug 75029 as well. Suggest that the HIG team come up with an overall recommendation, including desired GtkNotebook enhancements for GTK 2.4 to be filed against GTK, and "best available hack" suggestion for the short term.
ccing marco so we can get a galeon perspective :)
The HIG does suggest (IIRC) that basically you should use tabs so that they don't take up any more space than necessary, i.e. don't pad them to fit the width of the window or make them all the same width as each other. Unfortunately I don't know what flags you have to set to make that happen, so I couldn't include that information :) This of course doesn't cover issues like whether/when to use icons or coloured text on tabs, which is something we ought to address as well assuming we have anything sensible to say about it...
Oh, as for "enhancements to GtkNotebook 2.4", I vote for a standard "something on this tab has changed" indicator, to alert the user to things like external changes (e.g. channel tabs in xchat) or to unsaved changes (e.g. in an explicit-apply tabbed preferences dialog). This indicator would need to be themable, though, for accessibility purposes-- just turning the text blue or red or something doesn't really cut it :/
Basically, I would like to see all tabbed gnome apps act the same. Have the same file menus, same tab behavior etc. I think we need to be brutally clear on how apps should behave in regards to tabbing.
Current implementation in galeon2 is to have use a tab size of 1/7 the window size. But we have also a minimal size to ensure the title is not unreadable. When you have more then 7 tabs in a window the scrolling arrows are showed. Following Calum suggestions about not adding any pad, we could move to a max size of 1/x of the window instead of a fixed one. This is also similar to mozilla but I'm not sure how much it would be good for different types of applications. I think the "something is changed" proposal is great. We have 3 states in galeon though, Normal/Loading/Load complete. But this is probably just galeon specific ... Having this themable would allow us to remove colors preferences ... Other issues that could be discussed: 1 Is a Close button on the tab good ? 2 Should tabs be reorderable by drag and drop ? 3 Is a tabs menu needed and which items it should contain 4 How the Close part of the File menu should look for an application using tabs in the main window ? See 83560 5 Someone seem to be confused by the fact that closing the last tab close also the window (and doesnt leave and empty window like in real MDI). I personally prefer current behavior but ... Just some braindumping.
Hmmm in application like galeon, where the title of the tab is changed frequently in a not interactive way, you really want to have tabs all of the same fixed size. Otherwise every title change would cause a tab resize ....
The resizing point is a good one, it might make more sense to have different recommendations for tabs with dynamic and static labels.
I don't see how tab resizing is a problem. I'd prefer it to truncation of the document title. It would only happen on the current tab, so the notebook page itself wouldn't jump around at all. Is there anything that the GtkNotebook defaults don't do that we need, apart from: - a standard way to show "unsaved changes" - a "Close this document" X box. ?
Can anyone reply?
I can't think of anything else that's come up any time we've talked about this, those two features would be a pretty valuable start (and defining what the 'unsaved changes' indicator should be is probably enough to be going on with for now). There are also some related comments in bug #72170.
1. So, we'd like an EggNotebookDocuments that adds the [x] to the tabs and has some kind of void user_requested_document_close(unsigned int notebook_page) signal. For me, it would make sense to add a map of page-numbers-to-document-uri in that widget too. 2. So, does anyone have any ideas how we might show "unsaved changes" per-tab rather than just in the window title when the tab is selected? Let's rule out color changes.
Well, it would be good if the unsaved indicator on the tab was the same as the unsaved indicator in the titlebar... we don't recommend anything specific in the HIG for this yet, but just putting an asterisk before the title is probably the most widely used method at the moment.
Agreed.
I just wanted to mention that i'm more convinced than ever that tabs should be implemented by the wm.
Yes, Havoc has said that too, I think, in very general terms. But I have no idea how it might be done. And I don't know if it's a reasonable expectaction to have of the window manager. At the moment apps are doing it themselves.
Murray, I have some ideas (ok i stole some of them from mpt). Basically it would require a wm spec extension so that an app could specify that something should be opened in a tab with the current window. I guess each window would have an associated tab group. Windows that are already opened could be tabed by alt+draging the title bar of one window ontop of another.
> Basically it > would require a wm spec extension so that an app could specify that > something should be opened in a tab with the current window. Well, however it's implemented, there is clearly interest in pursuing it. This isn't really the place for that though.
I will try to summarize the points that were brought up in this bug: * Drag & Drop support (tab reordering) for GtkNotebooks would be nice. => not HIG stuff, discussed in bug 73240 against gtk+ * We should probably have scroll arrows (like in Galeon) when the number of tabs to display is larger than the available space. => filed as bug 116644 against gtk+, patch for the HIG follows * Tab states: there should be a way to specify different states for the page of a tab, like "loading", "ready", "unsaved", etc. => filed as bug 116647 against gtk+, patch for the HIG for a (possibly temporary) solution/workaround follows * Should tabs expand and fill out the whole space reserved for tabs (like gnome-terminal currently does), should tab labels that don't fit be clipped? What about tabs that change their labels during the lifetime of the tab? => this is partly in the HIG, patch for clarification and enhancement forthcoming * Close buttons. Should they be on the tab itself or at the right of all tabs? The latter seems not to be possible without gross hack with current Gtk+. => Filed as bug 116650 against gtk+ Missed anything? I made this bug depend on bug 116650. I guess it could be closed, once this implemented and the attached patches (or similar recommendations) are applied.
>* Should tabs expand and fill out the whole space reserved for tabs >(like gnome-terminal currently does), should tab labels that don't fit >be clipped? What about tabs that change their labels during the >lifetime of the tab? I think that for applications that use tab for MDI the mozilla beahvior is interesting. Basically the first 4 tabs has a width based on the window size (1/4). When more tabs are added the size is adjusted dinamically. This is similar to gnome-terminal behavior but has the advantages: - To not cause resizes until the window is full - To not have huge tabs when there are only a few of them See 116519 for a small discussion about it.
Created attachment 18023 [details] [review] Added MDI-specific notes to tabbed notebooks guidelines. Added guideline that tabs shouldn't change size.
Just to summarize my last patch (affects "Tabbed Notebooks" in Chapter 6: "Controls"): * Introductory notes about MDIs * Tabs shouldn't change size. * Static tabs: Tabs should be exactly as wide as required (old suggestion) * Dynamic tabs: Tabs should have a fixed size and labels should be truncated if necessary. * Scrolling arrows might be appropriate if number of tabs is not known in advance.
Created attachment 18024 [details] [review] Tab status indication guidelines
Well despite the fact that i think most of the hig writers won't want to add any comments on mdi, i'll add a comment: I think that both file->close (assuming that there is no quit menu item as both the draft hig suggest and as is implemented in epiphany) should only close the current tab, and that the window border close button should also only close the current tab as well. This prevents us from recreating the nitemare which is the havoc quit reigns upon multiple window apps onto tabed mdi apps. Also it is more consistent with sdi apps, doesn't force the user to think as much, and worst comes to worst a user can close multiple tabs at once by just hammering the window border close button with the mouse. Also i've heard anecdotal evidence from another ephy dev that when he let a friend of his use his browser, by providing him with a new tab to work in, the users first impulse was to close the tab with the window border button, which could have caused lots of data loss. ps. i still think this should be done in the window manager and that tabbed mdi has no place in a well designed document based gui.
On the MDI vs. WM issue: I would probably agree that a change to existing WMs is the appropriate solution(although I haven't pondered about this very much, yet). But as it stands, MDI is very convenient for a limited set of applications (like web browsers or terminal windows). Since there no solution on the WM front in sight, I think that we must consider MDI for now. Nobody is forcing us to commit to MDI forever.
sebastian, I think the HIG should push the envelope when it comes to ui, not stick to what is currently possible. I think there are a lot of examples from the past year and a half that suggest that HIG recomendations lead to change. (we do have reason to believe this, see the bold label frames, the button ordering etc.) If the HIG strongly states that any type of tab mdi should be implemented by the window manager and any required extensions to wm spec, I believe we will sooner see a tabbed wm because devs will ask for it. That said maybe a gup approved document on the current state of tab mdi might be acceptable for the time being, but I don't think it belongs in the HIG personally (even though I'm the one that opened this bug :)
Well, if you can describe exactly what should happen (even just exactly how it would look and act) then that will do more than anything to help make it happen.
I've just applied Sebastien's patch as a placeholder in the HIG for any more concrete recommendations on this topic. Except that I used preference windows as an example, rather than 'MDI' :)
Comment on attachment 18024 [details] [review] Tab status indication guidelines Marking committed based on calum's last comment on the bug.
Comment on attachment 18023 [details] [review] Added MDI-specific notes to tabbed notebooks guidelines. Added guideline that tabs shouldn't change size. This patch hasn't been committed yet.
Hi, I have just created a wiki page at http://live.gnome.org/TabImplementation for this topic that may better reflect the current status in future.
See also http://bugzilla.gnome.org/show_bug.cgi?id=132173
We still do not have a policy, and now we have tabs in Epiphany, Nautilus, gedit, gnome-terminal etc. Raising priority to high.
One thing that seems to have been ignored in previous discussions about tabs on Bugzilla is where new tabs are placed. Epiphany inserts new tabs to the right of the current active tab. Gedit and Gnome Terminal, on the other hand, append new tabs at the far right-hand side. IMO, Epiphany gets it right, but yes, the important thing is to have a consistent approach.
(In reply to comment #36) > One thing that seems to have been ignored in previous discussions about tabs on > Bugzilla is where new tabs are placed. Epiphany inserts new tabs to the right > of the current active tab. It only does so when you have activated the Tab Groups extension (or you're using a very old Epiphany version). The default behaviour is to add tabs to the far right.
Reinout - yeah, it's the Tab Groups extension. Thanks for the clarification. This behaviour - having the new tab placed next to the current one - is excellent, IMO.
Setting target to 3.x, and adding 'uipattern' to whiteboard as one or more patterns could fall out of this for our (proposed) 3.x UI pattern library.
See also bug #607886, where 'close tab on Ctrl-middle-click' is proposed.
See also Bug 83265, where there is a suggestion to show keyboard shortcuts in tab labels when tabs can be switched using Alt+Number.
The HIG now contains a page on tabs. It could do with more elaboration, but it is a start. Please file bugs for any specific additions that are required.