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

[Abderrahim Kitouni <a kitouni gmail com>]

Hello Sébastien,

You're writing long mails faster than I can read them :-)
(when I sat to answer you first last mail, you sent a new one).

Anyway, I've seen the other mail, and I'll try to answer to both.

              في خ، 21-10-2010 عند 19:58 +0200 ، كتب Sébastien Granjoux:
> I think it would be better to use signals instead of callbacks to report 
> that the project is loaded.The advantage is that we could remove later 
> most of the IAnjutaProjectManager interface.
That's fine for me. And for the python bindings :-) since signals are
well supported in pygobject compared to callbacks. They may be slightly
slower, but I think this isn't a problem.

> All plugins can use directly the IAnjutaProject interface while the 
> project manager plugin works only as a view. The project manager connect 
> on loaded/saved/modified signals and update the project view as needed.
I think it's better to reduce the projet manager to the bare minimum : A
high level interface that helps making things easier, but otherwise
doesn't get in the way.

> Currently, all plugins have to call the load function in 
> IAnjutaProjectManager interface. Then the project manager calls the load 
> function in IAnjutaProject interface and update the project view when 
> the load is completed. If we have a loaded signal, we don't have to do 
> it through the IAnjutaProjectManager interface.
That's probably better.

> I think we need the following signals in IAnjutaProject
>
>       void ::node_updated (AnjutaProjectNode *node);
>
> Emitted when a node is changed on disk. The project manager needs to 
> connect on this signal and call ianjuta_project_load_node.
This means that the project backend needs to monitor its files, Right?
If so, it needs to be documented clearly.


>       void ::node_changed (AnjutaProjectNode *node);
>
> Emitted when a node is changed with ianjuta_project_add_node_after, 
> ianjuta_project_add_node_before, ianjuta_project_remove_node, 
> ianjuta_project_set_property, ianjuta_project_remove_property. The 
> project manager needs to connect on this signal to update the project 
> view. In addition, perhaps it can automatically call 
> ianjuta_project_save_node.
I think it should call it automatically. The project isn't something
that changes very often.


>       void ::node_loaded (AnjutaProjectNode *node)
>
> Emitted when a node is loaded. The project manager needs to connect on 
> this to update the project view. Moreover, the load function can load 
> the project only partially, so the project manager needs to check all 
> loaded node and call ianjuta_project_load_node if some nodes do not have 
> all their children loaded (or it can wait until the children are really 
> needed).
Yes, it makes sense. But then as you said, this is a low level
interface. If a plugin tries to access a node, it needs to make sure
it's loaded first (or use the package manager which should take care of
this).


>       void ::node_saved (AnjutaProjectNode *node)
>
> Emitted when a node is saved. I think it's useless for the project manager.
It may be useless for now, but I think it's better to include it just in
case.



> This new proposal will change only the ianjuta_project_load_node and 
> ianjuta_project_save_node function in the IAnjutaProject interface. I 
> prefer to keep the current IAnjutaProjectManager interface for the moment.
>
>
> After merging the newproject branch into master and checking that it's 
> working, I think it would be useful to simplify the project manager 
> interface and allow plugins to use the project interface directly.
Yes, we should make sure it works before trying to go further. It's
already too big a change.

> As I have removed the thread used to load the project, I have seen that 
> loading the project doesn't take so much time. On Anjuta it is something 
> like 2-3s on the 28s needed here to start. The new backend is a bit 
> faster, 20% but you don't feel it.
Do you mean that the current implementation doesn't use threads at all?
I think it's better this way if it isn't significantly slower.

> Sorry for this long mail again with new changes:). I think it goes in 
> the right direction for you but what do you think ?
Yes, it goes in the right direction :-) The other mail seems also fine.
Now, I'd like to start experimenting with writing random project
plugin ;-). Which reminds me of a thing : Anjuta cannot import projects
for which there is no project template, I don't like this limitation,
and I don't think it's too much trouble to fix, is it? (we may need to
add a new entry to the project plugin description that tells which
builder to use, but that's about it, right? (or should I file a bug in
bugzilla for this?)

And btw, as a user of the project manager, I think this is a good time
to use it correctly instead of just porting to the new API (or should
this just wait for the next cycle?).

Right now, I look for all vala sources and all packages in the project,
parse everything (except not found packages), and hope for the best.
Ideally, I'd like to parse only files in the "current target" (the
current target is the target that contains the currently open file, that
I can get from the document manager), and still be able to get the used
packages and the vapidirs. I don't mind parsing command line options in
VALAFLAGS in the plugin, but I'd like to have a way to get all necessary
information.


Regards,
Abderrahim