[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: [PATCH] KConfig code cleanups
From: "Thomas Braxton" <kde.braxton () gmail ! com>
Date: 2007-10-29 2:44:40
Message-ID: 928c3f1b0710281944h624fcd2ah39afa88730d43271 () mail ! gmail ! com
[Download RAW message or body]
On 10/28/07, Oswald Buddenhagen <ossi@kde.org> wrote:
>
> On Sun, Oct 28, 2007 at 01:39:17PM -0500, Thomas Braxton wrote:
> > On 10/28/07, Oswald Buddenhagen <ossi@kde.org> wrote:
> > > On Sat, Oct 27, 2007 at 05:07:10PM -0500, Thomas Braxton wrote:
> > > > 1) do we want to support an empty group name?
> > > > 2) this one depends on #1, should the name of the default group be
> > > > exposed?
> > > >
> > > the concept of giving the root group a virtual name is bogus. it
> should
> > > be a null string.
> > > this, btw, does not mean that the name of the root group is "" - the
> > > root group simply has no name, but we need to address it somehow
> through
> > > our tree-wise inferior api. consequently, subgroups cannot have empty
> > > names, either.
> >
> > A couple of problems with what you wrote:
> > 1) A group with an empty name does not have to be the <default> group,
> it
> > would be written to an ini file as [].
> >
> that's bogus, too. what would it mean, logically? and i can imagine
> backends that can't deal with this without encoding hacks.
>
> > 2) The unnamed <default> group is written to the ini file without a
> group
> > marker at all. The other toplevel groups are siblings not children of
> the
> > unnamed <default> group, so there is no *root* group.
> >
> i know. ;-)
> while this doesn't really fit the flat structure of an ini file, the file
> itself can/should be viewed as the root group.
>
> > So do we want to support "[]"?
> >
> no
good, it just looked wierd to me :)
> If yes, then what should be returned as the name of the <default>
> > group? QByteArray()?
> >
> yes
not a problem, but, since we're not supporting "[]", what would be the
problem with using "" as the name of the default group? I was thinking that
we could use this to verify that we have a valid key by testing
mGroup.isNull() ==> invalid key, something wierd happened.
> > this looks bogus. it should be possible to have an empty group with
> > > an immutability marker. fix the entry map if it doesn't work.
> >
> > the <default> group is immutable if the file is immutable, since it
> > doesn't have it's own group marker in the file,
> >
> oh, right ... hmm ... do you think it would make sense (i.e., produce
> simpler code overall) to synthetize a root group marker?
not really, just pointing it out. but since you say we should consider the
file itself as the default group then we don't need to put a group marker
for the default group, because the immutable flag for the file could be
looked at as the immutable flag for the default group. And since there's no
way ATM to set the immutable flag for a group or entry, we don't have to
worry about writing it out.
taking this
> further, i think we should consider an actual tree structure for the
> entry map. this is all 4.1+ material, of course.
>
> --
> Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
> --
> Chaos, panic, and disorder - my work here is done.
>
[Attachment #3 (text/html)]
<br><br><div><span class="gmail_quote">On 10/28/07, <b \
class="gmail_sendername">Oswald Buddenhagen</b> <<a \
href="mailto:ossi@kde.org">ossi@kde.org</a>> wrote:</span><blockquote \
class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc \
solid;padding-left:1ex"> On Sun, Oct 28, 2007 at 01:39:17PM -0500, Thomas Braxton \
wrote:<br>> On 10/28/07, Oswald Buddenhagen <<a \
href="mailto:ossi@kde.org">ossi@kde.org</a>> wrote:<br>> > On Sat, Oct 27, \
2007 at 05:07:10PM -0500, Thomas Braxton wrote: <br>> > > 1) do we want to \
support an empty group name?<br>> > > 2) this one depends on #1, should the \
name of the default group be<br>> > > exposed?<br>> > ><br>> \
> the concept of giving the root group a virtual name is bogus. it should <br>> \
> be a null string.<br>> > this, btw, does not mean that the name of the \
root group is "" - the<br>> > root group simply has no name, but we \
need to address it somehow through<br>> > our tree-wise inferior api. \
consequently, subgroups cannot have empty <br>> > names, \
either.<br>><br>> A couple of problems with what you wrote:<br>> 1) A group \
with an empty name does not have to be the <default> group, it<br>> would be \
written to an ini file as []. <br>><br>that's bogus, too. what would it mean, \
logically? and i can imagine<br>backends that can't deal with this without \
encoding hacks.<br><br>> 2) The unnamed <default> group is written to the \
ini file without a group <br>> marker at all. The other toplevel groups are \
siblings not children of the<br>> unnamed <default> group, so there is no \
*root* group.<br>><br>i know. ;-)<br>while this doesn't really fit the flat \
structure of an ini file, the file <br>itself can/should be viewed as the root \
group.<br><br>> So do we want to support \
"[]"?<br>><br>no</blockquote><div><br \
class="webkit-block-placeholder"></div><div>good, it just looked wierd to me :)</div> \
<br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px \
#ccc solid;padding-left:1ex">> If yes, then what should be returned as the name of \
the <default><br>> group? QByteArray()?<br> ><br>yes</blockquote><div><br \
class="webkit-block-placeholder"></div><div>not a problem, but, since we're not \
supporting "[]", what would be the problem with using "" as the \
name of the default group? I was thinking that we could use this to verify that we \
have a valid key by testing mGroup.isNull() ==> invalid key, something wierd \
happened.</div><div><br class="webkit-block-placeholder"></div><blockquote \
class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc \
solid;padding-left:1ex"> > > this looks bogus. it should be possible to have an \
empty group with<br>> > an immutability marker. fix the entry map if it \
doesn't work.<br>><br>> the <default> group is immutable if the file \
is immutable, since it <br>> doesn't have it's own group marker in the \
file,<br>><br>oh, right ... hmm ... do you think it would make sense (i.e., \
produce<br>simpler code overall) to synthetize a root group marker?</blockquote><div> \
<br class="webkit-block-placeholder"></div><div>not really, just pointing it out. but \
since you say we should consider the file itself as the default group then we \
don't need to put a group marker for the default group, because the immutable \
flag for the file could be looked at as the immutable flag for the default group. And \
since there's no way ATM to set the immutable flag for a group or entry, we \
don't have to worry about writing it out. </div><br><blockquote \
class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc \
solid;padding-left:1ex"> taking this<br>further, i think we should consider an actual \
tree structure for the<br>entry map. this is all 4.1+ material, of \
course.<br><br>--<br>Hi! I'm a .signature virus! Copy me into your ~/.signature, \
please!<br>--<br>Chaos, panic, and disorder - my work here is \
done.<br></blockquote></div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic