[Kde-games-devel] Data migration issue

[Albert Astals Cid]

El Dilluns, 23 de març de 2015, a les 00:25:14, Matthew Dawson va escriure:
> 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.

But then that's the application fault and it shouldn't be doing that thing 
before migrating their configs.

The issue here is that frameworksintegration is there messing with the configs 
before the app can decide to migrate them.

Cheers,
  Albert