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 646788 - pango attributes / get_iterator not introspected
pango attributes / get_iterator not introspected
Status: RESOLVED OBSOLETE
Product: pango
Classification: Platform
Component: language-bindings
unspecified
Other Linux
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
: 658557 663254 669371 681381 725681 (view as bug list)
Depends on:
Blocks: 632113 646863 681409
 
 
Reported: 2011-04-05 08:38 UTC by jessevdk@gmail.com
Modified: 2018-05-22 12:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to wrap PangoAttrIterator as boxed (1.81 KB, patch)
2011-04-11 06:18 UTC, Daiki Ueno
none Details | Review
patch to wrap PangoAttrIterator as boxed (1.62 KB, patch)
2011-04-12 08:13 UTC, Daiki Ueno
none Details | Review
patch to make attributes introspectable (12.76 KB, patch)
2011-04-12 08:16 UTC, Daiki Ueno
none Details | Review
Python workaround code for get_iterator (4.01 KB, text/plain)
2012-08-19 07:54 UTC, Matas Brazdeikis
  Details
(new version) patch to wrap PangoAttrIterator as boxed (1.66 KB, patch)
2014-03-06 21:06 UTC, David Shea
none Details | Review
(new version) patch to make attributes introspectable (11.03 KB, patch)
2014-03-06 21:06 UTC, David Shea
none Details | Review
Fix the handling of Pango text attributes in gobject-introspection (10.74 KB, patch)
2014-03-07 22:09 UTC, David Shea
none Details | Review

Description jessevdk@gmail.com 2011-04-05 08:38:08 UTC
At least in python, Pango.AttrList.get_iterator is not available. I did not investigate yet exactly why not (it appears in the GIR).
Comment 1 Behdad Esfahbod 2011-04-05 23:29:34 UTC
I'm clueless about introspection.
Comment 2 Daiki Ueno 2011-04-11 06:18:38 UTC
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
Comment 3 Behdad Esfahbod 2011-04-11 15:14:03 UTC
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.
Comment 4 Daiki Ueno 2011-04-12 08:13:31 UTC
Created attachment 185777 [details] [review]
patch to wrap PangoAttrIterator as boxed

Revised version using G_DEFINE_BOXED_TYPE.
Comment 5 Daiki Ueno 2011-04-12 08:16:51 UTC
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
Comment 6 Behdad Esfahbod 2011-04-12 22:43:20 UTC
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?
Comment 7 Colin Walters 2011-04-26 18:43:59 UTC
(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.
Comment 8 Simon Schampijer 2011-11-03 13:37:30 UTC
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?
Comment 9 Martin Pitt 2012-02-08 04:49:44 UTC
*** Bug 669371 has been marked as a duplicate of this bug. ***
Comment 10 Behdad Esfahbod 2012-08-07 19:37:13 UTC
*** Bug 663254 has been marked as a duplicate of this bug. ***
Comment 11 Behdad Esfahbod 2012-08-07 19:37:18 UTC
*** Bug 681381 has been marked as a duplicate of this bug. ***
Comment 12 Behdad Esfahbod 2012-08-07 19:39:19 UTC
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?
Comment 13 Colin Walters 2012-08-07 20:24:28 UTC
(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.
Comment 14 Behdad Esfahbod 2012-08-07 20:31:33 UTC
Thanks.  Where do the cairo bits live?  Want to get a feel.  Maybe we can do that for PangoAttributes too.
Comment 15 Thomas Kluyver 2012-08-19 02:38:08 UTC
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.
Comment 16 Matas Brazdeikis 2012-08-19 07:54:13 UTC
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
Comment 17 Behdad Esfahbod 2012-08-25 20:14:06 UTC
*** Bug 658557 has been marked as a duplicate of this bug. ***
Comment 18 Benny Malengier 2012-12-28 16:30:29 UTC
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.
Comment 19 Behdad Esfahbod 2012-12-29 23:34:12 UTC
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.
Comment 20 Simon Feltman 2014-01-08 20:39:35 UTC
Sounds like this ticket might be dependent on bug 572415 and bug 560692?
Comment 21 David Shea 2014-03-05 22:51:39 UTC
*** Bug 725681 has been marked as a duplicate of this bug. ***
Comment 22 Behdad Esfahbod 2014-03-06 10:20:39 UTC
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.
Comment 23 David Shea 2014-03-06 21:03:48 UTC
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.
Comment 24 David Shea 2014-03-06 21:06:14 UTC
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
Comment 25 David Shea 2014-03-06 21:06:57 UTC
Created attachment 271144 [details] [review]
(new version) patch to make attributes introspectable
Comment 26 Behdad Esfahbod 2014-03-07 19:14:11 UTC
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.
Comment 27 David Shea 2014-03-07 20:08:00 UTC
(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.
Comment 28 Behdad Esfahbod 2014-03-07 21:05:47 UTC
Thanks.  Please commit when you are done.
Comment 29 David Shea 2014-03-07 22:09:29 UTC
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.
Comment 30 jessevdk@gmail.com 2014-09-04 14:42:56 UTC
Did anything get committed?
Comment 31 Matthias Clasen 2014-09-04 14:46:39 UTC
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.
Comment 32 Cédric Bellegarde 2018-01-21 12:01:03 UTC
Pango attributes still not usable in python?
Comment 33 GNOME Infrastructure Team 2018-05-22 12:59:29 UTC
-- 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.