GNOME Bugzilla – Bug 747664
GtkEntry:activates-default should work inside of popovers
Last modified: 2015-08-16 04:38:37 UTC
It would be nice if i could have a simple popover with two widgets. [GtkEntry] [GtkButton] And enter in the entry would activate the button similar to activating the default response in a dialog.
Sounds worthwhile indeed, you can achieve that by juggling with gtk_window_set_default(), but it would be nicer to have GtkPopover API so the right default is "pushed" depending on the current modal popover. I guess a similar gtk_popover_set_default() API would suffice.
Created attachment 301771 [details] [review] Add default widget handling to popovers Add a new API, gtk_popover_set_default_widget, that can be used to make a widget act as default while the popover is shown. This is useful in dialog-like popovers. http://bugzilla.gnome.org/show_bug.cgi?id=747664
Created attachment 301772 [details] [review] file chooser: Set default widget in create folder popover This is using the new default widget functionality for popovers to make Enter in the entry activate the Create button.
Maybe we should have custom elements so you can set up default widgets from the ui file, like <object class="GtkPopover"> ... <default-widget name="button"/> </object> That would also be useful for windows.
Review of attachment 301771 [details] [review]: That's what I had in mind :). It looks all right to me, besides the couple of debugging g_prints. Maybe we should also have a getter?
(In reply to Matthias Clasen from comment #4) > Maybe we should have custom elements so you can set up default widgets from > the ui file, like > > <object class="GtkPopover"> > ... > <default-widget name="button"/> > </object> > > That would also be useful for windows. That sounds useful indeed, this is just a single call, but the less code needed at the time of setting up a popover from an UI file the best IMO.
Attachment 301771 [details] pushed as e1c1fc5 - Add default widget handling to popovers
Created attachment 302790 [details] [review] popover: Use priv attribute after preconditions If the user pass a NULL the code will crash. This patch moves the use of priv attribute after the preconditions check. Also, in function gtk_popover_set_default_widget(), the precondition check returns a value if fails. http://bugzilla.gnome.org/show_bug.cgi?id=747664
Passing NULL is not allowed. I use this idiom quite a bit, and don't want to change it. I fixed up the precondition check in gtk_popover_get_default_widget.
There is at least 2 problems with this patch, one of them is affecting gnome-documents. (1) Changing the default widget of the window while a popover is open will not have the desired effect once the popover is closed, because the popover will restore an outdated state from it's priv->previous_default variable. This is a problem because gnome-documents changes the default widget in response to an action triggered from the popover (before it's closed). (2) Adding default widgets to popovers in ui files not only doesn't set them as default widgets for the popover, but it also clobbers the global state of the window by unsetting its default widget. I'll attach an example for that.
Created attachment 309074 [details] Broken ui file The entry should activate the "I'm the default" button. It currently does not do that, even if the menubutton popover hasn't been opened yet. It should still do that, even if the popover is open.
I've pushed a fix for (1). (2} is just the way has-default works: last one wins.
The problem with (2) is that we do not have a way to set a default widget for popovers from Glade.