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


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.



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