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/07/26 13:58] cparker |
pcb:preferences_subsystem [2020/08/23 15:23] cparker Rename data structures. |
||
---|---|---|---|
Line 48: | Line 48: | ||
/*! value */ | /*! value */ | ||
char * value; | char * value; | ||
- | } PreferenceFileItem; | + | } PreferenceItem; |
</code> | </code> | ||
Line 55: | Line 55: | ||
<code c> | <code c> | ||
/*! | /*! | ||
- | * \brief PreferenceItem data structure | + | * \brief PreferenceDefinition data structure |
*/ | */ | ||
typedef struct | typedef struct | ||
Line 73: | Line 73: | ||
/*! a string that can be used to initialize the preference */ | /*! a string that can be used to initialize the preference */ | ||
char * default_str; | char * default_str; | ||
- | } PreferenceItem; | + | } PreferenceDefinition; |
</code> | </code> | ||
- | There will be a number of "reader"/"writer" functions implemented by default to handle common data types like floats, ints, coords, etc. The data pointer will be passed to the reader and writer functions, and could contain anything. But it probably is a pointer to the variable to be set by the converted value from the PreferenceFileItem. Using function pointers like this allows for a lot of flexibility in how subsystems can use this code. The reader functions, for example, may also be responsible for notifying a GUI that the preference has been updated. | + | There will be a number of "reader"/"writer" functions implemented by default to handle common data types like floats, ints, coords, etc. The data pointer will be passed to the reader and writer functions, and could contain anything. But it probably is a pointer to the variable to be set by the converted value from the PreferenceItem. Using function pointers like this allows for a lot of flexibility in how subsystems can use this code. The reader functions, for example, may also be responsible for notifying a GUI that the preference has been updated. |
Note: the default_str should initialize the value to something that is SAFE, i.e. something that will never, ever cause PCB to crash. | Note: the default_str should initialize the value to something that is SAFE, i.e. something that will never, ever cause PCB to crash. | ||
Line 160: | 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 217: | Line 217: | ||
</code> | </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 |