GNOME Bugzilla – Bug 664218
Enter should activate the default "Continue" button in the wizard
Last modified: 2016-03-31 13:59:04 UTC
Pressing Enter in the wizard should always activate the default Continue action if it's sensitive. In particular, pressing Enter in the "Select a file/URL" GtkEntry should activate Continue with that URL.
not so easy, grab_focus() doesn't seem to work well when turning pages. More investigation needed. Furthermore, clutter-gtk grab chain is broken, making this feature a bit useful that is seems in the "Select Source" page for example
As you mentionned in IRC, we should make use of: gtk_entry_set_activates_default() and gtk_widget_set_receives_default()
(In reply to comment #2) > As you mentionned in IRC, we should make use of: > > gtk_entry_set_activates_default() and > gtk_widget_set_receives_default() Doesn't that require both the source and target widgets to be on the same level in widget hierarchy (as in directly under the same container)?
no
(In reply to comment #4) > no even if there is clutter actors involved? The reason I'm asking this is cause I tried to solve this bug when it was filed and failed to do so, at least by making use of gtk_entry_set_activates_default() and gtk_widget_set_receives_default(). I'll give it another try now..
(In reply to comment #0) > In particular, pressing Enter in the "Select a file/URL" > GtkEntry should activate Continue with that URL. This one seems to be already fixed. I'll look into the setup page entries now.
Created attachment 241203 [details] [review] wizard: Go to next page if a setup entry activates But before we do, ensure user has provided all required info.
Review of attachment 241203 [details] [review]: ::: src/installer-media.vala @@ +20,3 @@ public virtual bool need_user_input_for_vm_creation { get { return false; } } public virtual bool ready_to_create { get { return true; } } + public virtual bool user_wants_to_create { get; protected set; } // User wants to already create the VM Not exactly happy with achieving the goal with this property but apart from the receives_default/activate_default (which doesn't work out of the box at least), I couldn't think of a better way.
Created attachment 241216 [details] [review] wizard: Focus sensitive Continue/Create buttons Continue/Create button should have the focus when they are sensitive. Them being sensitive means that everything is ready for us to proceed to next step and so we should make it very easy for user to quickly move to next step. In most cases, this will enable users to create VMs very quickly IMO.
Created attachment 241217 [details] [review] unattended-installer: Use correct API for grabbing focus Gtk.Widget.is_focus is not for grabbing focus but dictates whether the widget is the focus widget within the toplevel or not.
Working patches are already provided so this should go to 3.8.
would be nice to have in 3.8.1, indeed
Review of attachment 241216 [details] [review]: Makes sense
Review of attachment 241217 [details] [review]: Was this causing some bug? I guess the entry was not focused as expected?
Review of attachment 241203 [details] [review]: Hmm I'd do something different here (which is already done for the ovirt login/password): as long as everything is not filled in, "enter" moves to the next entry to fill. After filling the last one, it moves to the 'login' button, but you need to press 'enter' once more to activate it. "enter" more or less behaves as "tab" there. Would also be nice to know why receives_default/activate_default is not working as expected... Maybe you need to call gtk_widget_grab_default() as well?
Review of attachment 241217 [details] [review]: No, it works fine AFAICT. This is just to do it the right way.
Review of attachment 241203 [details] [review]: I don't think I agree. TAB is the well-known method to go to next entry and ENTER is usually for "I am done". With this patch, user remains in the same entry if he/she hits ENTER while there is still mandatory fields to be filled. We should probably move the focus to next mandatory entry if current one is filled on ENTER too but that can be added later. Question now is that if this patch could go in time for 3.8.1?
Attachment 241216 [details] pushed as be58c07 - wizard: Focus sensitive Continue/Create buttons Attachment 241217 [details] pushed as 5bbb139 - unattended-installer: Use correct API for grabbing focus
(In reply to comment #17) > Review of attachment 241203 [details] [review]: > > I don't think I agree. TAB is the well-known method to go to next entry and > ENTER is usually for "I am done". With this patch, user remains in the same > entry if he/she hits ENTER while there is still mandatory fields to be filled. > We should probably move the focus to next mandatory entry if current one is > filled on ENTER too but that can be added later. I think we agree about the behaviour then. > Question now is that if this patch could go in time for 3.8.1? Let's say I missed this second paragraph, just as you missed the second paragraph from comment #15 ;) Given that we agree that the behaviour after this patch is suboptimal, and we also agree that the implementation could be nicer, and given that the bug it fixes is not a very bad bug, I think it's better to punt that patch for 3.8.1.
(In reply to comment #19) > (In reply to comment #17) > > Review of attachment 241203 [details] [review] [details]: > > > > I don't think I agree. TAB is the well-known method to go to next entry and > > ENTER is usually for "I am done". With this patch, user remains in the same > > entry if he/she hits ENTER while there is still mandatory fields to be filled. > > We should probably move the focus to next mandatory entry if current one is > > filled on ENTER too but that can be added later. > > I think we agree about the behaviour then. Almost :) See below. > > Question now is that if this patch could go in time for 3.8.1? > > Let's say I missed this second paragraph, just as you missed the second > paragraph from comment #15 ;) About receives_default/activate_default not working? I didn't miss it. I just don't know. Will need to test/research more. > Given that we agree that the behaviour after this patch is suboptimal, and we > also agree that the implementation could be nicer, and given that the bug it > fixes is not a very bad bug, I think it's better to punt that patch for 3.8.1. Well, there is also that this patch still improves the current behavior IMO and hence my question.
(In reply to comment #20) > Well, there is also that this patch still improves the current behavior IMO and > hence my question. I more or less answered that, given that improvement is very minor, implementation needs work, so does the behaviour, I'd just punt this patch to 3.8.2.
Created attachment 241784 [details] [review] wizard: Go to next page if a setup entry activates But before we do, ensure user has provided all required info. If all required info is not yet provided, take user to next required entry that is still awaiting input.
Created attachment 241785 [details] [review] Revert "wizard: Focus sensitive Continue/Create buttons" This reverts commit be58c071894b46090f51c1ccbaaff1892d16375a. This turned out to be a really bad idea: even a single character in username entry is sufficient for us to declare that we have all the needed info so username entry keeps loosing focus while user is trying to type in it.
Comment on attachment 241785 [details] [review] Revert "wizard: Focus sensitive Continue/Create buttons" Attachment 241785 [details] pushed as 6d37c8d - Revert "wizard: Focus sensitive Continue/Create buttons"
Review of attachment 241784 [details] [review]: Almost forgot about this patch/bug. Christophe, IIRC this patch is now only waiting because I haven't found out why gtk_widget_recieves/activate_default() doesn't work? If so, I think thats relevant to the other (already committed) patches and not this one. I'm probably missing something though?
Review of attachment 241784 [details] [review]: My understanding was that user_wants_to_create (); was needed as a workaround for this unspecified gtk_widget_receives_default() issue, which means this is relevant to this bug.
Review of attachment 241784 [details] [review]: Well the unattended installer shouldn't be accessing App.app.window in setup_ui IMO so gtk_windows_activate_default() can't replace user_wants_to_create(). Same goes for wizard calling App.app.window.activate_default(). Its not its place to do that and thinking about this, I'm even worried it will cause some weird side-effects (if not now, then in future).
Attachment 241784 [details] pushed as 0461f03 - wizard: Go to next page if a setup entry activates