xfconf data type quesions

[Brian J. Tarricone]

Alexandre Moreira wrote:
> On 10/12/07, Alexandre Moreira <alexandream at gmail.com> wrote:
>> I am really not sure if my idea is a good one, but I'll throw it: even
>> If you guys are planning on having a regedit-like editor, I don't
>> believe the types should be defined with that in mind, to allow it to
>> operate on a type in a different way or whatever. I think it would be
>> better to have a separate attribute to the config entries, like
>> "type-hint" or something like that, which the editor could use, but
>> would be useless to the applications.
>>
>> That way we could have a string with a typehint="filename", and the
>> editor could pop a file chooser dialog for it, and so on.
>>
>> One thing, though, is that I believe the editor would benefit most
>> from a scheme (to give users an advanced interface, with more
>> information and to handle things like enumeration options). But, as I
>> already know the consensus here is that we shouldn't have one in
>> xfconf, I'll just shut up :)
> 
> Hmm... Guys, I'm sorry if what I am saying makes no sense, or is
> completely off the roadmap for Xfconf, I admit I haven't been
> following the discussion closely. I've tried to find a proposed API
> for libxfconf but failed to find (can anyone point me ?), and I know
> too little of dBus to figure out a possible API through it's messages
> definitions.

See here:
http://svn.xfce.org/svn/kelnos/xfconf/trunk/xfconf/xfconf-channel.h

The current consideration involves extending that so all of the setters 
and getters for int, double, etc. also have a "_list()" variant as well, 
just like the string list stuff.  I partially implemented that in my 
local copy right before my hard drive died (fortunately I recovered 
everything).

> I don't know how xfconf handle types internally (is it aware of the
> type of the data it stores ?) but, if there is a method to query the
> type of a given option, I think we could make an extension here (Now I
> ask for your opinion on the subject, Brian, as the creator).

The daemon uses GValues to store everything, so, yes, it knows what type 
of data is in a particular property.  The dbus interface uses the dbus 
"variant" type, which, in terms of the dbus glib bindings, are expressed 
as GValues.

The problem is that new types need to be explicitly added in both the 
daemon and (sorta) in the client library.  The daemon needs to know how 
to serialise (store) values on disk.  For example, for a double value, 
it'll do g_value_get_double() and then the equivalent of printf("%f") to 
store the value in a file (I'm actually considering replacing that with 
storing the more-accurate full 64-bit hex value instead).

New types don't absolutely have to be added to libxfconf, though, as I 
could add a wrapper for the SetProperty/GetProperty dbus methods that 
just return the raw GValue rather than converting it to a char*, int, 
double, etc.

But the daemon-side problem is a real issue -- there's no way that I'm 
aware of to serialise arbitrary data structures (and certainly nothing 
as complicated as GObjects) that the daemon doesn't know about.

As discussed, I'd like to avoid the need for applications to install 
some kind of 'schema' file to describe property names and value types, 
though I suppose as a post-1.0 extension I'd consider the possibility of 
a system whereby an application can register custom types (probably 
client-side) that are a composite of existing types.  (Actually, I 
really like this idea and it can be implemented entirely in libxfconf.)

> The thing is: use something somewhat related to the "detail" parameter
> on Gtk+ Signals. Types *could* be stored, if the application desires,
> as something like typename:typehint, and a method to query the type
> would return those as separate  values.

That's a cool idea, but what problem does this solve just from the 
daemon/client lib POV?  The application presumably knows what's in the 
properties and values it stores, and the daemon needs to know how to 
store specific concrete types, not stuff that's made up on the fly.

> What do we win with that: Again, assuming the regedit-like editor
> mentioned before is somewhat important in the roadmap, we could have a
> separation between the storage of the data, and it's "presentation" to
> the user. We could have separate files that only the regedit-like app
> -- probably using an extension library, not bundled with libxfconf --
> would use to find type information on a certain option, to give the
> user a better interface, instead of simply a bunch of strings.

This does sound like it could be useful, but just for the regedit-like 
app.  I really don't want the regedit app to be for common use.  IOW, 
users shouldn't have to use the regedit app at all.  These are the 
use-cases I envision:

1.  Customisation by sysadmins to create system-wide defaults.

2.  Ability of power users to edit 'hidden options' -- I would hope that 
these aren't common, and they need to be documented in the app's 
documentation.

That's really mainly it.  And note that, without a schema system, #1 
doesn't really work all that well, because settings won't show up in the 
regedit editor unless the application has already been run once *and* 
has saved the settings in xfconf.

> therefore we would have something like a type="string:color", or
> type="string:filename", or even type="int:xfce.panel.position" (which
> could be mapped to a nice set of readable strings on the typehint
> file) on  the property, the config system itself wouldn't have to know
> anything about it (it could even use a simplified version of the
> method call, which didn't return the typehint part of the type) but we
> would still have enough information, if the app so desires, to give
> the user hints or constraints on what values it could accept.

I like this, and maybe this method can be used to help implement the 
ability of apps to register custom types.  Imagine an app that uses 
colors wanted to register a color type, so it might install a file in a 
directory that libxfconf watches that looks like this:

<libxfconf-type name="FooAppColor">
     <member name="red" type="int"/>
     <member name="green" type="int"/>
     <member name="blue" type="int/>
</libxfconf-type>

Then we could extend the Xfconf daemon spec to add your 'detail/hint' 
argument, which should be stored in the daemon however it wants to store 
it, but be treated as an opaque client-specific value.  With the current 
xml backend, that could look like this:

<property name="bg-color" type="intarray" hint="FooAppColor">
     <int>200</int>
     <int>100</int>
     <int>42</int>
</property>

Then, since the client lib has access to the type definition file (or 
perhaps the regedit app could access it directly), it could present the 
types to the user in a more meaningful way.  Of course, it can't be 
totally awesome: ideally it would display a GtkColorButton to set the 
option, but you can't really tell from the above definition that it's 
supposed to be a color.  Perhaps libxfconf could ship with some built-in 
extension types (e.g., XfconfGdkColor) that apps could use.  That also 
eliminates some of the problem with every single app that uses colors 
adding its own extension type.

This is both useful for the regedit-type app (able to display complex 
types better, with some hint as to what they're for), and for apps as 
well, as they can register custom types such that they can pass their 
own data types directly to the API and get them back filled in and ready 
to use[1].  I envision something like this:

gboolean xfconf_channel_get_custom(XfconfChannel *channel,
                                    const gchar *property,
                                    const gchar *type_hint,
                                    gpointer value_return);

And you could use it like so:

GdkColor color;
if(xfconf_channel_get_custom(channel,
                              "/foo/bar/bg-color",
                              XFCONF_TYPEHINT_GDK_COLOR,
                              &color))
{
     /* do something */
}

(XFCONF_TYPEHINT_GDK_COLOR would be a builtin type, and would be defined 
as a string constant in one of libxfconf's headers.)

> It seems to me that, through this approach we can have more
> information about the properties without bloating the xfconf daemon
> nor the library, and keeping the library API pretty slick. And if
> anyone gets interested in the idea of this "type reflection" data
> associated it would take a different effort (that is, it wouldn't
> delay Xfconf, as it could really be made as part of the said
> regedit-like app) to create an library to read this "type meta data".
> 
> Well, that is it. I think it is a good idea (otherwise I wouldn't
> write so much about it) but as I'm not developing anything in XfConf I
> believe it is more of a Brian's decision.
> 
> What do you say ?

I like it -- this idea seems like it could add a lot of flexibility at 
little cost.  Or, at least, you wouldn't incur any cost if your app 
doesn't use this feature.

	-brian

[1] I'd probably want to make the 'array of values' types in the Xfconf 
daemon to be untyped - that is, you can store an array of arbitrary 
mixed types, since structs would not necessarily be all of the same 
type.  The string list convenience API in the client could still be 
maintained; not so sure there needs to be convenience API for the other 
basic types as arrays, perhaps just a xfconf_channel_(get|set)_array() 
call.  Or two: one that takes varargs and one that takes an array of 
GValues.