Re: GConf and bonobo-conf



Havoc Pennington <hp redhat com> writes:

> As a suggestion, I think it would be helpful to describe several
> use-cases of the CORBA_any feature. i.e. examples of what an app would
> use it for, and why it's better than other possible options in those
> cases.

Evolution calendar named views:
	View
		Name: "Table of next week's ICBM launches"
		View type: table
		Display: (and (event-has-category "ICBM launches")
			      (event-intersects-time-range (make-week-range 'next)))
		Columns to display: subject, start date, geographical position

	View
		Name: "Confidential alarms that triggered in the last month"
		View type: Month view
		Display: (and (eq? (event-classification) 'confidential)
			      (event-has-alarm (make-month-range 'last)))

Etcetera.  Each view is a struct with some tricky union stuff,
something like:

	enum ViewType {
		DAY_VIEW,
		MONTH_VIEW,
		TABLE,
		JOURNAL_TIMELINE
	};

	struct TimeRange {
		Time_t start;
		Time_t end;
	};

	struct CalendarView {
		string name;
		string constrain_display_sexp;

		ViewType type;
		
		union {
			struct {
				TimeRange range;
			} day_view_options;

			struct {
				TimeRange range;
			} month_view_options;

			struct {
				sequence <string> columns_to_display;
				string sort_column;
				boolean reverse_sort;
			} table_options;

			struct {
				TimeRange range;
				...
			} journal_options;
		} u;
	};

Yeah, I know that is not the right IDL for unions, but whatever.

I would like to store a list of CalendarView structures to keep my
named views in nice chunks, instead of using a million prefixed nodes
in the GConf tree to simulate structs.

Then I can simply write

	Evolution_Calendar_CalendarView cv;

	view_node = "/node/name/that/is/just/a/string/in/a/list";
	cv = bonobo_conf_get_value (view_node);

without having to do anything else, whereas GConf would make me do

	view_node = "/some/node/that/was/a/pain/to/find";

	cv.name = gconf_get_string (view_node + "/name");
	cv.constrain_display_sexp = gconf_get_string (view_node + "/sexp");

	/* oops, gconf does not have symbolic values, so this will be painful */
	tmp = gconf_get_string (view_node + "/type");
	if (!strcmp (tmp, "day_view")) {
		char *key;

		cv.type = DAY_VIEW;

		key = g_strconcat (view_node, "/day_options/range/start", NULL);
		cv.u.day_view_options.range.start = parse_date (gconf_get_string (key));
		g_free (key);

		key = g_strconcat (view_node, "/day_options/range/end, NULL);
		cv.u.day_view_options.range.end = parse_date (gconf_get_string (key));
		g_free (key);
	} else if (!strcmp (tmp, "month_view")) {
		char *key;

		cv.type = MONTH_VIEW;

		key = g_strconcat (view_node, "/month_options/range/start", NULL); 
		cv.u.month_view_options.range.start = parse_date (gconf_get_string (key));
		g_free (key);

		key = g_strconcat (view_node, "/month_options/range/end", NULL);
		cv.u.month_view_options.range.end = parse_date (gconf_get_string (key));
		g_free (key);
	} else if (!strcmp (tmp, "table")) {
		char *key;

		cv.type = TABLE;

		key = g_strconcat (view_node, "/table_options/columns", NULL);
		cv.u.table_options.columns_to_display = gconf_get_string_list (key);
		g_free (key);

		key = g_strconcat (view_node, "/table_options/sort_column", NULL);
		cv.u.table_options.sort_column = gconf_get_string (key);
		g_free (key);

		key = g_strconcat (view_node, "/table_options/reverse_sort, NULL);
		cv.u.table_options.reverse_sort = gconf_get_boolean (key);
		g_free (key);
	} ... blah blah blah

You can see why I would prefer writing just two lines of code instead
of many.  I.e. the CORBA_Any stuff lets me use whatever I like with
very little code of my own.

We discussed this when you were designing GConf; structs and enums and
other things would indeed be useful but you would basically have to
replicate IDL to get them right in GConf.

That is, if I need complex data types I just declare them in IDL,
which

	- is the representation I would use to invoke my methods
          anyways,

	- is what bonobo-conf is perfectly happy to pass around,

	- is nice and declarative and much less of a pain than writing
          an astronomically long XML schema.

  Federico




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