xfconf update - array and struct types

[Jasper Huijsmans]

Hey Brian,

2007/10/15, Brian J. Tarricone <bjt23 at cornell.edu>:
...

I was reading the stuff about array types and was getting the feeling
it might just be a little bit overengineered, but than you got to the
structs and I must say that is really cool. It is absolutely clear
what is going on at first glance, the use can have complex data
structures and the backend does not need to know anything about it.
Very nice indeed.

(More comments below)

> * Struct values.  This is built on top of the array value stuff, and I
> think it's pretty cool.  Basically, you can pass the library a property
> name, a struct, and a list of GTypes for the members, and it'll fill in
> the struct from the config store (or save the struct values in the
> config store). There's API to register "named structs" which basically
> just has the library remember the struct layout for you so you don't
> have to type it over and over if you use it a lot.  This is how we fix
> our GdkColor/McsColor problem and leave the door open for a lot of
> other uses.  It works like this:
>
> /* from gdk */
> typedef struct _GdkColor
> {
>     guint16 red;
>     guint16 green;
>     guint16 blue;
> } GdkColor;
>
> /* our app */
> GdkColor color = { 0xe922, 0x594, 0x8fc8 };
> xfconf_channel_set_struct(channel, "/foo/barcolor", &color,
>                           XFCONF_TYPE_UINT16,
>                           XFCONF_TYPE_UINT16,
>                           XFCONF_TYPE_UINT16,
>                           G_TYPE_INVALID);
>
> ... and that's all you have to do to store a GdkColor.  Retrieving it
> works the same way.  I'd probably include some named structs by
> default, including GdkColor, so you could do this:
>
> /* from xfconf.h */
> #define XFCONF_NAMED_STRUCT_GDKCOLOR  "Xfconf-GdkColor"
>
> /* our app */
> GdkColor color = { 0xe922, 0x594, 0x8fc8 };
> xfconf_channel_set_named_struct(channel, "/foo/barcolor",
>                                 XFCONF_NAMED_STRUCT_GDKCOLOR, &color);
>
> The cool thing is that none of the struct stuff requires the daemon or
> backend to know anything about structs.  It just sees these as arrays
> of values.  The client lib does all the validation to make sure the
> struct layout matches the types of the array elements in the config
> store.
>
> There's one possible issue: struct member alignment.  Right now
> libxfconf is placing values in the struct you pass it by taking into
> account struct member alignment.  If you use the gcc extension
> __attribute__((packed)) on your structs, this won't work, and you'll
> get segfaults in your application if your structs would normally require
> padding.  I'm tempted to just list that as a limitation and leave it
> alone, since I think most of the time you'd use this libxfconf
> functionality for normal aligned structs.  The only time you really use
> packed structs is when you're using structs to represent some binary
> file format on disk or a wire protocol on the network, or something
> like that.
>
> So, that's about it.  It's far past my bed time, so I should get to
> sleep and work on this more tomorrow.  Comments, criticisms, and
> suggestions would be most welcome; it would be good to know if people
> think I'm going in the right direction, or if I'm getting to the point
> where I'm overengineering things.
>

Well I would say if you start worrying about packed structs, you have
reached the point of overengineering alright ;-)

Binary or otherwise unaligned data should be saved/restored as byte arrays.

Or let me rephrase that: If anyone should ever feel the need to use a
packed struct anywhere in Xfce, they should instead stick their head
in a bucket of ice cold water until they get back to their senses.

Did that come out too strong? ;-)

>         -brian

-- 
        Jasper