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: Sun, 05 Sep 2010 14:05:49 +0100
Thanks for looking into this.
في س، 04-09-2010 عند 23:04 +0200 ، كتب Sébastien Granjoux:
I have compiled anjuta with introspection enable and try it a bit. I
have get a few troubles to build it but it seems to work. I understand a
bit better how it's working.
I think the current interface can work if we add (transfer none)
annotation on all AnjutaProjectNode object returned by various
functions. It will means the object doesn't belong to the caller which
is the case, because all modification must be done through the provided
functions. I think another option is to consider that all
AnjutaProjectNode are constant.
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.
By using this workaround, we take the risk of causing memory leaks, so
I'd prefer something else.
I have created a simple anjuta_project_node_new and
anjuta_project_node_free function and it works without any warnings. So
I think introspection works fine with such object, it can handle void
Then they are several open points.
1. I don't know how to add specific data. By example in python if I have
an object that I want to associate to this AnjutaProjectNode structure
what should I send as argument. Is a gpointer enough to keep this python
Yes, a gpointer parameter gets passed a python object as is, you just
need to add some get_extra_data function or something.
But thinking again about it, the problem isn't in python since the
wrapper (the python object that is exposed from the bindings) can hold
the data. (and this should be true for other dynamic languages)
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.
2. I can try to check what is the difference between creating a
AnjutaProjectNode like it is now and a GObject representing a node. If I
use the second choice, it would be nice to have different GType for
group node, source node and so on. But all could have different save
functions, it is possible or is it considered as virtual functions ?
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.
3. I need to check what is the difference between using GObject or the
current structure for project node. Indeed currently, you need to
explicitly call the _new and _free function. Using GObject, the new
function is needed but I think the free function is needed too to
release the last reference. I'm not sure it makes a real difference but
I need to think more about this.
GObject has finalize/dispose, and code for freeing things should go
there. (and we could even use g_object_new directly if we can get the
4. The gir scanner understand the AnjutaProjectNode correctly but get a
trouble with AnjutaProjectProperty. AnjutaProjectNode get the right name
Anjuta.ProjectNode while the property keep the C name,
AnjutaProjectProperty. I don't know why, I will try to investigate a bit.
Seems fine here, I don't know.
btw, I've (finally ;-p) understood how properties work. It seems a bit
complicated and relies on the fact that lists are doubly-linked.
Wouldn't it be better to keep 2 lists, one for the default properties
and one for the overriding ones? That would be simpler, but may be more
I'm not sure about this, but I feel that a list should be just a list,
even if that would require more copying from backends written in dynamic
languages (as they have their own lists).
Anyway, need to think more about this.
] [Thread Prev