[Kde-games-devel] Data migration issue

Matthew Dawson matthew at mjdsystems.ca
Mon Mar 23 04:25:14 UTC 2015


On March 22, 2015 06:19:46 PM David Faure wrote:
> On Saturday 21 March 2015 23:53:07 Albert Astals Cid wrote:
> > Too late for KDE Applications 15.04 though now that i think, so maybe we
> > actually have to suggest everybody using the migrator to add those extra
> > lines?
> 
> OK, that means:
> 
> --- a/src/lib/util/kdelibs4configmigrator.h
> +++ b/src/lib/util/kdelibs4configmigrator.h
> @@ -60,6 +60,10 @@ public:
>       *    look for old data to migrate as well
>       * }
>       * @endcode
> +     *
> +     * IMPORTANT: after migrate() returns true, call
> KSharedConfig::openConfig()->reparseConfiguration() +     * so that the
> global config (very likely already created by e.g. the platform integration
> plugin) +     * can see the migrated data.
>       */
>      bool migrate();
> 
> But wait, this makes me realize another solution: kdelibs4configmigrator
> could load the framework integration plugin, which would take care of this,
> if installed.
> 
> Patch attached. Tested, at least to the extent that the slot is indeed being
> called.
> 
> Obviously that's still "too late for KDE Applications 15.04", so maybe fix
> the apps that you want to see fixed for 15.04 with a
> #if KCOREADDONS_VERSION < 0x050900
> KSharedConfig::openConfig()->reparseConfiguration();
> #endif
> 
> and KF 5.9 will make this unnecessary, i.e. the doc change won't get
> committed.
> 
> Any input?
I'm generally fine with this implementation, it seems like it would fix the 
problem.

I do have an alternate: would it be better to try and call into KConfig from 
KCoreAddons, iff both are loaded into the same process so that all 
KSharedConfigs could be reloaded after migration?  It creates a hidden 
dependency between them, but as long as it doesn't error out over while making 
the call, it shouldn't matter.  It would also handle the case the application 
isn't using frameworksintegration, but opened a KSharedConfig before.

My idea for calling across the libraries looks something like what I pushed 
here: git at git.kde.org:scratch/mdawson/kcoreaddons_talk_to_kconfig_base (hasn't 
propagated to the anon side yet).  Consider liblib1.so to be KConfig, and 
liblib2.so to be KCoreAddons.  

dlsym isn't portable though, so this idea would need some work on Windows.  
I'm just not sure how to implement that simply without OS specific code.  But 
I'm happy either way :)
-- 
Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150323/3a8e5bb5/attachment.sig>


More information about the Kde-frameworks-devel mailing list