Re: [anjuta-devel] New project interface and introspection

Hi Sebastien,

Thanks for looking into this.

              في س، 04-09-2010 عند 23:04 +0200 ، كتب Sébastien Granjoux:
Hi Abderrahim,

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 
pointer correctly.

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 
object ?
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
something like:
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]