GNOME Bugzilla – Bug 116650
"action area" for GtkNotebook (e.g. for tab close button)
Last modified: 2009-11-10 15:00:23 UTC
(See bug 72101 against the GNOME HIG for a general discussion about tab behaviour.) Some applications like Galeon or gnome-terminal that feature tabs per document need a method to close these tabs. While this is generally possible using the menu and a hotkey, it is often more desirable to have a "shortcut method" available. Galeon implements this using close buttons on the tabs themselves, Mozilla uses a common close button to the right of all tabs. This is a proposal for a general "action area" that could contain other shortcut icons (like new tab) as well. API draft: GtkHBox *gtk_notebook_get_action_area(GtkNotebook *notebook); This is quite generic and powerful. Another possibility is a higher level API: void gtk_notebook_set_tabs_closeable(GtkNotebook *notebook, gboolean closeable); gboolean gtk_notebook_get_tabs_closeable(GtkNotebook *notebook); This also has some advantages: * Tabs could have an additional popup menu with a "Close tab" option. * The location of the "close tab" icon could be configurable (e.g. by the theme): it could either be to the right of all tabs or on each tab.
Is it any progress on it?
> possible using the menu and a hotkey, it is often more desirable to have a "shortcut method" available. The menu and hotkey approach is both keyboard accessible and accessible to user with a mouse. although it is not necessarily as fast as other solutions it has the benefit of being a lot more predicatable. I must disagree with the idea that your suggestion is more desirable as I think the menu item is a necessity in most cases. To put it politely I strongly dislike the idea of a close icon on every tab, try closing multiple tabs and it can be quite cumbersome but if like in Mozilla the close icon is fixed on the left you can click it agian to close the next tab. In Mozilla the first option in context menu for the tab header is close (difficult to reverse if you slip but fairly fast and I figured I should mention it rather than a close icon on every tab). You mention an action area containing possibly containing other buttons besides close, but I draw you back to your Mozilla reference: Mozilla provides just two buttons, New on the left before the tabs and close on the right just after the tabs (or vice versa in a RTL locale I would assume). I dont think it is such a good idea to have any buttons other than those two belong in the tabbed Notebook (as opposed to putting them in the application toolbar) and having other buttons beside the Close button increases the risk of accidently clicking the wrong button. adding the usability keyword, given bug 72101 and the signifcant usability impact any implementation if this might have, for better or worse.
I don't see how the button can be seen as a shortcut to the hotkey. The hotkey approach seems to be by far the fastest method of closing tabs. I greatly prefer having a close icon on every tab, for two reasons: - It makes it harder to accidentally close more than one tab. People do tend te double click when single click will do. If you want to do mass-closing of tabs, using a hotkey is much healhier than repeated clicking. - It makes it possible to close other tabs than the current tab. I like this feature very much, and I think it should be at least taken into account when comparing the two options.
Still valid for latest GTK.
Created attachment 81591 [details] [review] patch for adding an action area to GtkNotebook Hi!, this patch allows GtkNotebook to set an action area beside the tabs, making adding a common close button quite easy. some observations on the patch: - only allows setting it at the right side of the tabs area (left in RTL), if people wants more fine grained customization, perhaps we could pass GTK_PACK_START/GTK_PACK_END to the function. - unlike other action areas, it just allows setting 1 widget, if people wants to insert more, will have to provide their own GtkBox. This is done because GtkNotebook tabs orientation may change, and it may depend on the user preferences whether the action area box should also change orientation or not.
Patch 81591 applies cleanly. Reviewing it would take a while. (Working on http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html)
(In reply to comment #5) > - only allows setting it at the right side of the tabs area (left in RTL), if > people wants more fine grained customization, perhaps we could pass > GTK_PACK_START/GTK_PACK_END to the function. I think that extra argument is essential. Many applications have icons on one side and buttons on the other side. > - unlike other action areas, it just allows setting 1 widget, if people wants > to insert more, will have to provide their own GtkBox. This is done because > GtkNotebook tabs orientation may change, and it may depend on the user > preferences whether the action area box should also change orientation or not. Did you consider the case of OS X, where the action area would probably have a reversed orientation?
(In reply to comment #7) > I think that extra argument is essential. Many applications have icons on one > side and buttons on the other side. Yeah, but it's like a call for bloat, and GtkNotebook is already quite bloated IMHO :), I guess we need more compelling reasons than saying "some apps have buttons at both sides", some input from the HIG guys would be great... > > Did you consider the case of OS X, where the action area would probably have a > reversed orientation? > Nope, but since the code already includes RTL support, shouldn't be hard to switch that for MacOS if necessary. Will try to provide a new patch soon.
I'll pretend to be a HIG guy... We already have arrows on both the inner and outer sides of the tab row in case of tab overflow. See bug 377441 and bug 326953. From that perspective, allowing buttons on both sides isn't really a problem. In the end it's up to the app developer to make sure he keeps bloat at a minimal level, the toolkit shouldn't make that decision for him IMHO. Just make sure to respect Fitt's law in fullscreen mode.
Created attachment 113608 [details] [review] updated patch, adds two action areas
Created attachment 113609 [details] test app
Created attachment 113610 [details] screenshot for the lazy
(In reply to comment #12) > Created an attachment (id=113610) [edit] > screenshot for the lazy To be honest, I don't like it. Most GNOME apps have their close buttons in the tab itself (epiphany, gossip, empathy, gnome-terminal), so I don't see why we're going with the Firefox-style. It makes it impossible to close tabs that aren't the current one (I usually open a few tabs for each "task", and I would close them without looking at them if my task was finished), the close button could be a screen width away from the actual tab handle (tab on the far left, close button on the far right), and the "new tab" button would replicate a toolbar button that would be just a few 100 pixels above.
I also don't like the tab at the far side, and fwiw the Firefox guys abandoned the idea pretty quickly when they tried it. It's just not easy for people (including me) to remember to look all the way over to the right side of the window to close something that isn't all the way over there. It's not informative in the way that having the button attached to the tab's title is. One thing that might be worth keeping from Firefox's current implementation is that when the tabs are overflowing (i.e. there are too many of them), only the currently focused tab has a close button. Would that be up to the app to decide though? I'm not sure, but I like that feature.
@Bastien, if I'm not mistaken this bug is about action areas in the tab notebook in general, not about having an external close button everywhere. Let's just keep using close-button-on-tab for GNOME apps and still allow action areas.
> Let's just keep using close-button-on-tab for GNOME apps and still allow action > areas. Maybe carlos didn't make this clear enough: GtkNotebook is already an overcomplicated mess. "we know close-button-in-the-corner is not a good ui but lets just add action areas anyway, somebody may find a use for it" is just not a good approach.
(In reply to comment #16) > Maybe carlos didn't make this clear enough: GtkNotebook is already an > overcomplicated mess. "we know close-button-in-the-corner is not a good ui but > lets just add action areas anyway, somebody may find a use for it" is just not > a good approach. That's an unfair characterization of what I said; I don't like the close-button-in-the-corner either but there's at least one other obvious use: a New Tab button. Don't limit developer's imagination; Gnome-terminal could have a new shell button; gedit could have one or more for new files with a certain template; Epiphany could have a button to show a dropdown menu of open tabs in case of tab overflow.
This would help us to get more compact docks in GIMP, see bug #346881.
Johannes Schmid seems to be working on this again (although with a new implementation): http://blogs.gnome.org/johannes/2009/03/31/save-the-world-waste-less-pixels/ Thank you, Johannes. :-)
Created attachment 132174 [details] [review] Updated patch This patch is basically Carlos' patch against latest git and with some cleanup and with documentation. I tested the patch with all different layout options (tab positions, scrollable yes/no) that gtknotebook provides and could find any problems with it. I am willing to improve the patch instead you still see some problems. Just to point that out - this patch is not meant for firefox-like closing buttons or something like that. It's completely up to the develop what he wants to add in this area. IMHO we should encourage developers to add small widgets with PACK_START only though bigger widgets (combo-boxes, etc.) can be added with PACK_END without making things cluttered.
Looks ok in principle, but there are quite a few issues to straighten out still: - action widget seems not in focus chain at all - in standard notebook style, the action widget is not aligned with the tabs - it does seem to be aligned with the selected tab, but that looks wrong to me - in no tabs and borderless notebook style, the action widget is placed floating over the notebook decorations. It should probably be hidden - in scrollable notebook style, when rotating the tabs to the left or right, the bottom arrow don't show up (presumably hidden beneath the action widget)
Created attachment 146530 [details] [review] Fix the widget position to match the position of non-selected tabs
Created attachment 146531 [details] [review] Don't show the action widgets when no tabs are shown I will take a look at the others tommorow. Hints for the focus handling are highly appreciated though!
Created attachment 146856 [details] [review] Fix the behaviour of the arrows when tabs are on the left/right > - in scrollable notebook style, when rotating the tabs to the left or right, > the bottom arrow don't show up (presumably hidden beneath the action widget) Fixed! (And yes, it took me much longer to figure that out that to write this 1 line patch...)
Created attachment 146862 [details] [review] Fix focus handling Focus chain is now: * ActionWidgetStart -> Tabs -> ActionWidgetEnd for top and right * ActionWidgetStart -> Child -> Tabs -> ActionWidgetEnd for bottom and left Actually I am not sure what the right solution is but this feels ok. Probably some HIG/A10n people should check this. Hope all remaining problems are solved now and this is ready to merge!
Created attachment 146901 [details] Another test application This is the test application I used especially for the focus handling. It allows to play around a bit more than the old test application. I kind of wonder why there is not a test application for GtkNotebook in gtk+ itself as there is for most other widgets.
All the issues from my last comment seem to be fixed, except for the focus chain. I see that the start action widget is in the focus chain when moving forward with Tab, but it is skipped when going backwards with Shift-Tab. And the end action widget seems to be not in the focus chain at all. Fix these two, and it is good to be merged.
+ tab_width = MAX (tab_width, action_widget_requisition[ACTION_WIDGET_START].width); + tab_width = MAX (tab_width, action_widget_requisition[ACTION_WIDGET_START].width); I guess one of these should be ACTION_WIDGET_END
Created attachment 147235 [details] [review] patch as committed Here is the patch I am going to commit. This should get the focus chain almost right.
One thing left to do is add gtkbuilder support for adding action widgets to notebooks.
Tiny issue: The gtk-doc comment says "Adds a widget" while gtk_notebook_set_action_widget only ever sets one widget.
It sets one on each side, but yeah. If you have more exact wording, please fix. Thanks