https://bugs.kde.org/show_bug.cgi?id=422529
feat...@engineer.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |feat...@engineer.com
--- Comment #15 from feat...@engineer.com ---
(In reply to Volker Krause from comment #8)
> I don't think KConfig is the right place for this. The library one happens
> to use for accessing a config file shouldn't just add its own vendor prefix.
> I can see why we might want some grouping of the config files, but that
> should be per product or product group (say Akonadi-based PIM or Plasma),
> not per config library vendor.
>
> Should someone want to implement this, this also needs considering migrating
> existing files and we need to account for application code that for whatever
> reason searches for config file locations manually. So this is much more
> than just adding an extra prefix in one place. Whether that effort/risk is
> worth the gain is another question.
What product groups are you suggesting?
I think having all KDE related configs in KDE is enough, and than it'd make
sense to have that prefix hard coded in kconfig.
But If you want to be more flexible, kconfig can add a prefix argument to the
load and save functions whose default is "kde", and have the products specify
their custom prefixes if they want to relate themselves to a certain product
family.
And for a smooth transition, the load function can be wrapped with a try catch
clause that would try to load with the prefix, and if it fails look for the
config outside the prefix and move it inside the prefix, living a symbolic link
outside.
--
You are receiving this mail because:
You are watching all bug changes.
