Re: gnome-db control and properties

[Rodrigo Moya <rodrigo linuxave net>]

> 1 - using properties
> In my view, the properties values are stored in a data field of the widget
> which will be in a bonobo control (using gtk_object_set_data()). So the
> user_data that need to be given to the get/set properties functions must be a
> pointer to the actual widget. This is what is done, AFAIK, with the call line
> 100 of file gnome-db-control.c.
> The problem is that when a client wants to get a property, the user_data given
> to the get_property function (by the bonobo framework) is set to NULL!
> I think it is a bonobo bug, but I could not find it in the bonobo sources. What
> do you think?
>
Let me think about this a little more (this evening) since I don't know
right now, and I haven't seen too much about the Bonobo properties stuff
(in fact I think the code you're saying in gnome-db-control.c is just
there as a reminder of missing things), and I'm quite busy at the moment
at work. I'll have a look tonight.
 
> 2 - naming issues
> I agree with you that the naming if the components needs to be correctly set. I
> think what you propose is the good solution. If I understand correctly, if an
> app wants to have the users config control, if the gda datasource is
> [Postgres-Native] (where Provider=gda-postgres), it will have to ask for the
> component:
> control:$(Provider)-$(Service)
> like
> control:gda-postgres-config-users
> We should thus make this a naming convention, and set valid names for services
> (like 'config-userss').
> If it is OK with you, I will start to enumerate services for which a provider
> can 'export' a bonobo control.
> 
I think the best way is what we talked the other day, which is exactly
what you're saying:

$provider-config-$service

where service is: users, databases, ... (I can't think of more right
now)

This way, we can activate all the config components by just knowing the
provider name. And thus, we don't need extra config files to be parsed.

Cheers