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 551271 - deprecate GRelation
deprecate GRelation
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-09-07 19:09 UTC by Havoc Pennington
Modified: 2010-06-24 02:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Havoc Pennington 2008-09-07 19:09:28 UTC
Has anyone ever used GRelation? Might be worth cleaning out in 3.0
Comment 1 Matthias Clasen 2008-09-07 21:19:57 UTC
Another candidate is GCompletion. 
The GHook stuff seems to be used only in gsignal.
Comment 2 Paolo Bacchilega 2010-06-21 19:40:58 UTC
I vote for keeping GHook, I use it in gthumb as part of the extension mechanism.
Comment 3 Bastien Nocera 2010-06-21 22:01:11 UTC
(In reply to comment #2)
> I vote for keeping GHook, I use it in gthumb as part of the extension
> mechanism.

libpeas? introspection?
Comment 4 Stef Walter 2010-06-21 22:44:26 UTC
I really, really wanted to use GRelation as what it was intended to be.

However with the fields limited to 2, it's not much use :(
Comment 5 Mikkel Kamstrup Erlandsen 2010-06-22 06:30:32 UTC
I wanted to use GRelation as well at least on a handul occasions, but as Stef also did I had to abandon it because of the restriction to 2 fields. Perhaps one day we'll see a full featured Gee.Relation...

GCompletion seems to have very limited use: http://google.com/codesearch?q=\bg_completion+-file%3Aglib (but still some use).

And a little more usage of GHook, but not much: http://google.com/codesearch?q=\bg_hook+-file%3Aglib

So, all in all, no protest on my account :-)
Comment 6 Paolo Bacchilega 2010-06-22 07:25:41 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > I vote for keeping GHook, I use it in gthumb as part of the extension
> > mechanism.
> 
> libpeas? introspection?

yes, but I don't have the time to port it to libpeas for now.
Comment 7 Emmanuele Bassi (:ebassi) 2010-06-22 07:44:55 UTC
deprecation != removal.
Comment 8 Paolo Bacchilega 2010-06-22 08:41:52 UTC
(In reply to comment #7)
> deprecation != removal.

right, but if I'm correct deprecation means that it will be removed at some point in the future.  Anyway if you think that GHook it's not useful enough to keep it in glib I can just copy it locally when it will be removed.
Comment 9 Colin Walters 2010-06-22 14:02:58 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > deprecation != removal.
> 
> right, but if I'm correct deprecation means that it will be removed at some
> point in the future.  

There are no plans for GLib 3.0 (i.e. no binary incompatible library release), as that would be an enormous train wreck.
Comment 10 Paolo Bacchilega 2010-06-22 15:35:01 UTC
what's the point of deprecating it then, considering that there is no suggested replacement?
Comment 11 Matthias Clasen 2010-06-22 18:21:00 UTC
The point is to state that these apis have not been 'successful', and are not widely used, and will not receive feature additions and heavy bug-fixing. 

And if there ever comes a time to rev the glib abi, they will go.
Comment 12 Paolo Bacchilega 2010-06-22 19:01:19 UTC
ah ok, then I have no objection to the deprecation.
Comment 13 Matthias Clasen 2010-06-24 02:37:47 UTC
I've done this now for GRelation and GCompletion.