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

["Johannes Schmid" <jhs jsschmid de>]

Hi!

> Remove all thread stuff from the project manager and move it in the
> backend part. I suppose I can move this stuff in libanjuta and avoid
> duplicate code anyway. But, it means using thread is not mandatory and I
> don't have to split add_node and new_node function. I could keep the
> same interface than now, just that all functions, including load_node
> and save_node are called in the GUI thread.

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.

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

> Perhaps, I can rename the node_updated signal to node_loaded signal,
> emitted when the node is loaded. Note that some of its children can be
> not fully loaded.

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

> Currently, the project is automatically reloaded if the project files
> change on disk and the node_loaded will be emitted when the load is
> completed. Should we have another signal like node_changed and wait for
> a ianjuta_project_load_node call to reload the project ?

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.

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


> It's will change the interface one more time but I have already changed
> it so many time. Anyway, I would like to progress on the autotools
> backend, so I will not change it immediately.

Sure! You might want to have a look at the git and symbol-db plugin for
handling threads. There are also some convinience classes in libanjuta
(AnjutaAsyncCommand, AnjutaAsyncQuery) that might be useul.

Regards,
Johannes