Fwd: Re: Postgres bonobo controls

[Vivien Malerba <malerba linuxave net>]

----------  Forwarded Message  ----------
Subject: Re: Postgres bonobo controls
Date: Tue, 9 May 2000 16:28:01 +0200
From: Vivien Malerba <malerba@linuxave.net>


On mar, 09 mai 2000, you wrote:
> > BTW, have you been able to set/get properties values of bonobo controls (not
> > the postgres ones because these functions are broken)?
> > 
> Didn't try it, because when I finished the properties dialog, I didn't
> know if this was the right solution for the properties, as I said
> before. I must confess that I'm a bit lost on this, I don't know (or
> haven't had time to think about) how to implement this. I've even
> thought the other day about adding a open-connection-like dialog when
> the component is activated (set_frame_cb), and prompt the user there
> about the properties needed for activating (each component will have
> their own) the component. Then, we could define a set of common
> properties separated from the 'activation' properties.
> 

Here is a summary of how I understand bonobo properties and how IMHO we should
use them for the gnome-db controls.

When an app 'imports' a component, it must be able to interract with it by
setting and reading values (I think that components may also be able to emit
signals, but I'm not sure). The properties that can be read and written, for a
given component, are accessed by their name (a simple string). For a given
component, ALL its properties are packed using a BonoboPropertyBag, and
accessed using a BonoboPropertyBagClient.

For example, if I want to get the value of the "running" property from the
property bag, which is a boolean, I use:
bonobo_property_bag_client_get_value_gboolean(prop_bag, "running");
and to set it:
bonobo_property_bag_client_set_value_gboolean(prop_bag, "running", TRUE);
It's quite simple to use for an app embedding a bonobo control.

Now, on the bonobo control side: if I want my bonobo control to exist, the
application telling the system that it 'exports' a bonobo control MUST
'register' it using a call to a function hidden in the gnome-db-control object.
However, the bonobo control must register its properties, for each instance of
that control created, and uses a call to  bonobo_property_bag_add_full() or the
like for each of its properties.

For example:
bonobo_property_bag_add_full(pb, "reset", PROP_RESET, 
			     BONOBO_ARG_BOOLEAN, NULL,
			     "Give it TRUE to reset/start the component", 0,
			     get_prop, set_prop, data);
will register the "reset" property as a boolean, and being property number
PROP_RESET (a simple enum is OK). The last two functions (get_prop and
set_prop) are called respectively when the app embedding this control calls 
bonobo_property_bag_client_get_value_###() and
bonobo_property_bag_client_set_value_###().
The data pointer helps to have some information on the actual bonobo control to
which apply these functions (it is passed as the data arg when these functions
are called).


Now here is where I have some problems: the get_prop() and set_prop() functions
are called with the NULL value instead of the actual bonobo control, so I don't
know which control I have to access to get/set values.



As for the usage of the properties in the gnome-db controls: I think these
properties should be used by the app embedding a control to choose how the
control must be initialised, etc. The properties should not be accessible to
the end user (he needs not know about them).

For the gda-manager, a solution may be to remove the 'Load' button in the
toolbar, and put a 'Configure' button under the other buttons of the Data
Sources. When the user clicks on it, it will insert a new page to the notebook
in which will be, if available, the global config component for the selected
data source (that way the DSN and username are known and can be passed by
setting the DSN and username properties of the new bonobo control). Like that
if I want to configure a DBMS, I first select it among the provided list of
dada sources, and click on 'Configure'. What do you think, Rodrigo?

Last, I think it is important that each control has its user and password
properties set because some actions may require the application user to change
identity (for example be the postgres user to add new users to the DB). With
this there is a property to hide this user identity part if not welcomed.

Thanks for reading it all !)

Vivien
-------------------------------------------------------