Re: GConf and bonobo-conf



> I don't want to invest more time making the case against introducing
> a structured-storage mechanism in GConf when the API wasn't designed
> for that; if it doesn't require changing GConf internally, then
> it's a case of caveat hacker - use the structured storage knowing
> that it makes your app harder to evolve in a way that puts a value
> on the user's configuration data.

Well, as we claimed before, we are using the GConf "engine" to store
values and notify people who have requested to be notified of changes,
but we do not even need to use the existing GConf API.

Our current approach is based on monikers, so you do:

	use Bonobo;
	init Bonobo;
	
	bag = Bonobo->get_object ("config:key", "Bonobo/PropertyBag");
	$property = $bag->getProperty ("Email");
	print "Email: " . $property->getValue ();

Notice that this is a working piece of code in Perl/Gtk, no code
wrapping was required, it is just using the stock Bonobo wrapper and
uses the moniker system to resolve to an interface that you can use.

The beauty of this scheme is that the API is defined in terms of the
CORBA IDL for PropertyBag and Property, and it is available across all
languages with Bonobo/CORBA support.

One API less to be wrapped.

Miguel.




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