[Geany-devel] Changed file saving implementation for systems with GIO

[Nick Treleaven]

On Thu, 04 Nov 2010 18:14:17 +0100
Colomban Wendling <lists.ban at 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