Re: [anjuta-devel] New project interface and introspection
- From: Sébastien Granjoux <seb sfo free fr>
- To: Abderrahim Kitouni <a kitouni gmail com>
- Cc: anjuta-devel-list gnome org
- Subject: Re: [anjuta-devel] New project interface and introspection
- Date: Wed, 08 Sep 2010 21:43:41 +0200
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
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
Then, the insert function has 2 flavors, insert_after and insert_before
it's better if it's a common functions for all backend.
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.
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.
] [Thread Prev