Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move settings infrastructure into a separate mixin #694

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

W8BSD
Copy link
Contributor

@W8BSD W8BSD commented Jul 1, 2023

The settings "stuff" added in commit 3506133 is generally useful to other live drivers that want to expose settings, so split it out into a generic mixin rather than having it as part of the KenwoodD7Family class.

@W8BSD
Copy link
Contributor Author

W8BSD commented Jul 1, 2023

I'll fix up the style stuff, but I'm mostly worried about where I put the file... I haven't looked around to see how mixins are handled.

@W8BSD W8BSD force-pushed the Settings-Mixin branch 2 times, most recently from 6ad1f52 to ebb03ce Compare July 1, 2023 04:02
The settings "stuff" added in commit 3506133 is generally useful to
other live drivers that want to expose settings, so split it out into
a generic mixin rather than having it as part of the KenwoodD7Family
class.
@kk7ds
Copy link
Owner

kk7ds commented Jul 1, 2023

I'll fix up the style stuff, but I'm mostly worried about where I put the file... I haven't looked around to see how mixins are handled.

I'd have to look at what other live drivers have in the way of settings to see if this is actually useful for them in the way you have it, but I'm not sure we even have any other than kenwood ones. So I'd probably put it in kenwood_live (because some of the other drivers import/inherit from that base) or create a kenwood_live_settings or just keep it in kenwood_d7 until and unless you're planning to refactor some of the other drivers to use it. But yeah, in the drivers module is where it should go. That's all the "radio specific stuff" and there is other infrastructure that has different rules for that module than the rest of chirp.

@W8BSD
Copy link
Contributor Author

W8BSD commented Jul 2, 2023

So I'd probably put it in kenwood_live (because some of the other drivers import/inherit from that base) or create a kenwood_live_settings or just keep it in kenwood_d7 until and unless you're planning to refactor some of the other drivers to use it. But yeah, in the drivers module is where it should go. That's all the "radio specific stuff" and there is other infrastructure that has different rules for that module than the rest of chirp.

So yeah, my TS-2000 is using it as well, and I plan to detach that from d7, adding a new parent class for the two... but I can put it with the new parent class easily enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants