After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724493 - Wrap gtk_popover_new_from_model
Wrap gtk_popover_new_from_model
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: general
3.11.x
Other All
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on: 724503
Blocks:
 
 
Reported: 2014-02-16 18:59 UTC by Juan R. Garcia Blanco
Modified: 2014-03-07 07:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Wrap new GtkPopover methods (6.44 KB, patch)
2014-02-17 22:43 UTC, Juan R. Garcia Blanco
accepted-commit_now Details | Review

Description Juan R. Garcia Blanco 2014-02-16 18:59:44 UTC
There's a new public method in GtkPopover, gtk_popover_new_from_model(). I looked into Menu and MenuBar, so now I know that we need to create a hand-coded constructor, and use _CONSTRUCT("relative_to", relative_to.gobj()), and all that. But I'm stuck at binding the model to the widget. There's a static method in GtkPopover, gtk_popover_bind_model(), that is called when constructing a GtkPopover this way. Should we fill a bug in gtk+ so that gtk_popover_bind_model() becomes public api? I think this is reasonable since GtkMenuShell has a public method for this.
Comment 1 Murray Cumming 2014-02-16 19:36:18 UTC
Yes, I think that would be a good idea. We cannot wrap this method otherwise.

As with bug #704671 for GtkMenu(Shell), even having the *_bind_model() methods is not ideal, but is at least usable.
Comment 2 Juan R. Garcia Blanco 2014-02-17 22:43:26 UTC
Created attachment 269471 [details] [review]
Wrap new GtkPopover methods

Wrapper for gtk_popover_bind_model() and gtk_popover_new_from_model(). I tried to mimic what is done in MenuShell. For gtk_popover_bind_model() I've created two methods, assuming the string parameter could be optional. I'd to hand-write the new constructor, so it could contain an error.
Comment 3 Juan R. Garcia Blanco 2014-02-19 19:01:10 UTC
May I push this? Carefully because gtk_methods.defs could have changed; I'd possibly need to regenerate it.
Comment 4 Juan R. Garcia Blanco 2014-02-19 21:38:21 UTC
Sorry, I just noticed that gtk_popover_new* have changed, and now accept a NULL relative_to parameter (there'll be then four constructors). To reflect this we need to modify our constructors. I think I can do this; what I don't know is if it'd be better to push this patch first, and then the patch that reflects the latest changes.
Comment 5 Murray Cumming 2014-02-20 08:19:18 UTC
Review of attachment 269471 [details] [review]:

It looks good. Yes, feel free to push the commit you have and then push a further commit, as long as you don't break the build.

So, did you file a GTK+ bug that caused that function to be added? If so, could you make this bug depend on it, please.
Comment 6 Kjell Ahlstedt 2014-03-06 15:28:39 UTC
Why is this bug still open? Hasn't it been fixed by
https://git.gnome.org/browse/gtkmm/commit/?id=7f5ff9390eadf6997409b2b87e7a1de466e6af14
Comment 7 Juan R. Garcia Blanco 2014-03-07 07:16:08 UTC
Sorry. Yes, it can be closed. Thank you.