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

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

Hi,

Le 07/09/2010 20:40, Abderrahim Kitouni a écrit :
> >          * ianjuta_project_backend_new_project:
> from AnjutaProjectNode :-) and you may need to add (transfer full): I'm
> not sure what's the default.

Sure.


> >          * anjuta_project_node_load:
> Is the (re)load really supposed to create a new node object? (and if so,
> you probably want to add a (transfer full) annotation. Or is just that
> reloading a node could reload a parent node instead?

This function is supposed to reload the node or one of its parent. So 
yes, transfer none can be better.


> >          * anjuta_project_node_save:
> This returns the node that actually got saved, right? how about
> transferring ownership? I guess it shouldn't.

Yes, it is like load node. So transfer none should be better too.


> >          * anjuta_project_node_new:
> obj is the parent, right? in this case how references are supposed to
> work? (which object should own the reference to the other)

If anjuta_project_node_new doesn't add the node as a child, it returns 
the node with (transfer full). The parent doesn't keep a reference on 
it. I think the best solution will be to have a floating reference like 
GtkWidget, so you don't need to call unref after adding the object to a 
parent because the parent takes the ownership.


> > AnjutaProjectNodeType type, GFile *file, const gchar *name, GError *err);
> Don't forget to register these as (GObject) properties.

I don't think it is needed to register as GObject properties. The 
GObject can be constructed with only default value and then these 
"properties" can be set afterward in the anjuta_project_node_new function.

GError *err should tell you why it's not possible to create the request 
node it's not a GObject property for sure.


> > 2. For the changed signal, it's probably needed to emit this on the
> > changed node and all its parents. So an user can connect only on the
> > root node to get all changes on the project. But in this case, we need
> > to get a node argument telling which is node that trigger the change. Or
> > is there another way to get this ?
> I don't see any other way.

Ok, so this argument is needed.

I can I emit the signal for all changed nodes and all their parents. But 
I'm afraid it will emit a lots of useless signal so perhaps it's better 
to make the root node special: implemented by a different object 
deriving from a AnjutaProjectNode and have this signal only on the root 
node. The AnjutaProjectNode will not have any signal.

So when a node is changed, the root node emit a signal with the changed 
node as argument. In this case, root node will be very close to the 
current object implmenting IAnjutaProject object.


> > 5. The name argument of the anjuta_project_node_new is useful when the
> > node doesn't correspond to a file, like target in autotool project.
> I feel this is abusing the GFile, so I prefer a separate name. And since
> it's going to be subclassed, I think even the new function is

Note that the AnjutaProjectManager use GFile to reference a node, so 
even a target node which doesn't correspond to a valid GFile need to 
have a GFile having whatever name. Unless we use AnjutaProjectNode 
object in the project manager interface too.


> > 6. I haven't decided if anjuta_project_node_new, insert the node as a
> > child of its parent.
> I think it can also cause trouble with reference counts. And since it's
> not going to be much used (g_object_{get,set}_data will only be used in
> simple cases, in all others a subclass is going to be written anyway),
> so I think there should be a separate add_child with (transfer full) for
> C convenience.

Ok, so it doesn't looks strange for you if anjuta_project_node_new get 
the parent as argument and return a child node which is not attached. 
add_child need to be called later to add it to the same parent. It can 
fail if you try to attach the child to another parent.


> > 7. I need to change the way properties are handled. Probably I can have
> > two lists, one for default properties and one for custom properties. The
> > properties object will correspond to the data. Like node, it could need
> > some specific backend information, so I could make it a GObject too but
> > there is probably more properties. I will think about this later.
> I think it's not necessary if we are going to "remove"
> AnjutaProjectProperty and use AnjutaProjectPropertyInfo everywhere

Ok, so AnjutaProjectPropertyInfo stay a C structure and a 
AnjutaProjectNode has 2 pointers on list of AnjutaProjectPropertyInfo, 
one static for all possible properties and one for custom properties.

The C structure for a property can be

typedef struct
{
        gchar *name;
        AnjutaProjectValueType type;
        gchar *value;
        GList *override;
} AnjutaProjectPropertyInfo;


Then we have the following functions

* gboolean anjuta_project_node_set_property (AnjutaProjectNode *obj, 
AnjutaProjectPropertyInfo* property, const gchar *value, GError *err)
This is a virtual function.

* gboolean anjuta_project_node_remove_property (AnjutaProjectNode *obj, 
AnjutaProjectPropertyInfo* property).
This function don't need to be a virtual one, as it just need to set a 
flag on the removed property.

* GList anjuta_project_node_get_all_valid_properties (AnjutaProjectNode 
*obj)
This function can return the static GList of all properties so it will 
have (transfer none).

* GList anjuta_project_node_get_properties (AnjutaProjectNode *obj)
This function can return the list of custom property, has this list is 
modified only by set_property method it can have (transfer none).



> Anyway, I like this new interface, we must take care of reference
> handling and registering properties and we should be fine.

After replying to your questions, I'm not convinced it's really easier 
to use than the previous one. If you have better ideas, you can propose 
more changes.

Regards,

Sébastien