|
Post by Jo on Aug 21, 2019 14:22:42 GMT -5
Names: I like the name SPFLite, especially since it is not a lite version :-)
Visibility-Export: I have 3 PCs at home, all with SPFLite installed. Years ago, all Config- & .ini files were equal, but as time goes by, there are differences. So after some month I compare the spflite.ini and the KBD-files, just to see, if I had any good idea on any one PC. Changes are of course only done with the standard OPT or KEYS command. So, if there is an easy way to make the config visible, fine, but it's not really a requirement, I can use KEYS LIST to see & compare the key-definitions.
Jo
|
|
|
Post by Stefan on Aug 22, 2019 8:01:05 GMT -5
Having at least in part kicked-off this debate by requesting a shared macro library, here goes my 2 penneth worth...
Use of SQLite... I guess the main reason for this is to allow shared read/write access to settings in a controlled manner. It is more complex than the existing INI file and it does place (yet another) reliance on an external product. In terms of its reliability, SPFLite is in good company of other big-name exploiters, and SQLite's developer promises to maintain backward compatibility until 2050. Good enough.
Backup/Restore - Assuming any given physical file in the new "data & control" structure stands alone, (i.e. individual config and/or other settings and values are not spread around multiple physical files with cross-reference/dependency on each other) any normal backup application can be safely used to provide backup and restore. I don't perceive a need for an application-specific backup/restore capability, unless groups of files MUST be treated as one logical entity.
Import/Export - George what you're proposing is fine with this user's expectations.
Naming - I note that the concept of "versions within Releases" when most other software (including the inspirational ancestor SPF) operate with "releases within Versions" is unusual. For the new name, you might also consider... (wait for it while I place my tongue firmly in cheek), SPFLiteNT to reflect use of the new technology (database).
Oh and... Didn't you guys say there would be no significant further development of SPFLite after your retirement? Thanks again for still driving this project along.
|
|
|
Post by George on Aug 22, 2019 10:14:51 GMT -5
The "new" SPFLite CFG file is self contained and holds everything in the former SPFLite.INI/KBD/BKP/SPR/SPS files along with ALL the files in the \Profiles folder. This is how the new Instance support can handle an Instance that, say, has it's own INI settings, shares the KBD settings, has its own SET variables etc. Another Instance might have it's own custom KBD.
The CFG file will be allowed to reside anywhere (even on a network drive). The remaining data files (AUTO, MACRO, FILELIST, CLIP etc. can reside within the CFG file folder, or placed somewhere else. Instances could even have their own unique data folder for these data files (not sure why anyone would do that, but ...). I've tried to allow you to put all this stuff where YOU want it.
Or like me, I will keep the CFG file in good old \Documents\SPFLite along with all the old data folders.
There are no dependencies between any of the files. Well, no more so than there is now between all this stuff.
As to names, I agree with Stefan on version/release and like SPFLiteV2, any violent objections?
George
|
|
|
Post by George on Aug 22, 2019 14:24:39 GMT -5
OK, I'm making it SPFLite2. Done.
George
|
|
|
Post by George on Aug 28, 2019 13:00:24 GMT -5
I had been concerned about the performance aspects of switching from plain text INI files to an SQL Database. After some testing using my latest test version, I think we're just fine. Here's some results, the timings are simple 'watch the clock', so are very rough. I timed from the click of the Icon to start the program until the FM screen appeared. The EXE file was also stored on the test device. This process requires a read of all the parameters from all the various tables. Each test was done 2-3 times and averaged. George
|
|