Re: [chirp_devel] [CHIRP - Feature #10929] (Closed) TYT UV8000D Add Menu Number to Settings and improve descriptions
Howdjadothat? I never got around to a pull request, but thanks.
On 11/7/2023 3:30 PM, Dan Smith wrote:
Issue #10929 https://chirp.danplanet.com/issues/10929#change-39849 has been updated by Dan Smith.
- *Status* changed from /New/ to /Closed/
- *% Done* changed from /0/ to /100/
Applied in changeset github|6b083e22e4af9ce577564e27051b0226c928eee2 https://chirp.danplanet.com/projects/chirp/repository/github/revisions/6b083e22e4af9ce577564e27051b0226c928eee2.
Feature #10929: TYT UV8000D Add Menu Number to Settings and improve descriptions https://chirp.danplanet.com/issues/10929#change-39849 closed
- *Author: *Rick DeWitt
- *Status: *Closed
- *Priority: *Normal
- *Assignee: *Rick DeWitt
- *Category: *UI Features
- *Target version: *chirp-py3
- *Start date: *2023-11-05
- *Due date: *2023-12-25
- *Chirp Version: *next
- *Model affected: *TYT UV-8000D
- *I read the instructions above: *Yes
User requested the addition of the radio menu sequence number to the Settings parameters. Good idea!
You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://chirp.danplanet.com/my/account
Howdjadothat? I never got around to a pull request, but thanks.
Oops, I must have fat-fingered a bug number, this was not something I intended to close!
On the subject, I kinda don't like the idea of like prefixing all the menu names with their numbers. I can see the utility of comparing them to the radio or the manual, but I think it will make the interface look more cluttered.
What about putting those in the doc text for each item and making it visible some other way, like a tooltip? I don't think I'm exposing the doc text on the settings items, but I should try to do that and if so, that would be a better place, IMHO.
--Dan
It doesn't look too bad-
The "--" indicates a s/w only parameter. You can leave it closed, I am going to finish it today. I think I finally understand "Epilogue" and how ANI/PTT-ID are used.
On 11/7/2023 8:15 PM, Dan Smith via chirp_devel wrote:
Howdjadothat? I never got around to a pull request, but thanks.
Oops, I must have fat-fingered a bug number, this was not something I intended to close!
On the subject, I kinda don't like the idea of like prefixing all the menu names with their numbers. I can see the utility of comparing them to the radio or the manual, but I think it will make the interface look more cluttered.
What about putting those in the doc text for each item and making it visible some other way, like a tooltip? I don't think I'm exposing the doc text on the settings items, but I should try to do that and if so, that would be a better place, IMHO.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs:http://chirp.danplanet.com/projects/chirp/wiki/Developers
It doesn't look too bad-
It looks messy to me. Anyone else have an opinion?
What about putting the menu number after the text in parens? Like "Voice (22)".
--Dan
It looks messy to me. Anyone else have an opinion?
I'm not in favor of doing this. I've maintained drivers for which the menu numbers are in a different order based on the vendor/model of the radio that is being supported. Menu 50 of one vendor may be menu 15 for another.
I have one driver that I am working on now that it is not uncommon for a new firmware of a particular model to insert a new setting which bumps up the number of all of the menus following it. It is hard enough to keep track of which menu settings are being used between vendors, models and firmware versions. It sometimes takes a lot of juggling to make it work. I can't imagine adding menu numbers to the mix.
I can see tickets being opened because the menu numbers don't match, menu numbers are missing (such as the ones for per-channel settings) and/or settings not being in numerical order.
Just my 2 cents.
Jim KC9HI
I have one driver that I am working on now that it is not uncommon for a new firmware of a particular model to insert a new setting which bumps up the number of all of the menus following it. It is hard enough to keep track of which menu settings are being used between vendors, models and firmware versions. It sometimes takes a lot of juggling to make it work. I can't imagine adding menu numbers to the mix.
I can see tickets being opened because the menu numbers don't match, menu numbers are missing (such as the ones for per-channel settings) and/or settings not being in numerical order.
Oh yeah, this pretty much seals it I think. Differing between clones of a given thing isn't something I even thought about, but is an excellent point. Taking the firmware argument, the UV-K5 has multiple threads of firmware development going on, amongst not only the OEM but other community groups, so there's no way that's staying consistent.
TBH, I've always preferred the settings in the software to be more human-friendly than you can usually be on the radio anyway, instead of trying to be faithful to the radio itself. Showing "STE" on the radio due to limited display space is much less helpful than "Squelch Tail Elimination" for example. My experience with most commercial software works this way too.
--Dan
OK. No more work on that feature, no driver change. I do need to get the "Special Channels" displayed at the end of memory. New issue # forthcoming.
On 11/8/2023 3:51 PM, Dan Smith via chirp_devel wrote:
I have one driver that I am working on now that it is not uncommon for a new firmware of a particular model to insert a new setting which bumps up the number of all of the menus following it. It is hard enough to keep track of which menu settings are being used between vendors, models and firmware versions. It sometimes takes a lot of juggling to make it work. I can't imagine adding menu numbers to the mix.
I can see tickets being opened because the menu numbers don't match, menu numbers are missing (such as the ones for per-channel settings) and/or settings not being in numerical order.
Oh yeah, this pretty much seals it I think. Differing between clones of a given thing isn't something I even thought about, but is an excellent point. Taking the firmware argument, the UV-K5 has multiple threads of firmware development going on, amongst not only the OEM but other community groups, so there's no way that's staying consistent.
TBH, I've always preferred the settings in the software to be more human-friendly than you can usually be on the radio anyway, instead of trying to be faithful to the radio itself. Showing "STE" on the radio due to limited display space is much less helpful than "Squelch Tail Elimination" for example. My experience with most commercial software works this way too.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs:http://chirp.danplanet.com/projects/chirp/wiki/Developers
participants (4)
-
Dan Smith -
Jim Unroe -
Rick (AA0RD) DeWitt -
Rick DeWitt