A Qt replacement for KGlobal::ref and deref

[Andreas Pakulat]

On 17.02.11 13:43:11, Stefan Majewsky wrote:
> On Wed, Feb 16, 2011 at 5:31 PM, Aaron J. Seigo <aseigo at 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.