On 10 Feb 2009, at 07:16, Allan Day wrote:
On Mon, 2009-02-09 at 19:22 -0500, Randall Wood wrote:On 9 Feb 2009, at 12:12, Allan Day wrote:Hey all, I've been working (on and off) on reviewing all the bugs and other discussions on tabs in GNOME [1]. It's reached a fairly mature stage now. I think the review contains useful information about how tabs could be improved in GNOME. Any comments or suggestions?I would suggest the following:- The display of a single tab (show tab or collapse tab bar) should beuser configurable and universal across the entire desktop (A user may find that screen real estate is more valuable than consistency). I would make showing the tab bar when there is only a single tab the default.There has been some recent discussion about the display of the tab bar in Gedit (this is the only GNOME app to display the tab bar when only one tab is open) [1]. In that bug, a number of devs state a preference for hiding the tab bar by default. You might also want to read this discussion on the Usability list: http://mail.gnome.org/archives/usability/2005-June/msg00133.html . So let's review the arguments: *Tab bar hidden by default*Advantages: clean, simple interface. Apps look very minimal without it,which can be nice. Makes learning the basics of the interface easier(since it is simpler). Conforms to current practice amongst GNOME apps.Disadvantages: makes tab functionality less discoverable. Means that itisn't possible to introduce additional functionality to the tab bar. Clicking on empty space in the tab bar could trigger the creation of a new tab, for example. Or it might be possible to drag tabs and windows from elsewhere into the tab bar. (Maybe the first step is to decide whether this functionality is desirable?)- Perhaps the close button should be hidden when there is only a single tab?I'd say leave the close button there, for sake of consistency.- Use Ctrl+{ / (Open brace) Ctrl+} (Close brace) to move between tabs
PgUp/PgDown moves around between keyboards even in the same layout. Look at compact keyboards like on laptops compared to full size keyboards. I switch between fullsize keyboard on a docking station and the compact keyboard on my laptop frequently, and the PgUp/PgDown keys are in different locations, while the {} keys are in a constant location.
Oh? Why not Ctrl+PgUp/PgDown?- Tabs should be included in the Window menuAgreed. There are decisions to be made about what this menu entry shouldbe called and what it should contain. Most GNOME apps call it 'Tabs'. Gedit is the exception - it calls it 'Documents'.
It seems to me that conceptually the tab is nothing but a logical extension of the window, and if we do a document-centric design, the window is nothing but a container for a document, so that makes sense. The only problem with using "Documents" instead of "Windows" is a matter of consistency--if every document-centric application had a menu for the type of objects it handles in windows (documents, conversations, drawings, etc), the user would loose the common target of "window" for dealing with the document container. Also, applications that work with multiple types of document-like objects might have problems as well (think of OpenOffice - it has the Window menu, would it need "Documents", "Spreadsheets", "Drawings", etc if it lost the window menu?
- There should be a menu item "Window->Merge All Windows" to move all tabs in all windows to a single tab bar in a single windowSounds like useful functionality. The main argument against might be interms of keeping things simple. Also, I'm not sure whether this is something that could be done by the window manager - might have to go into the File menu.
I don't think this should be a window manager task, its just that since tabs are window-like things, it fits with the other activities in the window menu. The File menu should about taking actions against the file being displayed or edited in the window or tab, not about moving tabs between windows, or moving all tabs to a single window.
Allan [1] http://bugzilla.gnome.org/show_bug.cgi?id=547848