Re: [anjuta-devel] Change project property interface

[Sébastien Granjoux <seb sfo free fr>]

Hi Abderrahim,


Le 21/12/2011 13:58, Abderrahim Kitouni a écrit :
> Well, it does. Functions like anjuta_project_node_insert_property_info
> clearly create the nodes added to the list, and this is the only way to
> add PropertyInfo's to a node (if we remove the gobject property).

Yes, I don't use this function. I'm setting directly the properties_list 
member. I have added it for you. I think it would be better to set the 
whole properties info list in one call allowing you to reuse the same 
list for several nodes.


When loading nodes, I could have temporary properties which could have 
temporary PropertiesInfo structure. It's the case when the properties 
are declared before the target in Makefile.am. By example if you have
  test_CFLAGS = -O0
  bin_PROGRAMS = test

A dummy CFLAGS property is added to a dummy node until we find the 
target node test. These dummy properties have a temporary property info 
which is free with the dummy node. To make the distinction, I have added 
a flag ANJUTA_PROJECT_PROPERTY_STATIC which is cleared for such property.


> This could be done in a generic manner by using the user_data field, but
> I think it should be possible to keep the current C plugins unchanged.

Even if you use the user_data field, you need to have a function to free 
the data correctly.


> The problem is that the list is a field in AnjutaProjectNode, and as
> such needs to be freed from there. And while things like you propose are
> doable in Vala (we need however to tweak generated bindings), it is
> impossible to do for dynamic languages.

To be clear, even if I'm discussing quite a lot, I would like to make it 
work with dynamic languages and without too much tricky things in Vala.


> Try to think in Python: the info list is a Python list, and in order to
> get this list to the node object (even through a possible
> set_properties_info) it needs to be converted to a GList, then either
> its ownership is taken by the node object, or it is freed just
> afterwards. So the node object needs to own at least the list (even
> though it doesn't need to own its contents).

How does it work if the object doesn't own the content? the content is a 
Python structure by example, so it should be converted to a C structure no?

In my idea, the properties info list argument is like the gpointer data 
argument of g_list_append by example.

I have looked as instrospection documentation, it has improved since 
last time I read it. Indeed, the argument should be marked as transfer 
none but we expect that the caller keep a valid copy of the parameter. I 
think it triggers issues similar to call back which is tricky.


Anyway, I think we can make it works exactly as you want. Having both 
the properties and the properties information content and list belonging 
to the node. As I have explained above, it's already working like this 
when loading a node.


Then, I'm still a bit annoyed that the properties info list will be 
duplicated in project backend not written in C. I think one solution for 
this is to create a new object which is a AnjutaPropertyInfoList. For C 
it could be just a GList so it cost nothing, but for a Python backend it 
can be a opaque object that the Python backend has to create, fill with 
needed data and pass to the project node. So we could have functions like

AnjutaProjectPropertyInfoList *anjuta_project_property_info_list_new ();
void anjuta_project_property_info_list_free (
                AnjutaProjectPropertyInfoList *list);
void anjuta_project_property_info_list_add (
                AnjutaProjectPropertyInfoList *list,
                AnjutaProjectPropertyInfo *info);

We could have (transfer full) for the info parameter of list_add 
function and (transfer none) when this list is used to initialize a new 
node. So it's up to the backend to keep all property information lists 
with the node using them as long as the backend is running. What do you 
think?

I could be a bit more complex to use (one additional object) just to 
gain memory perhaps we don't care.



Regards,

Sébastien