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

[Abderrahim Kitouni <a kitouni gmail com>]

Hello,
              في س، 16-10-2010 عند 14:11 +0200 ، كتب Sébastien Granjoux:
> Hi,
>
> I'm still working on the autotools backend but I'm thinking on how to 
> merge the newproject branch.
>
> This must be done before the end of November to so we can have some time 
> to check the code in the master branch.
>
> I think it's better to not merge every commit in the master branch, some 
> parts have changed several times and this history is useless. I suppose 
> I can get the difference between the master branch and the newproject 
> branch as a patch and apply it in the master branch as one commit.
>
> Then, I think it would be better to split this code in smaller changes, 
that's a good idea, right now it is:
149 files changed, 27942 insertions(+), 25409 deletions(-)
it's too much for a single commit.

> by example:
> - change IAnjutaProjectManager interface
> - change project manager plugin and updating Gbf backend
> - replace directory backend
> - replace autotools backend
>       - add anjuta token function
>       - add regression test
> - other miscellaneous changes in libanjuta
I'm not sure I'd do it in this order, but it's basically ok.

> Updating the IAnjutaProjectManager interface needs to add some code in 
> the Gbf autotools backend to list all header files of a package. The 
> advantage is that it can be done quite faste and other plugins could use 
> the new interface.
That's fine for me.

> Then the change in the project manager needs some additional change in 
> Gbf backend perhaps one or two weeks. Currently, the new makefile 
> backend is not working, so this work can be useful to keep this backend 
> using Gbf in the next release. I don't really know if it worths it 
> though. It's useful as a backup solution, in case there are too much 
> troubles with the new code (I really would like to avoid regression for 
> the user).
I agree it's important to avoid regression. But what's the problem with
the makefile backend?


> The lastest IAnjutaProject interface has the following characteristics:
> - Use floating GObject for AnjutaProjectNode. I could use normal GObject 
> if it's a problem.
That's fine, as long as g_object_force_floating isn't used.

> - Asynchronous load and save function with a callback. The load callback 
> can be called several time, could you confirm that it's not an issue for 
> python bindings ?
It is a problem, but there is an easy workaround (see my other mail).
> - One project-updated signal when the project is changed on the disk.
> - One GObject project implementing the IAnjutaProject interface.
(it could even be the root node ;-))
> - Properties are using C structures
(as long as they are registered as boxed as in my patch, this shouldn't
be a problem).


Regards,
Abderrahim