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

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

Hi,

Le 08/09/2010 17:44, Abderrahim Kitouni a écrit :
> But what I meant in my question is that we should be careful about
> reference cycles: both the parent and the child node keep a reference to
> the other, but only one should be owned.

I think the parent owns the child. I think that removing the free 
function has some advantage but add more complexity.


> then it shouldn't be called _new, a _new function creates the object and
> sets its properties.

Well, I don't care if it is called with another name but it can be 
strange to have an object without a new function.

Then we can add properties for all arguments except GError one. The 
issue with properties is that it slows the object creation significantly.


> But how would the root node know some node has changed? We need to
> propagate the information somehow, e.g. by using a virtual method that
> calls the parent node's method : this should be faster (but is this
> significant? how deep would be a node in a typical project?), but a bit
> ugly IMHO.

Perhaps, I should change this name. Currently, the signal is named 
updated and is emitted when the file corresponding to the node is 
changed. It is needed because when a node is changed (in the GUI) the 
change is saved just after and this signal is used to reload the 
project. The project reloaded automatically when the file are changing 
without taking care if it's due to a change in Anjuta or outside.

In this case, each node adding GFileMonitor can keep a pointer on the 
root node, there is no need to look for it on each change.


Then, I don't know if it's needed to emit a signal when the node is 
changed by some other function inside Anjuta. If yes, I suppose we can 
find the root by looking at the parent of each node up to the top. I 
think a normal project could have 4 or 5 level of hierarchy, even if 
it's 10 or 20 it isn't be very long.


But if you think it's ugly what do you prefer ? That each node emits a 
changed signal and someone wanting to get all changes has to connect on 
every node ? Or that each node emits a changed signal for itself and all 
its parent ?
I have looked a bit in GtkWidget signals which have a similar hierarchy, 
I have seen only signal emitted only one time by the widget getting the 
event, the changed node in our context.


> Maybe the _new shouldn't take the parent, the add_child is responsible
> for adding it.
> Another possibility is to use something like a create_child_node, that
> takes the a GType plus the arguments listed above, creates a node and
> adds it to the parent.

I think it's useful to have the parent in the new function, so the 
backend can check that the node will be valid as a children. This 
function can be renamed create_child. But I think it's better to not add 
the new node as a child.

The first thing that you should probably do with a new node is to remove 
it because you will have to save it which is done in a different thread. 
So this node shouldn't be accessible (in the project tree) until it is 
saved.

Then, the insert function has 2 flavors, insert_after and insert_before 
it's better if it's a common functions for all backend.

> > typedef struct
> > {
> >           gchar *name;
> >           AnjutaProjectValueType type;
> >           gchar *value;
> >           GList *override;
> I think this should be changed: a GList shouldn't be used as a node, but
> as an entire list. Can't this be just a AnjutaProjectPropertyInfo* ?

Yes, it can. I have thought that it can avoid to search the complete 
list but I don't see such case so indeed it's better.


> And maybe we should have another type for custom properties?

It's possible, typically the custom properties need the override 
parameter corresponding to the valid property. While the non custom 
property don't need it.


> (btw, did
> you have to use the extended struct for custom properties in autotools?)

Yes, in autotools backend all properties have additional fields, like 
it's done for node. Even the possible properties have them.

For the possible properties, there are information like the token 
identifier of the parser corresponding to the property and the position 
if it is in a list.
For the custom properties, you have in addition a pointer to the token 
corresponding to the value of this property.


> > * gboolean anjuta_project_node_remove_property (AnjutaProjectNode *obj,
> And where this flag would be set?

In the state data of the project node.


> Do we also need a _set function?

Yes, I have described the set_property above with the other functions 
because it is a virtual function, while all get functions can be common 
for all backend.

Regards,

Sébastien