I'm clueless about introspection.

Created attachment 185683 [details] [review]
patch to wrap PangoAttrIterator as boxed

I see the following warning when generating GIR:

pango-attributes.c:1595: Warning: Pango: pango_attr_list_get_iterator: return value: Invalid non-constant return of bare structure or union; register as boxed type or (skip)

Why not simply wrap PangoAttrIterator as boxed (patch attached)?  This seems to fix the problem:

>>> from gi.repository import Pango
>>> hasattr(Pango.AttrList, 'get_iterator')
True

Indeed it should be wrapped.  G_DEFINE_BOXED_TYPE please.  Do you see any other types now working?

To be honest, even with that, the attributes themselves are still unusable since _PangoAttributeInt and similar structs are not introspected.  Hard to fix it without them being real objects.

Created attachment 185777 [details] [review]
patch to wrap PangoAttrIterator as boxed

Revised version using G_DEFINE_BOXED_TYPE.

Created attachment 185779 [details] [review]
patch to make attributes introspectable

(In reply to comment #3)
> To be honest, even with that, the attributes themselves are still unusable
> since _PangoAttributeInt and similar structs are not introspected.  Hard to fix
> it without them being real objects.

Ah, I realized that it is not that easy to make attributes introspectable.  FWIW, I tried to wrap all the attribute types.  With the attached patch I can access the attributes through pygobject like this:

from gi.repository import Pango

attrs = Pango.AttrList.new()
attrs.insert(Pango.attr_underline_new(Pango.Underline.DOUBLE))
attrs.insert(Pango.attr_size_new(45))

i = attrs.get_iterator()

x = i.get(Pango.AttrType.SIZE)
assert Pango.attr_get_size(x) == 45

x = i.get(Pango.AttrType.UNDERLINE)
assert Pango.attr_get_int(x) == Pango.Underline.DOUBLE

Nah, that's excessive.  But then again I don't know how else we can do it.  Is there a way to define a new object hierarchy in g-i other than the GObject hierarchy?

(In reply to comment #6)
> Nah, that's excessive.  But then again I don't know how else we can do it.  Is
> there a way to define a new object hierarchy in g-i other than the GObject
> hierarchy?

There isn't, no.  Though I think we probably could support this method of inheritance relatively easily, but it would need introspection and binding changes.

I have the same issue as described above when trying to port code that used 'pango.AttrWeight' which should be now 'Pango.attr_weight_new' I guess. An extended patch like the one above would do for me, I am far from knowing what the better approach is though. What is the plan on the above?

*** Bug 669371 has been marked as a duplicate of this bug. ***

*** Bug 663254 has been marked as a duplicate of this bug. ***

*** Bug 681381 has been marked as a duplicate of this bug. ***

Colin, can you suggest any other way here?  First-class "tagged-union" support in g-i would be useful in way more than just this case.  Do you see that coming soon at all?

(In reply to comment #12)
> Colin, can you suggest any other way here?  First-class "tagged-union" support
> in g-i would be useful in way more than just this case.  Do you see that coming
> soon at all?

For cairo, which is also a non-GObject inheritance system, we ended up just having hand-coded overrides.

The original gobject-introspection design did have tagged-union support stubbed out, but it was never implemented.

Yeah, it probably would have been nice for the gnome-menus rewrite I did a while back.

On the other hand it's not a trivial patch; every binding would need nontrivial updates to support it too.

Regardless, I'll clone this bug for g-i so it can be on the TODO list.

Thanks.  Where do the cairo bits live?  Want to get a feel.  Maybe we can do that for PangoAttributes too.

Is there a way to produce the missing attribute types while the bindings aren't there? I'm trying to port something to Gtk 3 and gobject-introspection, and hitting a roadblock with Pango attributes.

Created attachment 221735 [details]
Python workaround code for get_iterator

You could try to look to my python workaround code. I put these into pygtcompat.py
Working example of pango rich text editor in pitivi title editor:
https://github.com/matasbbb/pitivit/commit/da815339e5ce3631b122a72158ba9ffcc9ee4372

*** Bug 658557 has been marked as a duplicate of this bug. ***

I also hit his bug in porting the Gramps application to GTK3.

I would suggest the section of pitivi on AttrList to be added, so as to have this working.

setattr(Pango.AttrList, 'get_iterator', get_iterator)

The trick there is that http://developer.gnome.org/pango/stable/pango-Text-Attributes.html#PangoAttrFilterFunc can be used to construct an internal python list of all Attributes.

I personally have no clue how to fix this, so just know that this bug won't get fixed unless someone goes ahead and figures out the solution.

Sounds like this ticket might be dependent on bug 572415 and bug 560692?

*** Bug 725681 has been marked as a duplicate of this bug. ***

I don't have time to pay full attention to this.  If people think there's something ready to be committed please tell me so, so I can approve.  Thanks.

I don't think that hand-crafted GIR files or waiting on new annotations is going to work, since the inheritance information is stored in GObject, and there's no way to define parents with these kinds of bare GTypes. So the solution is to either switch the attribute types to real GObjects, which would change the API, or use something like Daiki Ueno's two patches, which, though it adds a handful of functions that are superfluous to the C API, provides full access to attributes using introspection.

I'll go ahead and rebase the patches to the current pango git and attach them here.

Created attachment 271143 [details] [review]
(new version) patch to wrap PangoAttrIterator as boxed

Also added a gtk-doc comment for consistency with the other boxed types

Created attachment 271144 [details] [review]
(new version) patch to make attributes introspectable

Thanks.  I like this approach.  Note that even with this you can't create attributes.  It just makes using them possible.

Also, the stuff like pango_attr_float_get_type look unimplemented to me, and I think they should be removed.

(In reply to comment #26)
> Thanks.  I like this approach.  Note that even with this you can't create
> attributes.  It just makes using them possible.

You can create them, but only through the pango_attr_*_new functions. Something like:

>>> from gi.repository import Pango
>>> prop = Pango.attr_weight_new(Pango.Weight.BOLD)
>>> print prop
<PangoAttribute at 0x1b2a0e0>
>>> print Pango.attr_get_int(prop)
700

However, since all of those functions return PangoAttribute pointers and not the subclasses like PangoAttrInt, I think the GTypes for the subclasses can be removed. There's no way to create those in a way that would be useful.

pango_attribute_init can't do anything useful in introspection, and that can be removed from the .gir with an annotation in the comments. It would also be nice to remove the constructor for Pango.Attribute() for the same reason, but I'm not sure if that's possible. I'll look into it.

> Also, the stuff like pango_attr_float_get_type look unimplemented to me, and I
> think they should be removed.

Those are needed to define the boxed GTypes and implemented by the G_DEFINE_BOXED_TYPE macro invocations.

I'll work on another patch to address these issues, and add the typed attribute getters to the pango.def file.

Thanks.  Please commit when you are done.

Created attachment 271276 [details] [review]
Fix the handling of Pango text attributes in gobject-introspection

New patch. This one removes the boxed types for PangoAttrString etc, removes pango_attribute_init from introspection, and adds the new attribute value getters and type functions to pango.def. I also noticed that pango_color_parse wasn't working right, fixed through an annotation comment.

Did anything get committed?

sadly, no. And I would be hesitant to put this new api in a stable release (says he after just adding PANGO_ANALYSIS_FLAG_IS_ELLIPSIS). Since we didn't open a devel series for pango in a while, lets merge this once we do - probably when Behdad is ready to move on the module removal and full harfbuzz embrace front.

Pango attributes still not usable in python?

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/189.