User Tools

Site Tools


pcb:preferences_subsystem

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision Both sides next revision
pcb:preferences_subsystem [2020/10/04 21:39]
cparker
pcb:preferences_subsystem [2020/10/25 16:18]
cparker
Line 14: Line 14:
 One of the considerations here is separating the storage and application so that the methods can change. If we decide we'd rather store preferences in an SQL database, we can do that without having to rewrite the whole system. We only have to write functions to load and save the key values pairs in the database. One of the considerations here is separating the storage and application so that the methods can change. If we decide we'd rather store preferences in an SQL database, we can do that without having to rewrite the whole system. We only have to write functions to load and save the key values pairs in the database.
  
-I'm not too worried about the speed of these routines, so, it doesn'​t matter much if the lists are sorted. Reading, applying, collecting, and writing preferences doesn'​t happen very often.+I'm not too worried about the speed of these routines, so, it doesn'​t matter much if the lists are sorted. Reading, and writing preferences doesn'​t happen very often.
  
-== Original Idea ==  +We'​re ​going to go with a two step processThe read and write functions will take a pointer to a list of PreferenceItemsThe readers and writers can interact explicitly with the data they are reading/​writing and there'​s no need to build an intermediate ​listThis better supports ​the option for alternate storage formats.
-Originally, I was going to do it this way... but this is just extra work. So, I'm ditching ​the intermediate ​step. +
-I'm breaking ​the preferences process into four steps:+
  
- # Read the preferences file and create a list of key value pairs (preference items) \\ pilist = ppm_read_pref_file(fname);​ \\ This returns a list of PreferenceItem objects that contains the keys and values read out of the specified ​file+  * load_preferences(file, ​preflist) 
- # Apply preferences to the PCB data structures \\ ppm_apply_preferences(pdlistpilist); \\ This iterates over the PreferenceItems in pilist. For each item it looks up the key in a preference definition list, pdlist, ​and calls the function associated with that preference ​definition+   - open the preference store 
- # Collect preferences from PCB data structures \\ pilist = ppm_collect_preferences(pdlist);​ \\ This goes through ​the preferences definitions in pdlist and creates a set of key value pairs, pilist, that can be stored in the text file. +   - for each item in the store 
- # Write the preference data to a file. \\ ppm_write_pref_file(pilist); \\ Store the preferences in a file.+   - Look up the preference ​in the preflist 
 +   - get reader: check for a reader in the structure ​and use it if it's there. Otherwise lookup the default reader for the preference ​type
 +   - apply the reader to set the preference 
 +  * save_preferences(preflist, ​file)
  
-== New Idea == 
-Instead we're going to go with just a two step process. The read and write functions will take a pointer to a list of PreferenceItems. The readers and writers can interact explicitly with the data they are reading/​writing and there'​s no need to build an intermediate list. This better supports the option for alternate storage formats. 
- * load_preferences(file,​ preflist) 
- *# open the preference store 
- *# for each item in the store 
- *## Look up the preference in the preflist 
- *## get a reader: check for a reader in the structure and use it if it's there. Otherwise lookup the default reader for the preference type. 
- *## apply the reader to set the preference 
- * save_preferences(preflist,​ file) 
- *# for 
  
 === Data Structures === === Data Structures ===
Line 258: Line 249:
  * When collecting preferences,​ do we collect everything, or only things that aren't the same as the default?  * When collecting preferences,​ do we collect everything, or only things that aren't the same as the default?
  * I've made an implicit assumption here that the preference keys are strings. Maybe I shouldn'​t?​ They could just be integers...  * I've made an implicit assumption here that the preference keys are strings. Maybe I shouldn'​t?​ They could just be integers...
 +
 +
 +==== Old stuff ====
 +== Original Idea == 
 +Originally, I was going to do it this way... but this is just extra work. So, I'm ditching the intermediate step.
 +I'm breaking the preferences process into four steps:
 +
 + # Read the preferences file and create a list of key value pairs (preference items) \\ pilist = ppm_read_pref_file(fname);​ \\ This returns a list of PreferenceItem objects that contains the keys and values read out of the specified file.
 + # Apply preferences to the PCB data structures \\ ppm_apply_preferences(pdlist,​ pilist); \\ This iterates over the PreferenceItems in pilist. For each item it looks up the key in a preference definition list, pdlist, and calls the function associated with that preference definition.
 + # Collect preferences from PCB data structures \\ pilist = ppm_collect_preferences(pdlist);​ \\ This goes through the preferences definitions in pdlist and creates a set of key value pairs, pilist, that can be stored in the text file.
 + # Write the preference data to a file. \\ ppm_write_pref_file(pilist);​ \\ Store the preferences in a file.
 +
 +== New Idea ==
  
pcb/preferences_subsystem.txt · Last modified: 2021/02/28 19:56 by cparker