GNOME Bugzilla – Bug 666679
Improvements to the new project API
Last modified: 2011-12-22 21:16:18 UTC
Here are my proposed changes to the new project API, and an example for using it from vala (I'd like to know your opinion on this use). With these I think it's possible to write project backend plugins in both python and vala (I'll push the updated buildj plugin to bitbucket shortly, and I'll try to write a sample python plugin)
Created attachment 204050 [details] [review] libanjuta: set the info for the default value of a property
Created attachment 204051 [details] [review] libanjuta: add gir annotation for anjuta_project_node_insert_property_info
Created attachment 204052 [details] [review] libanjuta: don't register project property lists as GObject properties
Created attachment 204053 [details] [review] libanjuta, am-project: better memory management for the properties lists properties is now owned fully by the node, while only the list properties_info (not its content) is owned by tho node.
Created attachment 204054 [details] [review] language-support-vala: update .vapi for the latest changes
Created attachment 204055 [details] [review] language-support-vala: take advantage of the new project API
Review of attachment 204051 [details] [review]: Shouldn't it be (transfer full) for the info argument as the list doesn't copy the data?
Review of attachment 204055 [details] [review]: get_property always return a valid property, it could be a custom property or the default property. Property can be NULL only if you use an invalid id for this node. I have the same issue in the autotools backend. When I want to check that a node has its own property, I'm rather using something like ((property != NULL) && (property != property->info->property)). It's a bit cumbersome, perhaps we can find something better. But it's useful to get a valid property from a node even if the node hasn't its own value.
Created attachment 204112 [details] [review] libanjuta, am-project, project-manager, language-support-vala: rename property to default_value
(In reply to comment #7) > Review of attachment 204051 [details] [review]: > > Shouldn't it be (transfer full) for the info argument as the list doesn't copy > the data? It is done like this for patch 204053 (the node owns the list, but not the properties information; and those could be kept in one place in a static/class variable). If this becomes (transfer full), patch 204053 needs to change as well.
(In reply to comment #8) > Review of attachment 204055 [details] [review]: > > get_property always return a valid property, it could be a custom property or > the default property. Property can be NULL only if you use an invalid id for > this node. > > I have the same issue in the autotools backend. When I want to check that a > node has its own property, I'm rather using something like ((property != NULL) > && (property != property->info->property)). It's a bit cumbersome, perhaps we > can find something better. But it's useful to get a valid property from a node > even if the node hasn't its own value. Thanks, I'll fix this.
I've pushed all the above patches (with a fix for patch 204055)
Review of attachment 204050 [details] [review]: Ok.
Review of attachment 204052 [details] [review]: Ok