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

[Abderrahim Kitouni <a kitouni gmail com>]

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
GType).


> 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
expensive.

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.

Regards,
Abderrahim