On Thu, 04 Nov 2010 18:14:17 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Interesting change, let's see what happens now -- this said I don't use remote files often so I will probably not notice any change...
Actually I should have been clearer - this change affects local files too. I'll list the fixes now:
I should have been clearer too -- what I meant is that since I use local files, I don't face issues that GVFS (-fuse?) may have, so as far as the file saving still works, I woudln't notice :)
Let's hope so ;-) Thanks for testing.
Just to mention (I just saw that the question raised in the original thread, sorry not to have seen it before): you actually need to release GFiles with g_object_unref(). I'd thought it would be quite obvious -- you create an object, you destroy it -- but seems not :)
It wasn't clear an object was being created when I checked the docs originally. I just looked at the object hierarchy for GFile and it descends from GInterface, not GObject. Is g_object_unref () callable on a GInterface? I guess so but it would be nice to find some concrete information about it ;-)
Well, hum... GObject is a "classic" OO "language" -- it's actually a library, but still. An interface (GInterface [1]) cannot be instantiated by itself. You can only get an "instance" of a GInterface by getting an instance of an object (GObject [2]) that implements this interface.
Thanks for the links. I know OO interfaces in higher level languages, but I'm a bit ignorant about GObject. I'll try to read those pages sometime.
Also, the docs for g_file_new_for_path don't mention releasing resources, but the docs for g_file_get_parent *do* say to call g_object_unref. Both functions return a GFile. Is this a bug in the docs for g_file_new_* ?
Yes, it is. Actually I personally don't think it is a real bug because I think there is a difference between these two function:
- g_file_new_for_path() is named "new" so it suggests it creates
something new (just like g_object_new(), g_socket_new(), etc.).
- g_file_get_parent(), however, takes a GFile in argument, and returns
another one (the parent, right). It would be possible to think that the original file keeps the parent around, and so may not want the caller to release it.
And -- even if this is not really human-readable, I agree -- the return value of g_file_new_for_path() is marked as "transfer full" which means (thanks to the info popup) "Free data after the code is done". OK, the free function isn't explicitly given, and it's not really consistent to give it for g_file_get_parent() and not g_file_new_for_path().
So yes, it's kinda bug.
I wasn't looking at the latest docs, just the version Google found. The "transfer full" helps somewhat, but ideally IMO it would say to unref. Perhaps that's something GInterface users know by convention.
So, here's a (very) small patch for this.
I haven't applied it just yet, I'll wait for your reply to the above issue ;-)
I hope my explanations are clear enough for you to decide :)
Yep, applied.
Nick