(2020-03-01, 23:31)NikosSiak Wrote: @garbear  Hi, we were talking with velocity in the irc channel about this https://github.com/xbmc/xbmc/blob/master/xbmc/cores/RetroPlayer/savestates/SavestateDatabase.cpp#L105 method. I wanted to implement this to do some PR for my submission and I have a question about the purpose of the method, should this method just change the label of the save state or it should also rename the stored file. I understand that the way the file is stored will change but for now should I implement this method (and/or the delete method)

(2020-03-02, 01:22)velocity Wrote: @garbear regarding the project description - do we even need to create/interact with a db for this? Can't we use the filesystem? So like, have a specific dir structure with games as dirs and saves / thumbnails would be placed in there. Or do we need to store more information we can't easily store on the filesystem?

(2020-03-05, 08:05)garbear Wrote:

(2020-03-01, 23:31)NikosSiak Wrote: @garbear  Hi, we were talking with velocity in the irc channel about this https://github.com/xbmc/xbmc/blob/master/xbmc/cores/RetroPlayer/savestates/SavestateDatabase.cpp#L105 method. I wanted to implement this to do some PR for my submission and I have a question about the purpose of the method, should this method just change the label of the save state or it should also rename the stored file. I understand that the way the file is stored will change but for now should I implement this method (and/or the delete method)

@NikosSiak you're uncovering the history behind the current code. Back in 2012 I applied for google summer of code, got rejected, and built the project anyway 6 months later: https://github.com/xbmc/xbmc/pull/1562

The database ended up being too slow and I threw away the code. Then, in 2016, realized I could reuse the slow database for savestates, which are simple don't require much scale: https://github.com/xbmc/xbmc/pull/11034

You'll notice that https://github.com/xbmc/xbmc/pull/11034 was opened the minute after RetroPlayer was merged in https://github.com/xbmc/xbmc/pull/11022

I purposefully left a stubbed savestate database in the RetroPlayer PR. As a result, the diff of the savestate PR is a clean example of implementing the function you linked: https://github.com/xbmc/xbmc/pull/11034/files#diff-81cbcf1dcefad7e8b8f21bee08b196adR97

Hope that helps. 

(2020-03-05, 20:00)NikosSiak Wrote: I implemented the delete method for some PR but now I see you have already done that in the past so there goes my PR 

(2020-03-05, 23:23)garbear Wrote:

(2020-03-05, 20:00)NikosSiak Wrote: I implemented the delete method for some PR but now I see you have already done that in the past so there goes my PR 

The implementation I wrote uses a database wrapper I don't think we should use. And keep in mind, adding the delete method means it needs to be accessible from the GUI, so some UI/UX work is going to be needed. 

(2020-03-06, 18:41)NikosSiak Wrote: Yeah I know but I started from the function, do you suggest to start the UI/UX work now and if so can you direct me to the file/class that the menu of retroplayer is rendered. 

(2020-03-11, 01:23)garbear Wrote:

(2020-03-06, 18:41)NikosSiak Wrote: Yeah I know but I started from the function, do you suggest to start the UI/UX work now and if so can you direct me to the file/class that the menu of retroplayer is rendered. 

From my experience, UI/UX work is incredibly difficult (but rewarding!) in Kodi, because the GUI and skinning engine is so massive. If you need a button, menu, dialog, or anything else in the GUI, ask me and I'll create a branch for you with the GUI element present and its implementation stubbed out. 

(2020-03-11, 11:47)black_eagle Wrote: @NikosSiak I believe the strings you are looking for are here.