kdecore/config/TODO

   1 bugs
   2 ====
   3
   4 - make expandString stuff consistent
   5 - KConfigGroup::revertToDefault
   6   - does not match apidoc re. reverting to kdeglobals 1)
   7   - should use entryMap.revertEntry()
   8   - map has no bRevert flag that could be set along with bDirty, so it
   9     is impossible to get rid of a once set key
  10 - KConfigGroup::exists() should return true only if the group contains
  11   any non-deleted entries (?)
  12 - immutable groups with no entries are not written out and thus lose
  13   their immutability.
  14 - "C" & "en_US" should be detected early and converted to a null string
  15   (but also save the original string, so locale() semantics don't change
  16   at that point).
  17
  18 1)
  19 > > > > > > > I think the apidoc is wrong, it probably shouldn't have the extra
  20 > > > > > > > paragraph about opening kdeglobals explicitely
  21 > > > > > > >
  22 > > > > > > not necessarily. you are assuming a certain model: that kdeglobals
  23 > > > > > > blends into the config and is on the same level as the master file.
  24 > > > > > > however, that's not the case - kdeglobals is also a defaults file
  25 > > > > > > for the master file - which also happens to be writeable. in that, it
  26 > > > > > > already is an instance of the "master diversion" idea i want to
  27 > > > > > > generalize.
  28 > > > > >
  29 > > > > > no, I'm assuming that any entry read from kdeglobals if reverted will
  30 > > > > > revert back to the value from kdeglobals, since the default should
  31 > > > > > have bGlobal set.
  32 > > > > >
  33 > > > > yes. and now imagine that you want to revert the entries in kdeglobals
  34 > > > > to the system wide kdeglobals. this is what this comment is about.
  35 > > >
  36 > > > this is what happens, look at KConfig::parseGlobalFiles(). all the
  37 > > > files are parsed with ParseDefaults *except* the local one.
  38 > > >
  39 > > that is right, but makes no sense argumentation-wise.
  40 > > suppose we have default-foorc, kdeglobals and local-foorc; we opened the
  41 > > latter explicitly. now i revert key bar. it can only revert from
  42 > > local-foorc to kdeglobals or from kdeglobals to default-foorc.
  43 > >
  44 > no, you will revert from local-foorc to either default-foorc or
  45 > kdeglobals depending on whether bGlobal is set on the default.
  46 > $KDEHOME/share/config/kdeglobals can revert from any of
  47 > $KDEDIRS/share/config/[system.]kdeglobals
  48 >
  49 ok - but in either case the key in the master file is reverted.
  50 to revert the values in kdeglobals itself, you have to open kdeglobals
  51 as the master file. that's all that the comment says.
  52
  53
  54 wishes
  55 ======
  56
  57 - use lazy loading
  58   - load as soon as the first KConfigGroup is instanciated
  59   - lazy parsing of values is interesting, too - see kconfig_take2 branch
  60 - add $\\VAR and $\\(cmd) escapes to list-quote expanded string
  61 - possibly:
  62   - preserve unchanged parts of the config literally. problem: comments
  63     might become stale. so if a comment is already there, add an additional
  64     comment that indicates that the value was changed (include old value?).
  65   - api to actively add comments to files, groups and keys
  66     - option to start these comments with ## as a sign that they should not
  67       trigger the above change indicator logic.
  68   - guaranteeing that write order of new keys is preserved
  69   - detect commented out entries and put actual entries with the same key
  70     right behind them
  71 - possibly: selective multi-level master diversion
  72   - this is to support roaming profiles that have machine/user/etc. specific
  73     settings
  74   - files, groups and keys can have [$m] and [$s] markers; these cascade
  75     within each file only. the least significant object (farthest away from
  76     the master) with an effective $m mode becomes the master (i.e., is
  77     written to and not read past).
  78     default is $m for the master file and $s for the default files.
  79   - the CascadeConfig flag being unset doesn't make things exactly simpler
  80   - can kdeglobals be handled by this?
  81   - does this really make sense? promoting an object to profile wide status
  82     is a conscious decision - which probably needs to be repeated every time
  83     the value changes.
  84
  85 internals
  86 =========
  87
  88 - the handling of opening kdeglobals explicitly seems weird, at least.
  89   couldn't it simply mask out IncludeGlobals and thus handle it as any
  90   other config without globals instead of spreading kdeglobals special
  91   cases all over the place? 2)
  92 - clear up bDeleted vs. isNull in entrymap
  93 - make entrymap truly hierarchical
  94   - an entry map contains its flags, a map of keys and a map of submaps.
  95     it does NOT contain its name and has no parent pointer.
  96   - when creating a kconfiggroup, ask parent for the respective submap
  97     and link it if it is present. if it is not, create one at write op,
  98     link it and tell parent to add it to its entry map. both query and
  99     creation are recursive, obviously.
 100     a kconfiggroup DOES contain its name and has a parent pointer.
 101   - 3)
 102 - 4)
 103
 104 2)
 105 > > kdeglobals has to be handled specially because either you open
 106 > > $KDEHOME/share/config/kdeglobals twice or you ignore all
 107 > > system.kdeglobals files. but, I have an idea that might clean this up
 108 > > some, I'll see what I can do.
 109 > >
 110 > i must admit i don't understand the system.* files at all. when was this
 111 > introduced and for which purpose?
 112 >
 113 a while ago, according to svn they were in 2.0. and I don't know what the
 114 purpose was.
 115
 116 3)
 117 > We wouldn't have to worry about the KEntryGroup being removed out from
 118 > under us, because the only way that should happen is if the config
 119 > object is destroyed or reparsed, and in those cases you shouldn't be
 120 > using a KConfigGroup from prior to that.
 121 >
 122 i don't think "this is stupid and will not happen" works; [...]
 123 given that cascaded parsing includes writing to existing maps, i think
 124 the simplest approach is clearing the existing structure from keymaps
 125 and resetting the attributes, but leaving the subgroup maps populated,
 126 thus keeping any group refs valid.
 127 the question is about the type of reference held to the entry map.
 128 originally i had thought of pointers. a map would be linked only if it
 129 really existed, otherwise the pointer would be null (thus indicating
 130 reads to return the default immediately and writes to ask the parent to
 131 create a submap). however, keeping that consistent with deletions would
 132 be a nightmare, and with the rescan changing the groups underneath
 133 impossible without each map having a list of referring configgroups.
 134 therefore it might make more sense to always create a corresponding tree
 135 of empty maps when a configroup for a non-existing group is instanciated
 136 - these groups won't be written out (they have no entries and cannot be
 137 immutable) and access to non-existing groups (esp. without an subsequent
 138 write that would actually create it) is rare, so the performance and
 139 memory overhead of this "eager" approach is likely to be negligible. as
 140 a middle way one could use a pointer and lazily populate it on first
 141 access whithout putting semantics into the pointer being already set,
 142 but i don't think the added complexity will pay off.
 143
 144 4)
 145 > > > > hmm, wait. maybe it would be better if the map did not do actual
 146 > > > > permission checking. the frontent is peppered with asserts already
 147 > > >
 148 > > > that's the group doing permission checking, if this group is immutable
 149 > > > then the entry can't be changed. plus, now that KEntryKey doesn't know
 150 > > > what group it belongs to KEntryMap can't check if the group is
 151 > > > immutable.
 152 > > >
 153 > > > > (need to consider how to handle release builds). in the backend, the
 154 > > > > ugly immutableGroups hack would be unnecessary.
 155 > > >
 156 > > > no, immutableGroups would still be necessary unless i remove all
 157 > > > checking from KGroupEntry and KEntryMap. but, then checks for
 158 > > > immutable would have to be used everywhere that an entry might be
 159 > > > changed.
 160 > > >
 161 > > yes - and the frontend already handles it and the backend *should*
 162 > > handle it (issue warnings for trying to overwrite $i settings).
 163 >
 164 > i don't know, i think most handling of the immutability of a group
 165 > can/should be handled by the KGroupEntry itself. this way we can keep
 166 > all the data about a group in one place and let KGroupEntry keep
 167 > itself in a consistent/valid state.
 168 >
 169 dunno, either. the use cases are:
 170 - backend: writing immutable objects is fine, as long as the
 171   immutability does not come from a pre-existing default.
 172   given that there will be multiple backends, it sounds like
 173   centralizing the check and warning reporting might make sense. otoh,
 174   such a low-level function might not have enough context to make a
 175   useful message.
 176 - frontend: obviously, writing immutable objects is not permitted. this
 177   is already checked everywhere through asserts. in non-debug builds
 178   these asserts have no effect, but if a write gets that far it means
 179   that the app already permitted changing the option in the first place
 180   due to failure to check for immutability. i don't see much point in
 181   preventing the illegitimate change from being saved, as it can be
 182   repeated anyway (i'm not really convinced of security through
 183   exhaustion/boredom of the attacker :).
 184 i'm not sure whether that means that the two use cases need separate
 185 mutators or whether the mutator should not apply any immutability
 186 semantics at all.
 187
 188
 189 overwriting semantics
 190 =====================
 191
 192 generally:
 193 - localized entries cannot exist without an unlocalized "primary" entry,
 194   so writing a localized key when no corresponding unlocalized key
 195   exists should print a warning and copy the value to the unlocalized
 196   key.
 197 - a primary entry in the user config overshadows not only the immediate
 198   default, but also any localizations of the default. applies also to a
 199   [$d] marker, obviously.
 200   a localized entry in the user config overshadows only that
 201   localization from the default.
 202
 203 write ops:
 204 > > - writing an entry with the localization flag changes really only that
 205 > >   key.
 206 > >   trying to change the globality of the key prints a warning and does
 207 > >   nothing.
 208 - key exists in local config => overwritten
 209 - key does not exist => created
 210 yes, that's the trivial case.
 211
 212 > > - writing an entry without the localization flag deletes all
 213 > >   localizations.
 214 > >   in this case, changing the globality of the key poses no problem.
 215 - the key itself is handled trivially
 216 - if localizations exist in the local config, they are actively purged
 217 - localizations in the default config don't matter, as they will be
 218   overshadowed by the unlocalized key in the local config
 219
 220 > > - deleting an entry also deletes all localizations.
 221 - if default exists, write [$d] entry
 222 - if no default exists, delete entry
 223 - if localizations exist in the local config, they are actively purged
 224 - localizations in the default config don't matter, as they will be
 225   overshadowed by the unlocalized key in the local config (as
 226   localizations cannot exist without a primary key, a deletion marker
 227   key will be present).
 228
 229 > > - reverting a key to default also restores all localizations.
 230 - any local entries are actively purged
 231
 232