[Kde-games-devel] Porting Kigo - Paths

[Frederik Schwarzer]

Am Donnerstag, 5. November 2015, 02:45:34 schrieben Sie:
> Am Mittwoch, 4. November 2015, 21:46:37 schrieb Albert Astals Cid:
> > El Tuesday 03 November 2015, a les 00:41:32, Albert Astals Cid va
> 
> escriure:
> > > El Tuesday 03 November 2015, a les 00:32:18, Albert Astals Cid
> > > va
> 
> escriure:
> > > > El Thursday 29 October 2015, a les 03:13:37, Frederik
> > > > Schwarzer
> > > > va
> > 
> > escriure:
> > > > > On Wednesday, 28. October 2015 22:58:35 Albert Astals Cid
> 
> wrote:
> > > > > > El Wednesday 28 October 2015, a les 04:34:15, Frederik
> > > > > > Schwarzer va
> > > > > 
> > > > > escriure:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > question about paths.
> > > > > > > 
> > > > > > > Kigo saves to:
> > > > > > >     QDir::homePath()
> > > > > > > 
> > > > > > > which is $HOME and loads from
> > > > > > > 
> > > > > > >     KStandardDirs::locate("appdata", "games/")
> > > > > > > 
> > > > > > > which is $HOME/.kde/share/apps/kigo/games
> > > > > > 
> > > > > > Not really, it's also /usr/share/apps/kigo/games which on
> > > > > > my
> > > > > > system
> > > > > > has 2 installed system wide games.
> > > > > > 
> > > > > > > Despite of this seemingly odd discrepancy, what would be
> > > > > > > a
> > > > > > > good
> > > > > > > place for saving games?
> > > > > > > 
> > > > > > >     QStandardPaths::AppDataLocation ?
> > > > > > 
> > > > > > Since this is the behaviour of the kdelibs4 version i
> > > > > > don't
> > > > > > think it makes much sense to change is as part of the
> > > > > > porting.
> > > > > 
> > > > > If you say it like that, it does make sense. ;)
> > > > > Of course you are right. I tend to get carried away by the
> > > > > idea of
> > > > > removing obsolete things and clean-up in general while I'm
> > > > > at
> > > > > it. I
> > > > > will try not to mix this with porting.
> > > > > 
> > > > > > > Some games use DataLocation but that is stated
> > > > > > > deprecated
> > > > > > > in its
> > > > > > > description and AppDataLocation is suggested.
> > > > > > > http://doc.qt.io/qt-5/qstandardpaths.html#StandardLocati
> > > > > > > on
> > > > > > > -enum
> > > > > > > 
> > > > > > > I cannot play with paths in Kigo's frameworks branch
> > > > > > > right
> > > > > > > now
> > > > > > > since it is crashing on startup for me.
> > > > > > 
> > > > > > Let's fix that first :)
> > > > > 
> > > > > Not that easy. :)
> > > > > 1) it does not crash in KDevelop debugger here
> > > > > 2) KDevelop is somewhat broken here in Debian Sid and many
> > > > > things do not work properly. But anyway... GDB gives me a bt
> > > > > and I will investigate that.
> > > > 
> > > > Sounds like a bug in kpixmapcache.
> > > 
> > > https://mail.kde.org/pipermail/kde-frameworks-devel/2015-Novembe
> > > r/
> > 
> > 028261.html
> > 
> > Fixed in kdelibs4support now.
> 
> Nice. Thanks for digging into this. :)
> Now I just wait for the next release, which would be in less than
> two weeks, I guess?
> 
> So in the meantime I would like to put Kigo on hold and start with
> finishing the frameworks branch in KMahjongg. Unfortunately the
> history graph of the repo is messed up pretty badly. Check "gitk
> --all ." on it. So there might be a lot of cherry-picking needed to
> get all meaningful commits in the end. Or would it be better to
> "just" port, then merge and then look for lost commits for picking
> them to master?

Ok, if
    git log master ^frameworks --no-merges
does what stackoverflow.com is claiming it does, then there are only 
the last few commits missing in frameworks branch. So it should be 
alright.

Regards
Frederik