On Tuesday 04 July 2006 16:07, Attilio Fiandrotti wrote: > Frans Pop wrote: > > On Monday 03 July 2006 23:21, Attilio Fiandrotti wrote: > >>Nothing wrong, that's the correct behaviour of GTK+ applications : in > >>SVN rev 38009 i set reactivity to <ENTER> and <SPACEBAR> and double > >>clicks as pressure on "OK" button for the handler of SELECT questions > >>only, while MULTISELECT (and SELECT questions which are displayed > >> like trees) weren't affected : tomorrow i'll investigate about how > >> to fix this. Colin pointed me to this page: http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html#widget-navigation which seems to indicate that even in the GNOME Human Interface Guidelines 2.0 "return" and "space" should have different functions, in line with how the newt frontend works. However, for me the Gnome HIG are not necessarily authoritative for g-i. After all, g-i is not a Gnome application. It is a fully separate application that happens to use the GTK libraries for one of its frontends. Consistency between frontends is for me more important. > > IMHO the "correct" GTK behavior is broken then... > > I'd personally prefer to have the frontend behave like the newt > > frontend in this respect, but I guess that is something to discuss > > with the team. > > > > I'd certainly appreciate it if you would not change such behavior > > without discussing it first on the list. > > regarding single MULTISELECT questions, the simple (one line) attached > patch makes the question handler behave like this > > -If a checkbox inside a row has focus (small circle around it with many > common GTK themes of GTK default theme) <ENTER> or <SPACE> key pressure > toggles the check and, to go forward, the user has to TAB until the > "OK" button receives the focus and then he can use <ENTER> or <SPACE> > to activate it. IMO <ENTER> should still activate the Continue (OK) button in this case (or whatever button is defined as the default button). > -If no checkbox has focus, then an <ENTER> or <SPACE> key pressure > activates the "OK" buton while no check is toggled. <SPACE> should not activate the Continue (OK) button, unless the Continue button itself has the focus. Here's the log of the short discussion I had with Colin about this. (Davide did not reply before I wrote this mail.) [18:47:15] <fjp> zinosat: What do you think of using <enter> always as shortcut to Continue button? [18:47:21] <fjp> My reasons are: [18:47:28] <fjp> - consistency with newt frontend [18:47:52] <fjp> - having space and enter do the same thing seems stupid to me [18:48:37] <fjp> - especially in g-i "newbe" users will use mouse to select and are thus less easily confused anyway [18:52:01] <Kamion> that would seem consistent with the GNOME HIG [18:52:04] <Kamion> http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html#standard-shortcuts [18:53:45] <fjp> Kamion: What? Having space and enter do the same or having enter always select the button? [18:53:54] <Kamion> having enter always activate [18:54:02] <Kamion> space should toggle checkboxes etc. [18:54:11] <Kamion> what's the current behaviour? [18:54:38] <fjp> attilio changed it recently so that enter will also toggle checkboxes [18:54:43] <Kamion> urgh [18:54:56] <Kamion> that's definitely contrary to the HIG [18:55:03] <Kamion> Space Toggle selected state of focused check box, radio button, or toggle button [18:55:07] <Kamion> Return Activate focused button, menu item etc. [18:55:13] <fjp> Yes. [18:55:46] <fjp> Except possibly if you extend "focussed" to multi-selection lists. [18:57:27] <Kamion> I don't think that's the intention or how GTK applications generally behave [18:58:07] fjp adds this to the discussion on the list
Attachment:
pgptFADR6g0bd.pgp
Description: PGP signature