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

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

Hi Johannes,

Le 06/10/2010 15:44, Johannes Schmid a écrit :
> This sounds like a good idea to make threading optional. Some backends
> might not need it as they don't read the big amount of files the autotools
> plugin needs. Still they probably should use threads because blocking IO
> is a bad idea but if it is optional it is easier to implement a basic
> support.

My first idea was to run the complete project backend in a thread to 
avoid race hazards. But it's not completely possible and there is still 
a problem if the backend access to global anjuta data or with Python 
lock. So let's change the interface again and make threading optional.


> > It must be possible to use threads to implement these functions. So
> > returning from ianjuta_project_load_node doesn't mean that the node is
> > loaded (and same for ianjuta_project_save_node).
> The GIO API uses that approach alot including GCancelables and stuff like
> that. It isn't trivial to implement but doable.

Yes, I'm not sure it's necessary to have all this for a project. Having 
just a signal when the project is loaded (or partialy loaded) should be 
enough. We can use callback but I think signal is better here.


> Again, looking at the GIO API: Traversing to children should be async too,
> like it is in a GFileEnumerator

I think it's different because when load a project you normally want to 
load all children (I means all directory below the project directory). 
When you list all files of a directory, it's not obvious that all files 
in sub directories are needed too.

I think it's better to be able to list all children with simple 
synchronous functions like anjuta_node_foreach or anjuta_node_next.


> The question how we handle when there are pending writes to the project
> files when they change on disk. I would assume we ignore our pending
> request.  Changing files manually and in anjuta should not be done at the
> same time anyway. But it can happen in a git pull --rebase for example.
>
> Of course, if the user edits the Makefile.am manually the tree should just
> update as it is know. There will always be situation where we cannot
> support a certain feature.

I have tried to write only the modified file to minimize the possible 
conflict but I don't plan to do anything for this at the moment.

It's working like an edited file, the content of all project files are 
kept in memory, so by doing nothing you will loose some changes. Later, 
I can add some checks to display a dialog and ask which changes should 
be discarded, like in the editor.

I don't think it's a really big problem. If the user run git pull and 
add a new target at the same time, I don't know what's happen.


> > Do we need a node_saved signal ?
> Hmm, I don't see an immediate need for it. We can implement it later if we
> need it.

Ok, so I think we need only:

* node-loaded (AnjutaProjectNode *node, gboolean finished)
Emitted when a node has been reloaded, finished will be TRUE if all 
nodes have been reloaded. Typically you get this signal after calling 
ianjuta_project_load_node with node equal to the loaded node and then if 
finished is FALSE on all children nodes those have not been completely 
loaded the first time. The signal emitted on the last child will have 
finished to TRUE. With the finished argument, this can be a callback too.

* node-updated (AnjutaProjectNode *node)
When the corresponding node need to be reloaded from the disk.


Regards,

Sébastien