Re: [anjuta-devel] New project interface and introspection
- From: Abderrahim Kitouni <a kitouni gmail com>
- To: Sébastien Granjoux <seb sfo free fr>
- Cc: anjuta-devel-list gnome org
- Subject: Re: [anjuta-devel] New project interface and introspection
- Date: Mon, 06 Sep 2010 17:22:21 +0100
في ح، 05-09-2010 عند 16:16 +0200 ، كتب Sébastien Granjoux:
I don't think this is ok. "the object doesn't belong to the caller"
means that the caller doesn't need to free it, which is wrong IMHO.
I think it's right, because the AnjutaProjectNode pointer is really used
as an handle. For the caller, this handle doesn't correspond to a memory
location and it doesn't own the memory. The caller has to manually
handles allocation and deallocation of such object. I think it's similar
to file objects in python where you have to use open and close.
I'm not sure, but I think file objects do get closed by the GC if it
isn't done explicitly.
I think (transfer full) can not work on a C structure, because the
caller doesn't know how to free it.
Yes, that's right. The structure can be marked as foreign but then
static bindings have to be written (somewhat defeating the purpose of
So we're left with a problem only in Vala. I can do some strange casts
with which I need to be careful not to lose memory, but I'd prefer
void anjuta_project_node_set_extra_data (gpointer data, GDestroyNotify notify);
(and a corresponding get_extra_data). That would completely solve the
problem of backend-specific data.
I think you don't need this GDestroyNotify function, because all nodes
have an associated AnjutaProject object which is really a GObject and
which has this destroy notification function. It's the
ianjuta_project_node_free function. You have to call your destroy
notification function here.
Yes, it's not strictly needed, I was just thinking about getting rid of
If the save function doesn't return a value (IMHO, if the save function
is in the node itself, it shouldn't return a new node) then it could be
a signal instead of a virtual method.
Yes, but it's a workaround. Do you know if this limitation is only
Theoretically, it is temporary. But in practive, it can be some time
before it's fixed in all bindings. (And personally, I think we don't
need to worry about a limitation if it's only in one binding. We can say
e.g. a project backend cannot be implemented in js for now).
And even though gnome-shell is successfully using signals as workarounds
(see ShellGenericContainer), I actually think signals are good in this
case : a Group node for example could connect to the signal on itself as
well as on child nodes, and get notified if they need to be saved.
(This still needs more thought, but you get the idea)
] [Thread Prev