Config file support #16
Comments
|
Just have a config.txt, look for ` def configLoad(initConf): ` |
|
TODO: Once this is done, please call See also |
|
I started working on this in the Trigger Selector ticket. See here for more info: |
|
It appears that I'm already using this kivy Config module!
I set two options to change the following behaviours:
Interestingly these settings didn't persist in the kivy config file. My guess is that's because I'm only applying them at runtime at the start of |
…rser object and the App's build_config() method * #16 TODO: update the `setupDatDir()` to prioritize $XDG_CONFIG_HOME on linux systems * https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables * #39
|
In the above commits, I was successfully able to combine the kivy and buskill files into one ini config file, but unfortunately I cannot prevent kivy from creating the Kivy will allow you to specify where its data dir is with the environment variable So the only way to catch this early enough would be to move the logic for determining DATA_DIR to |
|
Today I successfully moved the instantiation of the buskill object into |
|
Today I successfully got the kivy built-in settings widget to be loaded in the Settings screen of the BusKill app. TODO: figure-out how to limit the settings items that are enumerated to only those in the |
|
ok, using the built-in settings widget and a new json file, I was successfully able to limit the config items appearing in the Settings Screen to only the "trigger" key/value, as defined in a json template (which is actually distinct from where the value is stored-to--that's still always the .ini file) Though this is very robust, I still need to extend the Settings widget because:
|
This commit is the fruitful effort of tying to figure out the structure of the Kivy Settings classes. Finally, this commit, I was able to remove the title of the Settings panel so it no longer says 'buskill' at the top -- not needed since we only have one "section" s.children[0].children[0].children[0].remove_widget( s.children[0].children[0].children[0].children[1] ) This is pretty ridiculious, but I learend: 1. the 'children' attribute of a given kivy widget is not recursive, so you have to use walk() 2. If you run remove_widget() directly on a root's grandparent, it won't work. You need to find the right widget and remove it directly from its parent 3. Somehow the title of the section appears before the options inside that title? This commit also overrides three Settings classes from kivy/uix/setings.py, but I'm still experiementing. My goal was to just change the way things are displayed, but it's buried in so many levels of inheretance that it's not trival. TODO: figure out the structure better and document it here: * #16
Understanding kivy's
|
|
From above, I'd guess that the
Example execution: With that, I printed a bunch of info about the Output I can see here that there's a |
|
If I try to set it to the empty string, it works -- but there is an empty label there taking up space. If I try to set it to ..then I get an error However, I found I could do this more sanely as follows |
…the `InterfaceWithNoMenu`'s `current_panel` instance field and looping through that panel's children to remove the Label. See also: * #16 (comment)
|
Finally, I found the relevant This excerpt from the |
|
SettingOptions is defined, but it leaves much to wonder how it works ...but when you check the code, you see that https://github.com/kivy/kivy/blob/2efdc2646147e5604767b8a5c6a43e5808455bf2/kivy/uix/settings.py#L612 So if I want to define an icon for each item in this list, it looks like I'll at least need to override the |
|
I finally figured out why overriding a kivy widget's kv-language only added-to (instead of replaced) the existing widget's layout. As the above documentation describes, you need to change with this (you add a dash before it to clear it) |
This commit finally solved the puzzling issue where I kept trying to change the layout for a given widget that I'm overriding (in this case the SettingsPanel with BusKillSettingsPanel), but it somehow just added the layout on-top of the existing layout. For example, I couldn't get rid of the label at the top of SettingsPanel. Even if it was absent in BusKillSettingsPanel and I used only BusKillSettingsPanel.
Solution: If you want to completely override a given classes' layout in kv-language, you must prepend a dash (-) before the definition.
For example, don't use this:
<BusKillSettingsPanel>:
spacing: 5
padding: 5
size_hint_y: None
height: self.minimum_height
Use this:
<-BusKillSettingsPanel>:
spacing: 5
padding: 5
size_hint_y: None
height: self.minimum_height
See also:
* https://stackoverflow.com/questions/74467933/how-to-override-built-in-kivy-widgets-and-their-kv-language-layouts
* https://kivy.org/doc/stable/api-kivy.lang.html#redefining-a-widget-s-style
* #16 (comment)
This commit finally managed to get the 'icon' and 'key/value' widgets in one row of our ComplexOption setting (the "Trigger") on the Settings Screen's SettingsPanel to appear side-by-side such that each label took up only the width it needed, and that the text wrapped on the key/value widget inside a StackLayout. See also: * https://stackoverflow.com/questions/74482717/why-is-declaring-size-x-and-size-y-different-from-delcaring-both-in-size-i * https://stackoverflow.com/questions/74480862/side-by-side-labels-in-stacklayout-why-is-second-label-missing-kivy-python/74482434#74482434 * https://stackoverflow.com/questions/74480089/equivalent-of-browser-debuggers-box-model-inspector-in-kivy * #16
|
Yesterday I finished replacing the popup when choosing the value for a given key that's an option (equivalent of a radio button in html). Instead of doing this in a very restrictive and poor-UX modal popup, we dynamically create a new screen where the user can have more information about each option in a scrollable view without it being cluttered in the modal. This includes:
The layout of rows of options will be similar to the layout of rows of settings on the previous screen, which is a tree as follows |
added a scrollview and grid layout to the BusKillSettingsSomplexOptionsScreen added a hard-coded example of an option for a given setting (this is like a radio button for a set of values that can be chosen for a given setting) TODO: actually populate the options dynamically, not hard-coded * #16 (comment)
|
Yesterday I got the changes made in the GUI's Settings Window to actually write the changes to the now-combined buskill/kivy .ini file TODO: Add the ActionItem at the top for help for the given ComplexOption's Screen |
|
Today I finished with the UI for displaying the help message when a "help" button icon is pressed in the BusKillSettingsComplexOptionsScreen's ActionBar TODO: implement the "reset" button to restore the defaults for all settings (after confirmation) on the main Settings screen |
|
Today I finished with the logic to actually update the runtime BusKill object's Also I updated the "BusKill is currently armed" text on the MainWindow Screen to include which trigger it's armed-with. This should avoid ambiguity to the user. Finally, I noticed that the nav drawer is open when exiting the Settings Screen. TODO: fix nav-drawer-open bug |
|
Note to self: if you see this error ..then it means you need to add a key/value pair to the defaults defined by |
|
I fixed a logic bug where I was attempting to re-arm whenever leaving the Settings screen -- but it really should only happen when leaving the Settings Screen and going back to the Main Screen. It should not attempt to re-arm when leaving the Settings Screen and going into a ComplexOptions Screen. TODO: fix a lot of bugs where the value is correct in the config file after reset, but the value is not correct on the Settings Screen or the wrong option is selected in the ComplexOption Screen |
|
I'm a bit confused as to why my For example for the "trigger" option, I'd think that the title should be I'd like to change this, but it may break things and take a while to fix :( |
…usKillOptionItem in the next commit. Wish me luck. * #16 (comment)
…"value" instead of "title" on the BusKillOptionItem objects * #16
|
I fixed the
The above message does not show-up the first time I click on the "trigger" option on the Settings Screen. It does show-up if I go back and then click on "trigger" again. The thrid time I click on it, I get this And the fourth The first message lists 4x |
|
ok, I fixed the infinite screen creation |
|
I also fixed the navbar drawer staying open. As I cleanup the code, I went ahead and added some test options for all the other kivy types While these new options generally "just work" -- the reset button does not work for them. TODO: see if clearing the widgets from the Settings screen and re-running the init() (as we were doing before) now works for those. I think maybe the "multiple screens" bug may have caused that to not work? Otherwise I'll just have to iterate into each of those settings and update them to match the config file, not too hard. |
|
I fixed the reset button to reset the built-in kivy types too. For future reference (when we will add more options that my be of the built-in kivy types), here's what that looks like: buskill-app/src/packages/buskill/settings_buskill.json Lines 25 to 60 in fbfa7fa buskill-app/src/buskill_gui.py Lines 1163 to 1172 in fbfa7fa |
|
Today I did a lot more cleanup of the At this point, I think this feature might be complete? I think I should just test the build on all three platforms. If all is well, then maybe I can merge it into dev! |
|
As far as I can tell, this feature is done. See testing in #14 for more info. I'm merging this into |
Config File to manage various settings within the application,
such as Trigger and Device.
This will allow for:
-> Modular Trigger System (expanding to a DIY Trigger oppurunity)
-> Preferred Device (i.e. if you have a device you routinely removed and would like BusKill to ignore its event)
-> a "First Start" sequence to allow for first time configuration
Once Configuration Files are an option within BusKill we can perform further enhancements such as:
-> update frequency
-> Trigger EcoSystem
The text was updated successfully, but these errors were encountered: