> BTW, I'd be interested in seeing the code for your stripped-down
> version. It probably isn't that appropriate for desktop use but I have
> been investigating some improvements along the lines of changing the
> protocol.
I'll make it part of PicoGUI (www.picogui.org) : it is not part of
this project itself, but the community there might find it useful...
About the protocol, I dropped the assumption of networked access to
the server, so I use unix sockets and transmit structures with no
great care for marshalling. I've a small description language for the
structures being passed that generate data structures sufficient to
handle the dynamic fields. For instance:
ValueString
gchar value [len]
guint16 len
...generates:
typedef struct {
gchar * value;
guint16 len;
} GConfRqValueString;
...plus information that the length of the value field is stored in
the len field:
static IPCLibContent _gconf_rq_value_string [] = {
{IPCLIB_PROTOCOL_BODY, 0, sizeof (GConfRqValueString)},
{IPCLIB_PROTOCOL_CHAR | IPCLIB_PROTOCOL_REFERENCE, offsetof (GConfRqValueString, value), 2},
{IPCLIB_PROTOCOL_UINT16, offsetof (GConfRqValueString, len), sizeof (guint16)},
{IPCLIB_PROTOCOL_FINISHED, 0, 0}
};
This makes it easy to write a generic library to send and receive
these structures. This code does not allow for nested structures. So
I've manually broken down the complex structures, and I reassemble
them by hand. Maybe less elegant than having an IDL compiler, but this
solves 80% of the problems easily...
The core functionnality is working, but the client library is not as
thin as expected, mainly due to the use of the glib: I don't have
dynamic libraries, and using a single function of the glib causes
almost the complete library to be linked in a program. I'll also try
to improve this situation by splitting the glib files, so that only
the requested functions are linked in.
Now that my PicoGConf works, I will have to implement a sort of
graphical preference editor on top of it. One shortcoming of the
current model is the automatic enforcement of additional constraints
on the values (min/max values for integers, general constraints on
strings,...). Is this something that will be addressed in a future
version (extended schemas for instance) or is it a design choice ? I
can think of using GConf itself to store these constraints as special
keys, but I don't know if this is a good idea (applications still have
to check if the values are correct, as the preference editor could be
easily bypassed).
Frédéric
Attachment:
pgpjO82jX34gQ.pgp
Description: PGP signature