pcb:preferences_subsystem
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
pcb:preferences_subsystem [2020/06/28 18:15] cparker |
pcb:preferences_subsystem [2020/07/26 14:18] cparker |
||
|---|---|---|---|
| Line 81: | Line 81: | ||
| === Functions === | === Functions === | ||
| + | There are a number of key functions here: load_preferences, save_preferences, read_pref_file, write_pref_file, apply_preferences, collect_preferences, readers, and writers. Note that the file IO is being deliberately kept separate so that the actual file format is independent. Also, this allows data from a single file to be scanned more than once against different preference registries. We saw some pseudo-code for the load_preferences and save_preferences above (although it should have used apply_preferences and collect_preferences instead of spelling it out). So let's think about some of the others, again in pseudo-code (python...). | ||
| + | <code python> | ||
| + | def read_pref_file(filename): | ||
| + | with open(filename, r) as f: | ||
| + | f.seek(-1) # seek to the end | ||
| + | flen = f.tell() | ||
| + | r.rewind() | ||
| + | file_data = f.read(flen) | ||
| + | | ||
| + | # make sure to add a null at the end so file_data[flen] is a null char. | ||
| + | |||
| + | # find all the new lines | ||
| + | lines = [0] | ||
| + | for i in range(flen): | ||
| + | c = data[i] | ||
| + | if c == "\n": | ||
| + | data[i] = '\0' | ||
| + | if i + 1 < flen: # more data in file | ||
| + | lines.append(i+1) | ||
| + | | ||
| + | keys = [] | ||
| + | for l in lines: | ||
| + | # ignore lines that start with "#" | ||
| + | if data[l] == "#": continue | ||
| + | # ignore leading whitespace | ||
| + | i = l | ||
| + | while i < flen: | ||
| + | if data[l] in [" ", "\t"]: | ||
| + | i++ | ||
| + | | ||
| + | else: | ||
| + | keys.append[l] | ||
| + | break | ||
| + | | ||
| + | if len(keys) == 0: return | ||
| + | | ||
| + | values = [] | ||
| + | for k in keys: | ||
| + | i = k | ||
| + | while i =< flen: | ||
| + | c = data[i] | ||
| + | if (c == '\0') or (i == flen-1): | ||
| + | # no value for this key | ||
| + | # point it at the key? At a null? | ||
| + | values.append(i) | ||
| + | break | ||
| + | | ||
| + | elif c in [" ", "\t"]: | ||
| + | data[i] = '\0' | ||
| + | if i + 1 < flen: | ||
| + | values.append(i+1) | ||
| + | break | ||
| + | | ||
| + | i++ | ||
| + | | ||
| + | </code> | ||
| === File Format === | === File Format === | ||
| Line 104: | Line 160: | ||
| | drc-linewidth-min | 8 mil | | | drc-linewidth-min | 8 mil | | ||
| - | Thoughts on processing: | + | === Thoughts on processing === |
| I’ve also considered if there should be some type of hierarchical structure. Like for example, subsystems could register prefixes like “gtk-” with the system, and then the system passes them the preferences with that prefix. With the function calling system, I don’t think this is necessary. Although it is a good idea for subsystems to use such a prefix to make editing the files easier. | I’ve also considered if there should be some type of hierarchical structure. Like for example, subsystems could register prefixes like “gtk-” with the system, and then the system passes them the preferences with that prefix. With the function calling system, I don’t think this is necessary. Although it is a good idea for subsystems to use such a prefix to make editing the files easier. | ||
| - | Thoughts on implementation: | + | === Thoughts on implementation === |
| The pointer is probably often going to be the item that should be populated with the preference value, but doesn’t have to be. It could be the general preferences structure, for example, if there’s more than one parameter that needs to be updated. | The pointer is probably often going to be the item that should be populated with the preference value, but doesn’t have to be. It could be the general preferences structure, for example, if there’s more than one parameter that needs to be updated. | ||
| Line 117: | Line 173: | ||
| There will be a function for reading a preferences file, and a function for writing a preferences file. | There will be a function for reading a preferences file, and a function for writing a preferences file. | ||
| + | <code c> | ||
| void read_pref_file (char * fname) | void read_pref_file (char * fname) | ||
| { | { | ||
| Line 123: | Line 179: | ||
| /* open the file for reading */ | /* open the file for reading */ | ||
| } | } | ||
| + | </code> | ||
| + | <code c> | ||
| /* void pref_float (char * index_str, char * input_str, void *ptr) | /* void pref_float (char * index_str, char * input_str, void *ptr) | ||
| * This function takes an input string, converts it to a float, and assigns it to ptr. | * This function takes an input string, converts it to a float, and assigns it to ptr. | ||
| Line 139: | Line 196: | ||
| /* return 0; */ | /* return 0; */ | ||
| } | } | ||
| + | </code> | ||
| + | <code c> | ||
| /* char * float_pref(index_str, float fval) | /* char * float_pref(index_str, float fval) | ||
| * This function takes an input float and converts it to a string for storage in a preferences file. | * This function takes an input float and converts it to a string for storage in a preferences file. | ||
| Line 156: | Line 215: | ||
| return fstr; | return fstr; | ||
| } | } | ||
| + | </code> | ||
| - | Questions: | + | === Questions === |
| - | If a user loads a new preferences file, does it need to notify anything that this happened? | + | * If a user loads a new preferences file, does it need to notify anything that this happened? \\ Presently, with preferences, values are updated immediately. This means that all preferences need to be such that changing them at any given moment doesn’t lead to disaster. However, this model also provides the flexibility that, if there isn’t such a preference, it can specify its own handler function which could take care of any of the necessary tasks to enact the change. |
| - | Presently, with preferences, values are updated immediately. This means that all preferences need to be such that changing them at any given moment doesn’t lead to disaster. However, this model also provides the flexibility that, if there isn’t such a preference, it can specify its own handler function which could take care of any of the necessary tasks to enact the change. | + | * Should I try to use the glib class structure and create an actual manager object |
pcb/preferences_subsystem.txt · Last modified: 2021/02/28 19:56 by cparker
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
