[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KConfig nested groups
From:       "Paolo Capriotti" <p.capriotti () gmail ! com>
Date:       2007-03-04 9:29:02
Message-ID: 87b37d60703040129p14c98e01xb2ad861f835e96f9 () mail ! gmail ! com
[Download RAW message or body]


On 3/3/07, Aaron J. Seigo <aseigo@kde.org> wrote:
>
> some thoughts:
>
> aIt.key().mKey.startsWith(prefix) looks slow, and is really a backend detail
> related to how it is stored on disk. e.g. backends that can actually store
> hierarchies of data (e.g. ldap) will not follow this pattern.
>
> perhaps it makes more sense to actually store the entries as a tree in kconfig
> and leave it up to the backend to populate that tree? that way getting the
> entrymap for a group is simply descending the tree once and returning all the
> non-default, non-deleted entries.

Yes, that's a good idea. Some notes on how I intend to implement this:

KConfig stores a KEntryMap, representing the whole config. Each KEntry
has an optional KEntryMap field, which, when nonnull, identifies it as
a subgroup. This way we can represent a tree-like structure without
changing too much in the existing code.
KConfigGroup no longer refers to a master KConfig, but stores a
pointer to a KEntryMap.
KConfig represents the whole configuration, and should only be used
internally. There is still the concept of "current group" and
functions to change it. Using the read / write api acts on the current
group. All of this is deprecated, though.
KConfigGroup can represent any node in the configuration (even the
topmost node). It has some extra functions: parent(), which returns
the parent node, and group(QString), which returns a nested group. I
don't like changeGroup very much, and in this context it makes little
sense... can I remove it?
Backends, of course, have to be changed to reflect the new data
structure, but probably not the abstract class KConfigBackend.
In summary, the API would be pretty much compatible, but the internals
would change a lot.

Attached is a patch which only removes the extra key inside KEntryKey.
Can I commit it?

Paolo

["kentrykey.patch" (application/octet-stream)]

[prev in list] [next in list] [prev in thread] [next in thread]