Open turdusmerula opened 6 years ago
In progress. I implemented it in the part_management branch, this needs some tests in windows environment prior to merging.
I will look into this now I have merged with branch part_management
I have updated with the following commits , Whilst I have not done extensive testing these commits gets my working copy running
Commit | Detail |
---|---|
https://github.com/turdusmerula/kipartman/commit/1553d0c98cd22f17230dc6570a22adc48c566664 | enables working functionality under MSW, However I think it may fail in Linux if kicad was not found (returning a None) appeared to not be valid value, suggest check if ok |
https://github.com/turdusmerula/kipartman/commit/6c3240e50fb135e13b18bd017ce0afddcbe3383c | Configuration, display Message on successful Test (Octopart,SnapEda) |
https://github.com/turdusmerula/kipartman/commit/a7031156b1fc4d0480de57d0017a1fb0b5459d93 | Octopart Apikey not being retrieved from configuration for edit part, octopart querie |
TODO's for possible looking at or raising as issues
Area | Detail |
---|---|
General Configuration | what is the optimum design pattern for accessing global config data, what are the alternatives, is there a penalty from doing configuration.Load() at each call in something like doing an Octopart Query |
Configuration_frame self.dir_kicad_path.SetPath | Check under Linux if kicad not installed that it does not return None, SetPath did not seem to handle None, Maybe we should allow SetPath to be None |
The configuration object is a singleton and should maintain itself up to date upon user configuration from kipartman. The best pattern for me is to always read the configuration object fields and not cache them inside other parts of kipartman. Load() should only be called on configuration update. This behavior was not clear when I first wrote code that uses configuration so you may still find some code in contradiction with this pattern, this should be considered as a bug.
There is still items to be added to the configuration windows: