cajhin wrote:my thoughts...
Ini files are kind of slow compared to binary data files. My plan is to have both: a human readable and editable and backupable ks.ini and a ks.dat. Both contain identical information, but only the latter is used by the app at startup because it is much faster. If you want to edit your shortcuts via ks.ini or you want to use a ks.ini prepare by some other user, there is a button that will translate it to ks.dat.
On KS edits via GUI both ks.ini and ks.dat will be updated on "Apply" and the app interface and KS-functionality as well immediately without restart.
Logically, the app will run on edited shortcuts without ks.ini being present. If no ks.dat is present the app will use the internal defaults.
cajhin wrote:A problem in some apps: it is a pain in the *** to figure out the name of the function you want to assign a key to.
I'd really like a nicely documented list of all functions.
One possibility:
Have a default ini that lists all functions, but assigns no keys. When the user adds a key combination, the default action for this key is then overridden.
Example ini:
Refresh_Tree= //update the tree panel on the left
Rebuild_Tree= //I have no clue what this does
Refresh_File_List= //updates the file panel on the right
Refresh_All=F5 //edited: Explorer-like refresh
Refresh_All=Ctrl+R //edited: another key for the same function
In this example, all shortcuts would trigger the hardcoded default action, except F5 and Shift-R (the last two lines), which have been edited/added by the user.
Yep, naming the functions is bit of a challenge.
I'm currently starting the CKS project with all functions available through
menus, which are quite a lot and luckily most of the important stuff is included here. An easy approach would be to use the menu structure for the naming convention, so e.g. "File_Info_PathName" should be sufficient to identify the command in menu "File|Info To Clipboard|Item Path/Name(s)".
However, if in future for some reason I reorganize that menu, the name "File_Info_PathName" will be misleading.
This will be no problem for the ks.dat file which will contain ordinal numbers only, no strings attached. But ks.ini ... needs a thought or two...
BTW, ini files have no inline comments (as in ... //comment) AFAIK. Only ";" at line start works as a comment marker.
cajhin wrote:One more thing: if you add new functions to the list, I would add them at the end, NOT alphabetically. That way, it is easy to check what new functions a new version offers that didn't exist back then when I customized my ini.
Yep, I will do this for another reason as well: functions will be internally identified by ordinal numbers. So new functions must be appended at the end.