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 686797 - Box GPollFD to make it introspectable
Box GPollFD to make it introspectable
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: general
2.34.x
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks: 686795
 
 
Reported: 2012-10-24 14:30 UTC by Martin Pitt
Modified: 2015-02-07 17:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Box GPollFD to make it introspectable (3.10 KB, patch)
2012-10-24 14:31 UTC, Martin Pitt
committed Details | Review

Description Martin Pitt 2012-10-24 14:30:34 UTC
We want to drop the static bindings of PollFD and IOChannel in pygobject (https://bugzilla.gnome.org/show_bug.cgi?id=686795). For that we need to box PollFD, so that introspection clients can handle GPollFD structs.
Comment 1 Martin Pitt 2012-10-24 14:31:46 UTC
Created attachment 227152 [details] [review]
Box GPollFD to make it introspectable
Comment 2 Martin Pitt 2012-10-24 14:49:40 UTC
Comment on attachment 227152 [details] [review]
Box GPollFD to make it introspectable

Setting to needs-work, as at the minimum, this needs to add a bumping of glib_required_version in configure.ac.
Comment 3 Martin Pitt 2012-10-24 14:50:00 UTC
Comment on attachment 227152 [details] [review]
Box GPollFD to make it introspectable

Sorry, that was meant to go to bug 686795.
Comment 4 Allison Karlitskaya (desrt) 2012-10-24 15:06:11 UTC
I plan on dropping (or at least substantially reducing the important of) GPollFD...
Comment 5 Martin Pitt 2012-10-24 19:13:25 UTC
Ryan, is that something you plan to drop before 2.5.2? If not, would it hurt to apply this for now?
Comment 6 Colin Walters 2012-10-25 00:47:28 UTC
(In reply to comment #5)
> Ryan, is that something you plan to drop before 2.5.2?

What is 2.5.2?  You mean 2.36?

> If not, would it hurt to
> apply this for now?

Hmm, if GPollFD does get deprecated, it would be kind of useless to have the boxed type in GLib since no one could be using it, and it'd come out deprecated.

On the other hand, if we say GLib will never box this, then pygobject could safely do so internally.  That would perserve the ability to backport (as much as pygobject supports it) newer pygobject to older GLib versions.
Comment 7 Martin Pitt 2012-10-25 05:21:25 UTC
(In reply to comment #6)
> What is 2.5.2?  You mean 2.36?

Sorry, I meant 2.35.2.

> Hmm, if GPollFD does get deprecated, it would be kind of useless to have the
> boxed type in GLib since no one could be using it, and it'd come out
> deprecated.

Right, hence my question about the timeline -- if Ryan is currently working on throwing that out, it indeed doesn't make sense. If it's just an idea for "one of these days", we might apply it.

> On the other hand, if we say GLib will never box this, then pygobject could
> safely do so internally.

I was considering this, but then this would need to be replicated by the other GI clients (gjs, etc.). But I'm fine either way.
Comment 8 Emmanuele Bassi (:ebassi) 2012-10-25 09:05:02 UTC
considering that the patch is not marked as accepted-commit_now, why has it been pushed to git.gnome.org?

http://git.gnome.org/browse/glib/commit/?id=932f4250b88a50059330a9df8224feeab6b0ffd7

Martin, was that intentional?
Comment 9 Martin Pitt 2012-10-25 09:19:50 UTC
Eek, sorry. I pushed the annotation fix, then re-applied it locally. I figure it got pushed when I pushed the 3-4 branch.

I can revert it again, but to avoid commit/revert/commit again, I'll ask desrt about the timing for deprecating GPollFD.

Again, apologies!
Comment 10 Emmanuele Bassi (:ebassi) 2012-10-25 09:25:17 UTC
no worries: accidents happen all the time. :-)

reverting and the re-committing is perfectly acceptable — and in my opinion something we should never be afraid of doing.
Comment 11 Martin Pitt 2012-10-25 09:41:20 UTC
I pushed the revert. I discussed the near-tearm plans with Ryan on IRC; there is a nontrivial chance that GPollFD will be deprecated by the end of the cycle, so I think the better way forward is to just box it in pygobject itself for now.

Thanks for the discussion!
Comment 12 Martin Pitt 2012-10-25 13:40:42 UTC
I tried to box GPollFD in pygobject, but I'm afraid that won't work, at least not that easily. The GType needs to be in the .gir, and that is built by gobject-introspection. I'm trying to find a hack in pygobject.
Comment 13 Martin Pitt 2012-11-03 17:50:05 UTC
I tried harder to find a hack in PyGObject, but such a hack would be a lot worse than keeping the static GPollFD bindings. We'd need to provide a special GPollFD case in all those places which expect PollFD to have an actual GType through libgirepository. So I think we either apply this patch after all (even if it's going to be deprecated in the next glib release -- that doesn't matter, PollFD has been public API for ages and can't just disappear anyway), or I need to keep the complete static PollFD binding in pygobject.
Comment 14 Allison Karlitskaya (desrt) 2012-11-05 13:31:48 UTC
It comes to my attention that GPollFD is unlikely to entirely disappear this cycle anyway.  Even if we deprecate the GSource APIs that use it, we have GPollFD all over the place, including in the implementation of the new APIs.

If boxing it will make your life easier, then please proceed.
Comment 15 Martin Pitt 2012-11-05 14:03:37 UTC
(In reply to comment #14)
> If boxing it will make your life easier, then please proceed.

Thanks, committed then.
Comment 16 André Klapper 2015-02-07 17:01:27 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]