Delete "Saving Settings" at close

[GoogleCodeExporter]

What steps will reproduce the problem?
1.open stoffi
2.work around it
3.close it

What should have happened?
It takes a little bit too much to close bcause of the saving stuff

What happened instead?
i wanted it to close istantly

Can you give us any additional information that could be useful in fixing
this bug? Just try to open and close it

What release of Stoffi are you using (Xia or Shang)?
Alpha one, downloaded yesterday

If you are using alpha or beta, please state which:
Qin Alpha two

Original issue reported on code.google.com by davidhau...@gmail.com on 9 Jul 2012 at 4:28

[GoogleCodeExporter]

We have been discussing this issue in the mailing list, why it exists and what 
we plan to do.

In short:
This is because the built in settings storage in .NET (which I use) is very 
slow, bad, horrible, and should die in a fire. We will change to something like 
SQLite or CouchDB instead. This will take a lot of work, Ryan suggested that he 
might take a look at it. Hopefully by changing the settings storage we can: 
make Stoffi use less RAM, make startup and shutdown faster, save settings as 
they are changed (in case of crash).

Original comment by christof...@stoffiplayer.com on 10 Jul 2012 at 8:29

• Changed state: Accepted
• Added labels: Milestone-Han, Priority-High

[GoogleCodeExporter]

I would lean towards SQLite over CouchDB. My understanding is that CouchDB is 
actually a fully blown database server whereas SQLite runs in-proc and has some 
level of synchronization. Out of curiosity, is there anything more complex than 
key-value pairs for simple types that need to be stored?

Original comment by zeigl...@gmail.com on 11 Jul 2012 at 1:33

[GoogleCodeExporter]

Yeah, SQLite looks the best but perhaps there is a NoSQL database that works 
just as SQLite (being embedded inside the application rather than stand alone).

The settings are everything from simple boolean (Pause playback when computer 
is locked) to data structures for tracks, keyboard shortcut profiles, etc.

Original comment by christof...@stoffiplayer.com on 11 Jul 2012 at 8:31

[GoogleCodeExporter]

So, I've been looking at this some more. I think I've found a potential nonsql 
embedded database in HamersterDB (http://hamsterdb.com/). It is C, so we would 
have to use P/Invoke and I'm not sure how Christoffer feels about introducing 
native code dependencies. It looks like more of a key/value store than anything 
else. 

Original comment by zeigl...@gmail.com on 25 Mar 2013 at 11:28

[GoogleCodeExporter]

NoSQL is not a requirement but was mostly a thought from my side if perhaps it 
would be more efficient (I don't know). Is there C# support for SQLite? Can we 
use HamsterDB in a Linux or OS X executable or would this mean that we could 
only use that backend on Windows?

No matter which approach we go with I think it would be feasible to just remove 
the dialog and do the settings saving in the background if no upgrade is 
pending (in which case, we save settings and then migrate them to the new 
version). This would let us close this issue without too much work.

Perhaps we should create a separate issue for switching out the settings 
backend. So we can track that independently.

Original comment by ephracis on 25 Mar 2013 at 2:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Settings backend is now in  issue #370 . I can take this issue.

Original comment by ephracis on 25 Mar 2013 at 3:05

[GoogleCodeExporter]

Dialog is now only shown when the app is being upgraded. Otherwise the saving 
of the settings is done in the background after the GUI has disappeared.

Original comment by christof...@stoffiplayer.com on 16 Apr 2013 at 5:57

• Changed state: Fixed
• Added labels: Milestone-Qin
• Removed labels: Milestone-Han