xfconf data type quesions

[Brian J. Tarricone]

mmassonnet at gmail.com wrote:
> On Sun, Oct 07, 2007 at 02:19:35PM +0200, Jannis Pohlmann wrote:
>> Am Sun, 7 Oct 2007 11:16:44 +0200
>> schrieb "Nick Schermer" <nickschermer at gmail.com>:
>>
>>> First of all, I don't see why alpha is part of a color. But apart from
>>> that, why not convert the color into a hex decimal string (like
>>> gdk_color_to_string does). The # shows we're talking about a color
>>> (well most people will recognize it that way) and strings like
>>> #33335555ffff are easy to customize.
>>>
>>> We could even add a convenient function in the library to save a
>>> gdkcolor, since what we mostly use in Xfce/Gtk (gdkcolor -> convert ->
>>> xfconf_channel_set_string and the other way around for parsing the
>>> string to a gdkcolor with gdk_color_parse).
>> I haven't read all of Brian's explanations, but his #6 (if properly
>> implemented) would be very flexible for any kinds of lists. But for
>> colours I prefer your idea of using a HTML-/CSS-like colour string.
> 
> AFAICU #6 offers extensibility in data storage, and the Color type would
> only be there for backward compatibility.  Now about an HTML color
> representation, it fits perfectly in a string, so maybe a Color type is
> useless in a general case.

The problem with using html/css color strings is that they aren't 
particularly useful to applications in that form.  Storing an array of 
ints lets you do (e.g.):

GdkColor color;
int *parts;

parts = xfconf_channel_get_int_list(channel, "/foo/bar");
color.red = parts[0];
color.green = parts[1];
color.blue = parts[2];

Though I guess with a string, you do:

GdkColor color;
const gchar *htmlcolor;

htmlcolor = xfconf_channel_get_string(channel, "/foo/bar");
sscanf(htmlcolor, "#%4x%4x%4x", &color.red, &color.green,
        &color.blue);

... or use gdk_color_parse() (tho I'm not sure if that can handle 16-bit 
html-like color strings, or just 8- and 4-bit as the examples show in 
the documentation).

Personally, I prefer not to store numeric data as strings, but I guess 
this is OK, and it's technically less code (well, ignoring the fact that 
you have call to an expensive function in there).  And   Obviously you'd 
have to do error checking in either case (for the int array, make sure 
there are actually 3 elements; for the html string, make sure the string 
is valid).

Then again, after adding all the array types, both methods are possible, 
and app authors can choose to do what they wish.

I dunno... I still haven't decided, and it doesn't seem like anyone has 
a silver-bullet answer.  My laptop is half-alive again; I'll mess with 
this over the weekend I guess.

	-brian