You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just noticed that we're setting the enclosure.platform config to mycroft_mark_2 on install.
Is that to get around people using if platform == "mycroft_mark_2" in Skills etc, when they want to check if a GUI is connected? Or are there other reasons a dev environment should pretend to be a Mark 2?
I can certainly see having a "Mark II" mode being useful - to try and emulate a Mark II setup as much as possible - config, correct dimensions, etc. But I'm wondering if that should be an intentional option rather than the default config?
It jumped out at me because if we are writing to a mycroft.conf file we'll need to switch to the XDG path for it instead of the hard coded value.
Any thoughts or preferences?
The text was updated successfully, but these errors were encountered:
Will add the configuration for platform to the dev_script.sh, the hardcoded path is in /etc/mycroft its at system level, so if mycroft-core does adopt xdg even at system level config, we can then switch to /etc/xdg/
I just noticed that we're setting the
enclosure.platform
config tomycroft_mark_2
on install.Is that to get around people using
if platform == "mycroft_mark_2"
in Skills etc, when they want to check if a GUI is connected? Or are there other reasons a dev environment should pretend to be a Mark 2?I can certainly see having a "Mark II" mode being useful - to try and emulate a Mark II setup as much as possible - config, correct dimensions, etc. But I'm wondering if that should be an intentional option rather than the default config?
It jumped out at me because if we are writing to a
mycroft.conf
file we'll need to switch to the XDG path for it instead of the hard coded value.Any thoughts or preferences?
The text was updated successfully, but these errors were encountered: