[Kde-games-devel] Data migration issue

[Mathias Kraus]

Am Samstag, 21. März 2015, 14:06:03 schrieb David Faure:
> On Saturday 21 March 2015 10:16:07 Mathias Kraus wrote:
> > Am Samstag, 7. März 2015, 14:43:14 schrieb laurent Montel:
> > > Le Saturday 07 March 2015 13:47:13 David Faure a écrit :
> > > > > KdePlatformTheme::loadSetting
> > > > 
> > > > This code runs before the application name is set, but the fallback to
> > > > argv[0] should still work. [This makes me realize that we should call
> > > > QCoreApplication::setApplicationName before creating the application
> > > > instance, everywhere.].
> > > > 
> > > > >  This function caches that instance of
> > > > > 
> > > > > KSharedConfig, which is working ontop of an empty file and thus does
> > > > > nothing.
> > > > 
> > > > Right. But that's exactly what reparseConfiguration() should fix, the
> > > > case
> > > > where the file on disk was changed.
> > > > Indeed, given that the migrator code is in kcoreaddons, it can't do it
> > > > automatically. (On hindsight, maybe the config migrator should have been
> > > > in
> > > > KConfig...)
> > > > 
> > > > I'm surprised that Laurent didn't hit this issue though?
> > > 
> > > No I never see it, and nobody reported it before that.
> > > So what is the fix that I need to do ?
> > 
> > The release is approaching really fast. We need a solution. What's wrong
> > with the migration before QCoreApplication creation? As far as I can see,
> > it's a plain copy from the old location to the new one.
> 
> Before QCoreApplication creation, toLocal8Bit / QFile::encodeName can be 
> wrong. Thiago has said many times that you're not supposed to use any Qt API 
> before QCoreApplication exists.
> 
> From this discussion it seems to me that a reparseConfiguration in the right 
> place would do.
> 
> But can we get a more complete bug report than "it doesn't work"?
> How do we reproduce this exactly?

Sorry, the first mail to kde-frameworks-devel should contain the conversation on kde-games-devel, but somehow it got lost.

I think the easiest way to reproduce it is with kmines, but the behavior is the same with 5-6 different games I tried.
1. start kdelibs4 version of kmines
2. change to a non default theme
3. run kf5 version of kmines
4. kmines starts with the default theme
5a. if kmines is closed and then started again, at least some migrated settings are used, e.g. high scores or window size
5b. if the user doesn't close kmines and changes some settings or plays a game and wins, some of the migrated settings will be overwritten

I already tried reparseConfiguration after the migration, but it didn't work.
This is the code I tried.
=======
KConfig config(QLatin1String("kminesrc"));
config.reparseConfiguration();
=======

I can provide you with a config file for kmines, if you need one. If you give me a hint where to use reparseConfiguration, I can also try to check if it works.

By the way, I'm using Qt5.4.1 and KF5.8 from kubuntu CI ppa. Three weeks ago the behavior was slightly different. If kmines-kf5 was closed right after the migration and started again, all the migrated settings were used, but now some are already overwritten when kmines is closed right after the first run. Also, previously if I played a game after the migration and won, all migrated settings were lost, but now noly e.g. the "easy" high scores are lost and all others are again there after a restart of kmines..
I didn't update libkdegames and kmines in the meantime, so the only difference is the Qt and KF5 version (was Qt5.4.0 and KF5.7+git???).

Albert Astals Cid was also able to reproduce this behavior a few weeks ago, so I guess it's not a problem with my local configuration.

Any help is welcome.
Regards,
Mathias