GNOME Bugzilla – Bug 88314
Expanding nodes is a bit of a pain
Last modified: 2006-09-24 17:17:43 UTC
Currently you press "+" to expand a node, and "-" to hide it again. That's fine, but it's a bit of a pain since "+" requires Shift to access it on UK/US (and probably other) keyboards, but "-" doesn't. This is a rather unpleasant inconsistency, and will probably lead to reports of broken-ness (in fact I've already had one). Therefore it might be nice if "=" also expanded a node, since that's the key "+" shares . (Would probably need to research other keyboard layouts and see if there are any other keys that "+" and "-" share that it would make sense to additionally map to.) Also there's the problem that "+" on the keypad works, but "-" on the keypad doesn't, but I think I've moaned about that before and been told it wasn't possible to fix though :/ It would probably be better if "+" on the keypad didn't work either in this case, if it's possible to distinguish it from "+" on the keyboard. Another useful enhancement might be to allow Spacebar to toggle the expanded/hidden state of nodes that don't allow in-place editing, e.g. the tree in gconf-editor.
Actually, re my last point, maybe it would be better if Space always did that and F2 was used for Rename instead (as per Nautilus), but I guess it's a bit late for that :/
As a proposed solution for the 'S-+' vs '-' dichotomy, we can weasel out of it by doing what the ctree does. It binds '=' to toggle node. In practice, no one has ever complained about this behavior. As for the F2 vs. space issue, that should prolly be fixed by modes.
The modes bug is 80590.
Modes went to 2.4.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Is there any reason not to have space work in addition to +/-? It was what I instinctively tried when first using a treeview. And I didn't manage to figure out +/- on my own, even after some effort-- I had to ask on irc. (I actually discovered shift+right/left on my own though, and having found that, +/- weren't quite as important.)
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
The only reason I can think of to avoid Space as the toggle key is that an expandable node can potentially have an associated action just like any other node in a list/tree (e.g "view this folder", in the old nautilus sidebar treeview), and Space always ought to be the keyboard shortcut for 'activate'. You could perhaps smooth over that by claiming that that default action for an expandable node is 'toggle', unless the application over-rides it with something else, but I'm not convinced that would really match the user's mental model.
When I press Space in general I expect a "gentle" action, whereas for decisive action I press Enter. For instance in a file manager I would be shocked and dismayed if pressing Space on a file launched it. Thus I think Enter is sufficient for "activate". I don't think Enter and Space should always do the same thing.
Space does launch a file in Nautilus, and has done for the best part of a year IIRC... so you're obviously not *that* easily shocked and dismayed :) Space is the only activate key we document anywhere (except for Enter activating the default button in a dialog, pretty much), and has been since GNOME 2.0. So while I agree Space and Enter needn't always do the same thing, we'd need a pretty convincing reason to make them behave differently (or to deliberately make Enter do something new at all), I think. Perhaps this is it, but I'm not quite convinced, yet...
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
I didn't know about +/-, but shift-left-arrow and shift-right-arrow collapse and expand nodes. I think it makes a lot more sense -- shift-arrow feels like a control sequence, whereas +/- seem like data I'm typing at the program. (Space feels wrong for the same reason.) I think (can't check right now) that the Mac uses left/right arrows to collapse/expand nodes. Is shift-arrow acceptable? Do lots of people expect +/- to work? My first reaction is to simply get rid of +/- -- no more inconsistency!
Shift+arrow keys theoretically means "expand the selection in that direction"-- I know the tree control is row-based rather than cell-based at the moment, but if we went that particular keynav route, it would certainly preclude us from ever allowing aribtrary cell selections in future. Dunno if that would be an issue or not.
*** Bug 321647 has been marked as a duplicate of this bug. ***
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
*** This bug has been marked as a duplicate of 105895 ***