Re: GConf and bonobo-conf
- From: Federico Mena Quintero <federico ximian com>
- To: Havoc Pennington <hp redhat com>
- Cc: Dietmar Maurer <dietmar ximian com>, gconf-list gnome org, gnome-hackers gnome org
- Subject: Re: GConf and bonobo-conf
- Date: Tue, 20 Feb 2001 12:51:44 -0600
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]