On 17.02.11 13:43:11, Stefan Majewsky wrote: > On Wed, Feb 16, 2011 at 5:31 PM, Aaron J. Seigo <ase...@kde.org> wrote: > > which begs the question: "is KConfig (as ane exmple) platform or app dev"? > > fun > > conversations to be had and digging to be done :) > > From my experience, KConfig is actually two things at once: > > 1. framework for reading and writing INI-like files > 2. utility for locating and merging user-specific plus system-wide > configuration > > Only part 2 is platform. Part 1 is already a great thing in itself > even if applied to single files. Usages of KConfig for the purpose of > defining custom, human-readable file formats include (here in > kdegames) KGameTheme description files, Palapeli puzzle metadata, > Palapeli collections, Kolf courses, etc.pp. Part 2 is "just" a bonus > for application configuration files, just like KConfigXT which is not > useful for custom file formats. > > So a possible idea could be to refactor the KConfig class into two > classes, one for stand-alone config files and one for application > configuration in KStandardDirs' "config" prefix. The latter class > would then move into the KDE platform thingy, while the other one does > not have any KStandardDirs dependency. (Dunno about other low-level > dependencies, though.)
I don't see why 2. would be a platform-thingie. Its useful for an app itself when it needs to have different levels of configuration where a more specific level needs to be able to override a more general level. Think of apps that have some kind of session, some settings might be useful across all sessions you use, but some are specific to a given session. So I actually think there are 3 parts in KConfig: 1. ini-style reading/writing 2. merging of kconfig-files representing different level of configuration 3. locating of config-stuff And here the 3. one would be platform-thingie (unless one has a backend for different platforms). Andreas -- Save energy: be apathetic.