GNOME.org
 

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

Hello,
              في س، 25-09-2010 عند 11:01 +0200 ، كتب Sébastien Granjoux:

Hi,

Here a new proposal for project API


* The IAnjutaProjectBackend interface which has to be implemented by all 
project backend plugin.

[...]


This is exactly the current interface. So comparing to my previous 
proposal, the difference is that the new_project function returns a 
project object and not a root node.

Yes, that's fine.


I have tried to remove this project object, but I haven't found a nice 
way to handle changed signal, so in the end I think it's better to keep it.
+ This project object is a nice place to have this changed signal.
+ The project object can own all nodes and you free you from allocation 
stuff.
+ It can be used to easily keep global configuration.
- One disadvantage is that you need one additional argument, the project 
pointer in all node functions.

You scared me. I thought all node methods will really have an additional
argument. But looking below, I only see the load/save/add/remove have
moved back to the project interface.


I have though about using the root node as a project object, but it is a 
bit annoying:
- A pointer on the root object is not always available (you have to go 
to the top of the parent list).




* The IAnjutaProject interface is implemented by the project object.

gboolean
ianjuta_project_load_node (
      IAnjutaProject *project,
      AnjutaProjectNode *node,
      GError *err
      );

gboolean
ianjuta_project_save_node (
      IAnjutaProject *project,
      AnjutaProjectNode *node,
      GError *err
      );

These are here to actually load from/save to the filesystem. They make
sense here to avoid making assumptions about the actual project format.



AnjutaProjectNode *
ianjuta_project_add_node_before (
      IAnjutaProject *project,
      AnjutaProjectNode *parent,
      AnjutaProjectNode *sibling,
      AnjutaProjectNodeType type,
      GFile *file,
      const gchar *name,
      GError *err
      );

AnjutaProjectNode *
ianjuta_project_add_node_after (
      IAnjutaProject *project,
      AnjutaProjectNode *parent,
      AnjutaProjectNode *sibling,
      AnjutaProjectNodeType type,
      GFile *file,
      const gchar *name,
      GError *err
      );

AnjutaProjectNode *
ianjuta_project_remove_node (
      IAnjutaProject *project,
      AnjutaProjectNode *parent,
      AnjutaProjectNode *sibling,
      AnjutaProjectNodeType type,
      GFile *file,
      const gchar *name,
      GError *err
      );

AnjutaProjectNode *
ianjuta_project_set_property (
      IAnjutaProject *project,
      AnjutaProjectNode *node,
      AnjutaProjectProperty *property,
      const gchar *value,
      GError *err
      );

AnjutaProjectNode *
ianjuta_project_remove_property (
      IAnjutaProject *project,
      AnjutaProjectNode *node,
      AnjutaProjectProperty *property,
      const gchar *value,
      GError *err
      );

And these methods are just for "bookkeeping", right? I mean that, in
simple backends, they could have a default implementation that just
forwards calls to the actual node.



Comparing to my previous proposals, I have done the following changes:

- Load and save function returns a boolean instead of a node. The 
returned node was not really useful and returning a pointer means that 
you have to define the kind of transfer. It's not a big problem, as all 
objects are own by the project, returned pointer are always of type 
<transfer none> but it's not needed neither.

It was one of my unanswered questions :-) I wanted to get rid of them
from the start.


- I have replaced the new function by add_before and add_after. It's one 
additional function to write, but the code of both function is almost 
the same.

Since there are "default" implementation in the nodes, it's not that
much.


- I have added remove_property and remove_node function. I think it's 
not necessary, we can have a common function that is just setting a 
REMOVE flag in the common part of node or property data. But, perhaps it 
is easier to use if the node or the property is really removed from the 
project tree. In this case, the function is necessary because the 
project object needs to keep these removed objects somewhere else in 
order to be able to remove them from the file when the save function is 
called. What do you think?

I prefer it this way, and the backend is then free to do whatever it
wants with them.


about add_before and add_after

The return value has the <transfer none> annotation, the node 
is owned by the project. 

The problem is that even the project could be something that doesn't
have "full control" over memory.


- I have removed the free function. As far as I know, it was your main 
concern about the old API. Freeing the node or the property can be done 
in the remove function. But I think it would be better to do it in the 
save function when the removed node or property is not needed anymore. 
It must be done if the project object is destroyed too.

The problem is requiring a 'manual' free in whatever form.


- The AnjutaProjectNode object is working like AnjutaProjectProperty, so 
it doesn't need to be a GObject. I plan to keep it as a GObject at least 
until I implement the complete new interface and check that everything 
work fine. I think I should add 
anjuta_project_generic_node_new/anjuta_project_generic_node_free and 
anjuta_project_generic_property_new/anjuta_project_generic_property_free. Which 
are both taking on generic pointer to help you implementing a specific 
property and node in Python.

Well, I feel you're missing the point. I don't want a "function to help
me implement it in Python". I want a clean OO design, that makes it
easy, or even pleasant to use. (and btw, even if you end up using this,
by all means avoid adding generic to the function name, that breaks
conventions).


What do you think about this?

Well, I don't like it much. I feel you're slowly going back to your
original design.

Abderrahim
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]