GNOME.org
 

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

Hello,

              في ث، 07-09-2010 عند 22:48 +0200 ، كتب Sébastien Granjoux:

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

Yes, we can use a floating reference, and we can also just have the node
passed to add_child with (transfer full).

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.



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.

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


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

Of course, I was talking about the actual arguments : type, file and
name.


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.

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.


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.

I don't mind either way.


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.

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.



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;

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* ?

} AnjutaProjectPropertyInfo;

And maybe we should have another type for custom properties? (btw, did
you have to use the extended struct for custom properties in autotools?)




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.

And where this flag would be set?


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

fine. Do we also need a _set function?


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

ok.


Regards,
Abderrahim
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]