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 761339 - [PATCH] skip gtk_widget_path_iter_add_qclass from g-ir-scanner
[PATCH] skip gtk_widget_path_iter_add_qclass from g-ir-scanner
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Language Bindings
3.19.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-01-30 21:33 UTC by Andrei Dziahel
Modified: 2016-02-05 07:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (947 bytes, patch)
2016-01-30 21:33 UTC, Andrei Dziahel
none Details | Review
skip private gtk_widget_path_iter_add_qclass from g-ir-scanner (948 bytes, patch)
2016-01-31 14:25 UTC, Andrei Dziahel
needs-work Details | Review

Description Andrei Dziahel 2016-01-30 21:33:22 UTC
Created attachment 320094 [details] [review]
patch

Instructs g-ir-scanner to skip this function as per note in gtkwidgetpath.h.
Comment 1 Matthias Clasen 2016-01-30 22:13:49 UTC
Review of attachment 320094 [details] [review]:

::: gtk/gtkwidgetpath.c
@@ +850,2 @@
 void
 gtk_widget_path_iter_add_qclass (GtkWidgetPath *path,

Mismatch between the function name and the comment (class vs qclass)
Comment 2 Andrei Dziahel 2016-01-31 14:25:16 UTC
Created attachment 320125 [details] [review]
skip private gtk_widget_path_iter_add_qclass from g-ir-scanner

Fixed, thanks!
Comment 3 Matthias Clasen 2016-01-31 19:46:26 UTC
Review of attachment 320125 [details] [review]:

Sorry for not looking in depth earlier - I think the better fix is to move that function into a new gtkwidgetpathprivate.h header, and include that where the function is used.
Comment 4 Andrei Dziahel 2016-02-02 20:20:31 UTC
I afraid I'm not so proficient with C and GTK internals to do what you're asking  me to. That's why it could take so long so the fix might even not make into 3.20. 

Moreover, my patch merely fixes someone's oversight, so how about this: my patch gets applied, GTK v3.20 gets released not being affected by this issue, and covering technical debt by implementing better fix goes to someone who introduced the issue (or his reviewer), or a volunteer. Does that make sense?
Comment 5 Matthias Clasen 2016-02-03 06:51:07 UTC
i'll get around to it myself before 3.20
Comment 6 Andrei Dziahel 2016-02-05 07:31:13 UTC
(In reply to Matthias Clasen from comment #5)
> i'll get around to it myself before 3.20

Thank you in advance! Can you post link to new issue here so we could track its' progress in haskell-gi [1]?

[1]: https://github.com/haskell-gi/haskell-gi/blob/master/bindings/Gtk/Gtk.overrides#L11