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

[Abderrahim Kitouni <a kitouni gmail com>]

Hello,
              في ن، 04-10-2010 عند 21:57 +0200 ، كتب Sébastien Granjoux:
> > What I meant is functions like anjuta_project_group_get_node_from_file,
> > (and your proposed anjuta_project_generic_node_new) : we don't actually
> > have an AnjutaProjectGroup class, so these function end up incorrectly
> > namespaced in G-I as Anjuta.project_group_get_node_from_file
>
> So it needs to be renamed anjuta_project_node_get_group_from_file. I 
> have no problem with this.
Maybe anjuta_project_node_get_node_from_file, but you see the idea.


> I haven't found a good way to handle this.
>
> 1. Remove the AnjutaProjectNode* return value:
> It's an easy solution. It needs to change the class generator and the 
> project wizard plugin. Both plugins still need to creates nodes, so they 
> could connect on the project and get the new nodes. But, they cannot 
> really know if the new nodes has been created by the add function.
I think a callback approach is better (see below)

> 2. Create a proxy node:

> 3. Call ianjuta_project_add_node if possible:
These do seem like far from trivial to implement.

> 4. Call ianjuta_project_add_node immediately:
> The backend needs to take care that the ianjuta_project_load or 
> ianjuta_project_save function can be running. It's always possible, the 
> backend can keep the add operation in a queue if the worker thread is 
> running to do it when the thread is completed. But I'm annoyed to let 
> this on the backend side.
The fact that the project backend can be called from two different
threads is a bit scary. Right now, the GUI thread only calls
get_node_info which is supposed to return a constant list (and even
then, the python GIL can get in the way) but having more 'multithreaded'
calls is asking for trouble.


> 5. Add ianjuta_project_new_node:
> It was the solution used in the previous interface. It's not very 
> different from the solution 4. It's just more easier to understand that 
> ianjuta_project_new_node should be able to work even if the load or the 
> save function is running in another thread. There is an issue to define 
> if the new node is owned by the project (should be kept in a special 
> list), the caller or floating.
This can reasonably be done, making new_node another 'constant return'
method. However, the node should definitely be owned by the caller : it
makes it easier to avoid memory leaks (at the cost of one added
g_object_unref call).

> Do you have another solution?
How about...?
6. Make the function async, that is, pass a callback to the pm method,
and the callback will be called when the node is ready to be used. The
problem with this approach is that it can make things look like the user
command was ignored when saving/loading takes too much time.

> I don't know. It's sure that I need to use thread in the project 
> manager. It's especially useful to reading package content, there are 
> lots of files and it takes perhaps one or two minutes on anjuta project 
> here (There are lots of debugging messages too).
This seemed like a lot of wasted time for me. What do you mean exactly
by 'reading package contents'?

But thinking again about it, maybe we can do without threads. This may
look like a crazy idea, but it may work after all. It seems that the
autotools backend reads one makefile at a time, so it might be not that
bad (maybe by using async gfile methods for not blocking in I/O, but the
rest should be fine).

(but maybe it doesn't work like this and I need to spend another weekend
with this to get a better idea of the whole thing).

> It's a problem that I have with Python and other script languages. A 
> lots of things are much more easy to do but a few things are really 
> difficult and I don't know it before I bump in it.
+1

> > Because of this, I'm about to give up writing a project backend in
> > Python,
>
> It's a bit a pity. I could move all thread functions in the backend so 
> it's will not be mandatory. But I'm afraid it will make it much more 
> difficult to do.
Right. What would be even more difficult is changing the current
implementation.

Regards,
Abderrahim