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

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

Hi,

Le 16/10/2010 20:47, Abderrahim Kitouni a écrit :
> that's a good idea, right now it is:
> 149 files changed, 27942 insertions(+), 25409 deletions(-)
> it's too much for a single commit.

I think so, but it needs some change to make sure that anjuta is working 
with the new interface and old backend.


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

Then, which order do you think is better and why ?


> I agree it's important to avoid regression. But what's the problem with
> the makefile backend?

I have modified the makefile backend to use the flex/bison parser but I 
haven't change it to implement the IAnjutaProjectBackend interface, so 
it doesn't compile at the moment.


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

Ok, I will remove it.


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

Ok, I need to think a bit about this. You think that adding a 
destroynotify function will be the best solution ? or do you think it 
can be done even better ?


> > - One GObject project implementing the IAnjutaProject interface.
> (it could even be the root node ;-))

Sure, but I think it's better to keep it separate in the interface.

It's more annoying for the user as he has to keep an additional project 
pointer instead of only the node pointer. One the other hand, I think it 
can be useful in the backend to keep global project data. Putting them 
in the root node could be difficult, if the node is not linked in the 
project tree. I have tried to make the project object almost useless in 
the autotool backend but I'm still afraid to find a situation where it's 
really better to have it.


Or do you think it's better to remove completely the project object ? so 
implement the IAnjutaProject interface in each node and have the root 
object emitting the changed signal.


Do you have other points that you think could be done better ?


Regards,

Sébastien