Re: [anjuta-devel] Change project property interface

[Abderrahim Kitouni <a kitouni gmail com>]

Hello Sébastien,

              في ر، 02-11-2011 عند 23:12 +0100 ، كتب Sébastien Granjoux:

> > > struct _AnjutaProjectProperty
> > > {
> > >    gchar *value;
> > >    gchar *name;
> > >    AnjutaProjectPropertyInfo *info;
> > > }
> > Does the name really need to be here (rather than in the info)?
>
> It's used for map properties. By example in autotools, it is used for 
> installation directories. You can defined custom directories for 
> installing your software by defining a variable named with the prefix 
> dir with a value corresponding to the installation dir by example
> anjutadocdir = $(docdir)

Ok.


> I have copied the current code here. But at least next is used in the 
> autotools project so it could be better to have them public. But if you 
> think it's better we can perhaps make them private.

In this case, I think they can be considered protected for now (In fact
this is how Vala implements protected fields). But the general direction
in the GObject world is to avoid accessing fields directly. Maybe we
should keep them for now.


> > Since the memory management of these two lists are done by subclasses,
> > I'd rather replace them with virtual methods.
>
> You means for both GList or for type and state too?
I mean only the lists.


> The issue of replacing both GList by a virtual method is that currently 
> AnjutaProjectNode has no virtual function. Then it's not really more 
> flexible because both lists are already created by the project backend, 
> so it can use a hash table or anything to keep the properties, the only 
> additional requirement is that it has to create these two lists.

The problem is that introspection doesn't allow to assign to a field. So
right now, it doesn't work in Python.

> If we have a virtual function, we could create the list at runtime but 
> we still have to create them and the caller should take care of freeing 
> them.
>
> The only solution to avoid creating them is to have iterator but I think 
> it's too complex for this case.

What do you mean by "them"? I assume you mean the property and property
info structs, then I don't see any advantage creating them on demand.

The problem right now is that the properties and properties_info are
stored in the AnjutaProjectNode struct but subclasses are responsible
for managing their memory. So ultimately I'd like to have the lists
stored in the subclasses themselves, and the only way that I see to
achieve this is to make the current methods virtual. I'm open to any
other suggestion.



> > Another change I'd like is to have IAnjutaProject's methods dealing with
> > properties take the property id instead of a pointer to the property.
>
> Is it ok if we provide both?

I don't think it's worth the trouble (but see below).



> Do you still have issue for properties memory allocation or is it more 
> clear now?

I'm trying to have an API that's usable both from Vala and Python, and
currently this seems challenging.

Here are all the uses of the properties API from the project manager (in
pseudocode), I think these are the only important API for now (plus
language support plugins which would need to get the compiler flags in
the simplest possible way).

in update_properties:
    foreach valid_prop in node.get_native_properties()
        prop = node.get_property (valid_prop)
        if prop.native != null
            add_entry (prop, main_panel)
        else
            add_entry (valid_prop, secondary_panel)

in on_properties_dialog_response:
    if entry is empty
        set_property (prop, null)
    else if modified
        set_property (prop, text)

in add_entry:
    /* only for map properties */
    foreach cust_prop in node.get_custom_properties()
        if cust_prop.native == prop
            /* put in a tree model */

So from what I see here, the project manager needs to:
  * get all the property infos,
  * get/set the value of a "simple" property (currently everything but
map properties),
  * get all the values for a map property,
(Am I right in thinking that it still doesn't support adding values to a
map property? If so, we should take this into account when designing the
API)
  * know whether a property has been set explicitly.

(I'm not sure whether the latter is really needed or just a consequence
of how things are currently implemented).

So a map property is currently implemented using multiple property
structs pointing to the same property info struct.

So currently the project backend needs to implement these methods:

    Property set_property (Node node, Property property, string value);
    bool remove_property (Node node, Property property);

(the latter of which being unused by the project manager) using the
following helper methods defined by the nodes:

    List<Property> get_native_properties ();
    List<Property> get_custom_properties ();

    Property get_property (Property property);
    Property get_map_property (Property property, string name);

    Property insert_property (Property native, Property property);
    Property remove_property (Property property);

I see that my suggestion to make get_*_properties virtual won't work
because {insert,remove}_property need to modify them.

The problem is that if you want to extend the Property structs in a
backend specific ways, you need the backend to take care of memory
management for them, but then you can't have them in the base class
unless you have a uniform way to free them (which isn't easy if they
aren't GObjects).

There is another problem with the current api is that it doesn't allow
one to set the native properties list (I've tried to solve this by
making it a property, but I don't really like that solution).

So here is my proposal:
  * Make get_native_properties virtual, with a default implementation
returning null (and give it a better name in the process). It should be
(transfer container) i.e. the caller needs to free the list but not its
contents.
  * Make get_custom_properties, insert_property and remove_property
virtual, keeping their current implementation; this would allow a
subclass to provide its own extended properties. The return value for
get_custom_properties would be (transfer container). I'm not sure anyone
would need the return value of the two other methods.

We could optionally add some helper methods (such as set_property and
set_map_property) and make the project backend methods and the helper
methods (the getters and the setters, if they are added) take a property
id instead of a property struct.

I hope this is reasonable, what do you think? did I miss something?

Regards,
Abderrahim