[chirp_devel] Reprise of UI problem... HELP, please?!?!
HELP, please. I sent an earlier version of this message last week, but haven’t seen it in _devel list. I still am soliciting some pointers/help. I still work on the Yaesu FT1D radio, adding in multiple special memories and some digital settings and correcting a setting setup error that exists in the present FT-1D driver.
However, I cannot understand what I’ve done to the driver to cause the following problem. I KNOW the problem is my fault, because CHIRP_next does the change correctly, while it behaves incorrectly as described below when CHIRP_next is loaded with my modified driver. As a non-Python-er, I’ve even tried to interact with the driver while running, but haven’t a clue where to look or what to modify to get the output that’ll point to the problem. [I include a debug file from that CHIRP_next test.]
Bottom line request for help: How can I have affected the UI without having messed up my driver's structures? Or CHIRP’s mem structure either, AFAICT. Any guesses, please?
This UI silliness occurs in spite of the driver passing all tox tests for it: tox shows no syntax errors in the pep8 section, and tox -e driver -- -k Yaesu_FT-1D_R Indicates that my changed driver passes all tests (well, 31 passed and two skipped.)
When I load a bare FT1D file (presumably factory-fresh; actually a default file from Yaesu’s ADMS software for the FT-1D), the expected shows in the CHIRP UI: - Memory 1 (first slot, python index 0) has an entry of 145 MHz, FM - Eleven “Home" memories are defined as described in the manual. - The other 1100 memories show as empty [Although the files won’t show in the email summary, I attach two screenshots of that situation, both file labels showing “Bare FT1D”, but have removed them from this reprise.]
AFTER attempting to change the second memory slot (python index 1) to show 146 MHz, I expected the UI to auto-populate the rest of the line similar to what showed on the first memory (FM…). BUT: - Memory 2 UI now shows a label with an asterisk (almost surely indicating a change to that line) with the 146 I typed still in the frequency location; the rest of the line is blank - Home3 (!) UI now shows the correct Memory 2 line, along with label “2”, as if it were memory 2 [Two more screenshots labeled with “after mem 1 change” are no longer included but available.] - Looking at the browser, memory index 1 and Home1, Home2 and Home 3 all show the correct register information. [Two more screenshots after the changed include “browser” in the filename are no longer included.]]
- This type of problem occurs for every memory line up through 100, although it starts to populate the PMS specials memory lines.
BUT: If I save the file, exit and restart CHIRP, everything is in the ‘correct’ place. That’s in keeping with the browser having shown the correct data in the correct place!
Debug file, shows information from unmodified FT-1D module, and then the modified one after “load module”:
I’ve made significant changes to get_memory and set_memory, to settings sections and to my data structures. (I’m pretty sure the changes as they stand will break the Yaesu FTM3200 driver.) A copy of my modified ft1d.py:
______ Declan Rieb WD5EQY wd5eqy@arrl.net mailto:wd5eqy@arrl.net
AFTER attempting to change the second memory slot (python index 1) to show 146 MHz, I expected the UI to auto-populate the rest of the line similar to what showed on the first memory (FM…). BUT:
- Memory 2 UI now shows a label with an asterisk (almost surely indicating a change to that line) with the 146 I typed still in the frequency location; the rest of the line is blank
- Home3 (!) UI now shows the correct Memory 2 line, along with label “2”, as if it were memory 2
[Two more screenshots labeled with “after mem 1 change” are no longer included but available.]
- Looking at the browser, memory index 1 and Home1, Home2 and Home 3 all show the correct register information.
[Two more screenshots after the changed include “browser” in the filename are no longer included.]]
- This type of problem occurs for every memory line up through 100, although it starts to populate the PMS specials memory lines.
I haven't debugged your problem, but the reason for the UI disconnect is that you;'re returning an overlapping set of special memories with the regular ones. You need to map your special memories somewhere that does not overlap with the regular numbered memories (i.e. start right after the last regular memory). So when you edit memory 1, you'll notice that "Home2" actually changes waaay down at the bottom of the memory editor. During the initial load, you've returned a special memory with a number=1 and so chirp thinks that's where memory number 1 goes.
I'll take a todo to write a test to cover this if we really don't already have one.
A copy of my modified ft1d.py:<ft1d.py>
In the future, a draft github PR (or at least a diff) would be a lot easier to look at and pull down to try. However, you've got a ton of change in your .py file from current master, which makes it really hard to tell what all you've changed. Please do split that up into pieces before you submit, otherwise it'll be really difficult to review.
--Dan
I'll take a todo to write a test to cover this if we really don't already have one.
Okay, I wrote that up:
https://github.com/kk7ds/chirp/pull/633
I'll wait to merge that until we have something else meaningful. It passes on everything in the tree and fails on your driver, warning about the overlapping number space.
--Dan
Which docstring formatting standard am I supposed to be using? I noticed that some existing docstrings place an @ in front of parameter names in-line with otherwise unformatted descriptions, but that doesn't correspond to any of these:
Epytext syntax:
@type num_dogs: int @param num_dogs: the number of dogs
Sphinx syntax:
:param param1: The first parameter, defaults to 1. :type: int
Google syntax:
Args: param1 (int): The first parameter.
NumPy syntax:
Parameters ---------- param1 : int The first parameter.
Which docstring formatting standard am I supposed to be using? I noticed that some existing docstrings place an @ in front of parameter names in-line with otherwise unformatted descriptions, but that doesn't correspond to any of these:
Yeah, the @paramname stuff is from me I'm sure, based on something I was using (not for chirp) more than ten years ago.
Sphinx syntax: :param param1: The first parameter, defaults to 1. :type: int
This is my current preferred way of doing it, based on code I write elsewhere and for which it matters.
--Dan
participants (3)
-
Craig Jones -
Dan Smith -
Declan Rieb