[Development] QSettings refactor updates

Thiago Macieira thiago.macieira at intel.com
Mon Oct 20 14:38:53 CEST 2014


On Monday 20 October 2014 14:26:17 Simon Hausmann wrote:
> > Should be completely transparent and orthogonal. The data types supported
> > by the front-end should not be affected by whatever it uses for caching.
> Ah, so that means custom types (types other than what QJson supports) will
> be converted to the same QVariant(0x12, 0x54, ...) type of string as in
> .ini files?

I'm not sure I get you.

What I meant is that we decide what the front-end supports and how it gets 
saved to the .ini file. However it gets cached, it's an implementation detail 
and must not affect the user in neither the API nor the .ini file.

For example, if we decide that we must support integers with 64 bits of 
precision, then we'll need to either modify QJsonDocument to support it or 
we'll need to somehow cache it differently -- as a string, for example.

> > > The current .ini format Qt defines allows for custom types to be stored
> > > (in
> > > a hackish way and hard to version). Would the new API be limited to
> > > booleans, integers, doubles and strings? (i.e. no QVariant in the API)
> > 
> > I'd say it's a good idea to do that, though I'm pretty sure we'll get
> > asked
> > for lists too. Then again, for lists I'd save multiple config entries
> > instead of one entry containing multiple items.
> 
> Yeah, I think that's a lot more robust than trying to look for an unescaped
> ',' and then split.
> 
> Does XDG allow for that?

I don't think so. We'll probably need to figure out which extensions we'll want 
to adopt, like for example the head and trailing space extensions that KConfig 
uses, which will be required to embed newlines anyway.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list