[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] Data migration issue
From:       Mathias Kraus <k.hias () gmx ! de>
Date:       2015-03-04 17:16:06
Message-ID: 40729917.sFuQqi6lvK () io
[Download RAW message or body]

Am Mittwoch, 4. März 2015, 10:04:11 schrieb Matthew Dawson:
> On March 3, 2015 10:59:21 PM Mathias Kraus wrote:
> > Hi,
> > 
> > I noticed a problem with the data migration in the kdegames transition from
> > kdelibs4 to kf5 and Albert Astals Cid suggested to ask frameworks devel for
> > advice.
> > 
> > In short, when the migration is run after the QCoreApplication is created,
> > the migrated config is not used but the default values. This results in a
> > lost migration if the users changes some settings during the first run of
> > the kf5 version of the game. Also, if the user plays a game and wins, all
> > the previous high scores will be lost. Ian Wadham assumes there will be
> > also other issues.
> > 
> > If the migration is run before the creation of the QCoreApplication, it
> > seems to work correct.
> Taking a look into what is happening, it appears that other libraries are 
> accessing the kminesrc file once QCoreApplication is created by using 
> KSharedConfig::openConfig.  This function caches that instance of 
> KSharedConfig, which is working ontop of an empty file and thus does nothing.
> 
> One backtrace I got looks like:
> #5  0x00007ffff5adc3c0 in KSharedConfig::openConfig (_fileName=..., flags=..., 
> resType=QStandardPaths::GenericConfigLocation) at 
> /home/matthew/kde/kconfig/src/core/ksharedconfig.cpp:87
> #6  0x00007fffe21ed296 in KHintsSettings::KHintsSettings (this=0x683380) at 
> /usr/src/debug/kde-
> frameworks/frameworkintegration-9999/frameworkintegration-9999/src/platformtheme/khintssettings.cpp:65
>  #7  0x00007fffe21e94f7 in KdePlatformTheme::loadSettings (this=0x67f930) at 
> /usr/src/debug/kde-
> frameworks/frameworkintegration-9999/frameworkintegration-9999/src/platformtheme/kdeplatformtheme.cpp:121
>  #8  0x00007fffe21fc6bb in KdePlatformThemePlugin::create (this=<optimized 
> out>, key=..., paramList=...) at /usr/src/debug/kde-
> frameworks/frameworkintegration-9999/frameworkintegration-9999/src/platformtheme/main.cpp:52
>  #9  0x00007ffff4aaa44e in qLoadPlugin1<QPlatformTheme, QPlatformThemePlugin, 
> QStringList> (parameter1=..., key=..., loader=0x7ffff4f63ab0 
> <_ZZN12_GLOBAL__N_112Q_QGS_loader13innerFunctionEvE6holder>) at 
> /usr/include/qt5/QtCore/5.4.0/QtCore/private/qfactoryloader_p.h:107
> #10 QPlatformThemeFactory::create (key=..., platformPluginPath=...) at 
> kernel/qplatformthemefactory.cpp:64
> #11 0x00007ffff4ab4012 in init_platform (argv=0x7fffffffce58, 
> argc=@0x7fffffffcc7c: 1, platformThemeName=..., platformPluginPath=..., 
> pluginArgument=...) at kernel/qguiapplication.cpp:1045
> #12 QGuiApplicationPrivate::createPlatformIntegration (this=0x63dec0) at 
> kernel/qguiapplication.cpp:1166
> #13 0x00007ffff4ab4ced in QGuiApplicationPrivate::createEventDispatcher 
> (this=<optimized out>) at kernel/qguiapplication.cpp:1183
> #14 0x00007ffff4704126 in QCoreApplication::init 
> (this=this@entry=0x7fffffffcd30) at kernel/qcoreapplication.cpp:727
> #15 0x00007ffff4704186 in QCoreApplication::QCoreApplication 
> (this=0x7fffffffcd30, p=...) at kernel/qcoreapplication.cpp:650
> #16 0x00007ffff4ab6ea9 in QGuiApplication::QGuiApplication 
> (this=0x7fffffffcd30, p=...) at kernel/qguiapplication.cpp:560
> #17 0x00007ffff50c0c05 in QApplication::QApplication (this=0x7fffffffcd30, 
> argc=@0x7fffffffcc7c: 1, argv=0x7fffffffce58, _internal=328704) at 
> kernel/qapplication.cpp:562
> #18 0x000000000042d68c in main (argc=1, argv=0x7fffffffce58) at 
> /home/matthew/kde/kmines/main.cpp:35
> 
> Which I think might be avoidable anyways, as the hints should only read from 
> the globals?  Migrating first would of course avoid this issue (but see 
> below), and I think calling reparseConfiguration after migrating may also 
> work.  Alternately, tracking down why kminesrc is opened early might be 
> another solution.

Unfortunatelly, calling reparseConfiguration doesn't solve the problem.

> > 
> > Laurent Montel, the creator of kdelibs4configmigrator, suggests the former
> > procedure (first QCoreApplication, then migration), though.
> If kdelibs4configmigrator uses KConfig itself for anything, then it really 
> should only be used after QCoreApplication is created.  Doing otherwise is 
> very fragile and may break in the future.
> 
> Hope that helps,

It seems kdelibs4configmigrator doesn't use KConfig but just copies the files to the \
new location.

Laurent, what's the reason to suggest to do the migration after QCoreApplication is \
created? Might someting breake in the future?

Regards,
Mathias
_______________________________________________
kde-games-devel mailing list
kde-games-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel


[prev in list] [next in list] [prev in thread] [next in thread]