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

[Abderrahim Kitouni <a kitouni gmail com>]

Hello,
              في ر، 08-09-2010 عند 21:43 +0200 ، كتب Sébastien Granjoux:
> > 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.
That's true. But I don't think it's really that bad.

> 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.
What I had in mind is that every node should watch for both "external"
changes (e.g. using a file monitor) and child nodes and emit the signal.
This way the signal is propagated up to the root node.

But thinking again about it, having the signal only in the root node and
every changed node emitting the signal on the root node is not that bad.
The question is whether we want the possibility to watch for only a part
of the tree (e.g. watching a target for changes in C flags/package
dependencies changes). This should be possible either way : one can
always connect to the signal on the root not then filter unwanted nodes
by using some is_ancestor method.


> > 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.
Ok, then it can stay as it is. The new method creates the object
(setting the parent as needed) and have a method for actually adding it
to the parent.

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

> 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.
In this case, having a different struct won't simplify things much, so
we should probably keep it this way for now.


Regards,
Abderrahim