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 670856 - GVariantBuilder should be registered with the GType system
GVariantBuilder should be registered with the GType system
Status: RESOLVED WONTFIX
Product: glib
Classification: Platform
Component: gvariant
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Allison Karlitskaya (desrt)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-02-27 00:38 UTC by José Alburquerque
Modified: 2012-02-27 20:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description José Alburquerque 2012-02-27 00:38:17 UTC
While trying to wrap GApplication's "add_platform_data" virtual function, I noticed that it takes a GVariantBuilder.  For the C++ bindings to wrap the virtual function, it would be necessary to also wrap GVariantBuilder.  If GVariantBuilder was registered with the GType system, it would be easier to do this.
Comment 1 Allison Karlitskaya (desrt) 2012-02-27 17:11:46 UTC
I think add_platform_data may be a better candidate for 'skip' -- it's never meant for use by applications -- only toolkits.

also: boxing GVariantBuilder is difficult proposition.  It has a dual identity as a struct and a quasi-object.
Comment 2 José Alburquerque 2012-02-27 18:16:50 UTC
(In reply to comment #1)
> I think add_platform_data may be a better candidate for 'skip' -- it's never
> meant for use by applications -- only toolkits.

For now we have skipped it also.

> 
> also: boxing GVariantBuilder is difficult proposition.  It has a dual identity
> as a struct and a quasi-object.

I suppose it's not urgent since the only meaningful API that would require it would be the above mentioned virtual function.
Comment 3 Allison Karlitskaya (desrt) 2012-02-27 18:52:20 UTC
then i'll WONTFIX this.

fwiw: i think bindings should not really expose GVariantBuilder or GVariantIter to their users at all, but rather attempt to provider nicer interfaces to GVariant that mesh better with the native type system of the language in question.
Comment 4 José Alburquerque 2012-02-27 19:34:18 UTC
Sorry about the bug report.  Honestly, after reporting, I was made aware, as you pointed out, that the virtual function in question would probably not need to be wrapped.  I still reported the bug in case it might not be difficult to have GVariantBuilder registered with the GType system, but since you mentioned that it was not an easy proposition, I decided that it was not worth doing this for the one virtual function that wont be wrapped for now.

In the future, I'll be more careful about filing something that might not be important.  Thanks.

(In reply to comment #3)
> fwiw: i think bindings should not really expose GVariantBuilder or GVariantIter
> to their users at all, but rather attempt to provider nicer interfaces to
> GVariant that mesh better with the native type system of the language in
> question.

Yes.  Until now, only GVariantIter has been exposed in the C++ bindings.  It hasn't been quite adapted to the C++ way of iterating, but that should not be difficult to do in the future.
Comment 5 Allison Karlitskaya (desrt) 2012-02-27 20:51:04 UTC
No worries.  Please don't hesitate to report problems in the future.

If you're not sure about something, it's also sometimes helpful to give a poke on IRC (#gtk+).

Thanks for the efforts.