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

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

Hi Abderrahim,

Le 12/10/2010 11:36, Abderrahim Kitouni a écrit :
> > It's not true for a source file used in several targets. Each target
> > will have its own source node, but all these source nodes will have the
> > same GFile. It can be a different GFile object but corresponding to the
> > same file. But I hesitate to consider as different two GFile objects
> > corresponding to the same file.
> I see. But then, how is ianjuta_project_manager_get_parent supposed to
> work?

We can have a different GFile for each source (referring to the same 
file) and then compare only the address (without using g_file_equal) of 
the GFile object to find the node containing exactly the same GFile 
object. The comparison is much faster but I think cleaner solutions 
exist (but perhaps not better is there are other disavantages).



> So what's exactly needed for this?
> I'm not sure, but it seems that only changes needed in IAnjutaProject
> interface is removing the return value of all functions but get_root and
> get_node_info, and adding signals: property-updated and maybe
> node-{added,removed,saved}. What do you think?
>
> Or should we use callbacks instead? Using callbacks makes it easier to
> send multiple request to the backend and then process responses (there
> isn't the problem of "which request triggered this response?"), but if
> all that's needed for further processing is the new/updated node, it
> will be easier to just use signals.

I don't really know. There are only two functions giving problem 
anjuta_project_load_node and anjuta_project_save_node. I think all other 
functions can be implemented synchronously in the GUI thread, so they 
keep their return value.

In the worst case, if anjuta_project_add_node takes really too much 
time, this function can just create a temporary node so the GUI can have 
a node and play with it and only create the node in save function. It's 
more work for the backend but it's much better to use and I don't think 
it's really needed.

I propose the following changes:

* void anjuta_project_save_node (IAnjutaProject *project, 
AnjutaProjectNode *node, IAnjutaProjectSaveCallback callback, gpointer 
user_data, GError **err);

with typedef void (*IAnjutaProjectSaveCallback) (AnjutaProjectNode 
*node, gpointer user_data, GError* err);

It is a callback, similar to what we have in the IAnjutaDebugger interface.

I think a simple saved signal, like in IAnjutaFileSavable, is not enough 
because I want to avoid any graphical stuff in the backend but still be 
able to display an error message.

I think we can consider that the callback is always called, even if 
there is a failure at the very beginning, by example the node doesn't exist.

The GError** parameter of save_node is completely useless, but added 
automatically by the anjuta idl compiler.

As the parameter is a GError * and not a GError **, the error 
information always needs to be created.

We could implement something more complex like in GIO, with GCancellable 
and _finish function. It allows to cancel an operation and the GError is 
not created if not needed, but as it needs to create a GAsyncResult, 
it's probably more work anyway. Moreover I think the GError is almost 
always useful in our case.



* void anjuta_project_load_node (IAnjutaProject *project, 
AnjutaProjectNode *node, IAnjutaProjectLoadCallback callback, gpointer 
user_data, GError **err);

with typedef void (*IAnjutaProjectLoadCallback) (AnjutaProjectNode 
*node, gboolean complete, gpointer user_data, GError* err);

It is a callback, like anjuta_project_save_node, so same remarks apply.

The difference is that the callback can be called several time until 
complete is TRUE. The goal is to already send back data (call the 
callback) even if all nodes are not loaded. I hope it doesn't cause 
troubles for the python bindings.


* void ::node_changed (gpointer node)

I keep the same signal emitted when the data on the disk are changed. 
The project manager at least need to connect on this signal to call the 
load function.

What's happen if we have modified the project in Anjuta but get this 
signal before saving the changes? I'm not sure it's very important, 
displaying an error message like the editor seems to much, moreover it 
can give troubles if the changes are originally requested by Anjuta.



> Yes, but right now, no other plugin can access the backend directly. So
> we need to add a get_current_project method to the project manager.
> But then, a potential problem with signals is that one plugin may get a
> signal that's not related to the operation it has requested, and thus
> wrongly assume its operation has finished.

My idea, is to keep the project manager interface for the moment, just 
keeping in memory we could remove it if the project interface fits. I 
think the main advantage would be to replace GFile by AnjutaProjectNode.


> I've also attached a couple patches to the following bug (mostly g-i
> related) : https://bugzilla.gnome.org/show_bug.cgi?id=631952

Ok, I will look at this.

Regards,

Sébastien