Re: gnome-db control and properties

> 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:


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

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.


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