xfconf data type quesions

[Alexandre Moreira]

On 10/12/07, Alexandre Moreira <alexandream at gmail.com> wrote:
> On 10/12/07, Nick Schermer <nickschermer at gmail.com> wrote:
> > 2007/10/12, Brian J. Tarricone <bjt23 at cornell.edu>:
> > > Personally (...) [snip]
> >
> > I think it's better (...) [snip]
>
> 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.

Well, here it goes:

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 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.

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.

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.

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 ?

Regards,
Alexandre Moreira.

>
> Best Regards,
> Alexandre Moreira.