GNOME Bugzilla – Bug 58433
Can't desensitize GtkNotebook tabs
Last modified: 2014-08-03 18:58:46 UTC
GtkNotebook has no API for allowing an existing notebook page to be 'de-sensitized' (i.e. temporarily disable page switching to that tab). Furthermore, if a GtkNotebook tab widget is desensitized with gtk_widget_set_sensitive (GTK_WIDGET (some_notebook_tab), FALSE), the notebook tab's widget is 'greyed out' visually but it can still be used to perform a page switch with the mouse/keyboard! Apparently this is because the parent GtkNotebook widget is actually receiving the mouse events, rather than the tab widget. Most widget toolkits that have notebook-like widgets (Java's JTabbedPane, for instance - Mac and Windows also, I believe) allow tabs, like menu items, to be 'greyed out', after which they no longer can be used to perform page switches until they are 're-enabled'. Ideally we should have API for this (for clarity): gtk_notebook_set_page_sensitive (notebook, page_widget, is_sensitive); (or something like that) which would do the following: (1) grey out/re-sensitize the tab and content widgets via gtk_widget_set_sensitive(); (2) similarly sensitize/desensitize the corresponding menu items if available; (3) disallow page switch requests to desensitized pages (skipping over them in the case of prev()/next(); Barring that, we should at least disallow mouse or keyboard page switches for pages whose tabs are in an insensitive state (via a patch to gtk_notebook_page_select() ?). This second approach would require no API change, but the documentation should reflect the fact that 'greying out' tabs is done via desensitizing the tab widget, whereupon page switches to the corresponding page are disabled. I think that if the currently displayed page is de-sensitized it would be enough to de-sensitize the content widget, no 'automatic' page switch seems desirable. ---------- billh aug-02-2001
See discussion from: http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00016.html In particular, note comment in http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00037.html from Calum Benson: As an aside, it's generally considered poor practice to havedisabled tabs anway... it's almost always better just to hide them ltogether. (And since it's also a general rule that the contents of one tab shouldn't affect the contents/state of another tab in the same notebook, you're unlikely to get into a situation where this causes tabs to disappear/reappear under the user's nose.) So I'd consider this to be a low priority addition :o) I'd agree with this quite a bit - having an insensitive notebook page strikes me as sort of similar to a locked door saying "top secret; keep out" ... it would be better to simply avoid having the page visible, or to let the user at least see what was on the page. And also, any insensitive control should be grouped logically with whatever would make it sensitive - if you have one notebook page insensitive, it's pretty hard to figure out what would make it sensitive.
Hmm, I still don't agree with Calum and Owen though I understand what you guys are saying. It turns out that there *is* such an ability now, it just doesn't work correctly. That is, one can set_sensitive to FALSE on a notebook tab's label. Your arguments against doing this assume that notebooks are static, but they are not. In many apps there are sets/groups of UI info/options that are presented as notebook pages, where the tabs are rather like menu items. Just as one doesn't remove menu items when they are (temporarily) unavailable, one should not rebuild the notebook every time a group becomes invalid for whatever object or model lies behind the info the notebook presents. I think what we need is to just make GtkNotebook respect the sensitivity setting of the widget in its tab (something which it does not now do, you can select a notebook page whose tab is de-sensitized). I think this is a bug, not an RFE. Owen said: "if you have one notebook page insensitive, it's pretty hard to figure out what would make it sensitive." This assumes that there is some user action that would make the page sensitive, which is not always the case. Consider the case of menuitems, which are analogous to notebook tabs in some use cases. -Bill
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Since gtk+ behavior has changed in gtk+ 2.4, this now becomes urgent since the previous workaround doesn't work anymore. GOK for example requires this behavior.
downgrading this bug's accessibility impact; we have decided to remove GOK's dependency on desensitized tabs. I still think this is a desirable feature, but it doesn't block anything current that I'm aware of.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
I agree that it's bad practice to have insensitive pages, but shouldn't there be a common behavior for insensitive widgets? I mean, tab focus avoids insensitive widgets, filechooser in SELECT_FOLDER mode doesn't select insensitive rows (files)... wouldn't it make sense to do the same here? If it does, I'll provide a patch when I've got some time.
Right now you can set the page and the tab label insensitive and get an insensitive page that the user *can* switch to. Isn't that more useful then preventing the user from going to the page?
Maybe, but when I see an unsensitive widget I do not expect to be able do anything with it. I once again agree that it's terrible practice, and I really hope not to see a GUI featuring this ever, I just wanted to push some chat to decide whether closing it as WONTFIX or fixing it.
Having an unsensitive page to which one cannot switch is quite odd (what happens if it is the only page? Page navigation skips it?) Owen's suggestion to set both the page and the tab label insensitive seems the only sensible way to do this...
Trying to sort out a11y bugs that are still relevant from those which are not. Thoughts on this one?
I don't think we'll add more complications to GtkNotebook at this point.