Re: [anjuta-devel] Scons Support in Anjuta

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

Hi,

Le 01/09/2010 18:43, Abderrahim Kitouni a écrit :
> Which brings us to another question: how to "copy" a ProjectNode?
> Actually copying is incorrect for the reasons you describe. But how
> about reference-counting?

It's not done currently because it was not needed but it can be done.


> and what about the proxy nodes? can they be
> used as "copies"? (not that anyone is going to copy a node, but just to
> be sure things won't break if someone does.)

I don't think so.

I need proxy, because the backend is running in a different thread. When 
the backend load a node, this node will be modified so the GUI shouldn't 
use it.

The proxy node is use by the GUI as a replacement of the node which is 
loaded by the backend. The proxy copy only the common data of the node, 
not the specific data needed by the backend so it's not a full copy.


> Replacing:
> typedef GNode AnjutaProjectNode;
> with:
> typedef struct _GNode AnjutaProjectNode;
> is enough to make GI think it's unrelated to GNode, and won't affect C
> backends. So I think we should go with this.

Ok.


> Making it a number doesn't make sense if the backend is supposed to
> allocate it.

The backend is not supposed to allocate it. It is an identifier. The old 
gnome build system was using a perl script to read the project files and 
this AnjutaProjectNode * was a string something like "group:src" or 
"target:anjuta". It's working fine, the only issue is that each time you 
want to work on a node, you need to look up in a hash table to get the 
real object. If needed we can use a string representing the pointer in 
hexadecimal. It will avoid the hash table lookup.

It's the same thing than the FILE* structure returned by fopen. Here the 
backend has to call anjuta_project_generic_node_new instead of fopen and 
ianjuta_project_node_free instead of close.


> What I meant is that it's better to switch to GObject rather than
> reinventing the same mechanism. But I think I'll go for 1. or 2. above.

The mechanism is just an addition when allocating some memory so I don't 
see the issue to redo it. Then, switching to GObject means to rewrite 
almost all GNode functions, it's much more work.

Anyway, if using GObject is not noticeably slower than the current 
structure and really help. It can be done, it's more work but it doesn't 
matter so much.


> (and just to see how scary are warnings I was talking about, and can
> even get to the state where there are actually bugs).

I'm not really afraid about warning. But indeed, it's better to avoid 
them. I need to check how it's working because it's difficult to tell 
you that everything should be fine without some real proposal :)

> * use the struct _GNode trick so that only C backends are aware that its
> actually a GNode.

Ok.

> * add _new and _free functions:
> AnjutaProjectNode *anjuta_project_node_new (AnjutaProjectNodeType type,
>                                              AnjutaProjectProperty *properties,
>                                              GFile *file,
>                                              gchar *name,
>                                              AnjutaProjectNodeState state);
> (I'm thinking of adding a gpointer user_data at the end).

That's fine but then you need a hash table to associate your specific 
data to each node.


> * Register it as a boxed (maybe using anjuta_project_proxy_new instead
> of a real copy and making _free aware of this).

If you don't have any specific data a proxy node can be enough.


> This should bring it to a state where it's useable, and the next step
> would be AnjutaProjectProperty.

There is the same issue with AnjutaProjectProperty. But the goal is to 
make it better than useable, if I really need to change it I will do it 
including the C part if needed.

Do you plan to put your change somewhere where I can get it ? So I can 
compile it and understand better the issues.

Regards,

Sébastien