search

marmelo / gqrx-remote

Remotely control gqrx while keeping your bookmarks in order.
MIT License
39 stars 15 forks source link

Accept flexible frequency value strings #5

Open nellump opened 10 years ago

nellump commented 10 years ago

Currently, gqrx-remote.py only accepts frequency values specified without multiples (i.e., no "kHz", "MHz", etc.). Values may or may not include commas.

It would be nice if the user could specify frequency values with common multiple/exponent abbreviations, e.g. "kHz", "MHz", etc. The program would need to validate any user-specified values, and those values would need to be stored in the CSV file as they were input by the user, so that future presentation could preserve the user's format. Values would be converted to an unadorned format prior to passing them to the remote process (as the program currently does).

I'd be happy to implement this feature if it's considered worthwhile.

nellump commented 10 years ago

I have a first draft commit checked into my fork of gqrx-remote, on the branch "flexible-frequencies". From the commit message:

First take at making gqrx-remote abbreviation-aware.

DESIGN FEATURES

  1. New bookmarks have their frequency value parsed and converted to standard SI-abbreviated notation (e.g., "100.1 MHz", instead of "100,100,000"). User-supplied frequency values can include SI abbreviations. They'll still be converted, if necessary (e.g., "1100 kHz" will become "1.1 MHz"). A broad range of positive-valued exponents are recognized (kHz, MHz, etc.); case-insensitive (e.g., "kHz" == "khz" == "KHZ").
  2. Bookmarks have their values stored to CSV in SI-abbreviated notation. Values are not altered when read from the CSV file for display in the bookmark list.
  3. Frequency values are converted back to unabbreviated values when being sent to a remote radio daemon.

AREAS FOR IMPROVEMENT

  1. Users might not want their frequency values munged by the program. In the U.S. (and perhaps other countries), it is common to refer to broadcast AM stations' frequencies in terms of kHz. Currently, the program would convert "1100 kHz" to "1.1 MHz", which may be undesirable.
  2. The program cannot handle unabbreviated frequency values that are not integers (e.g., it'll complain about "100.3").
  3. Some parts of the program could really use unit tests (the pretty-print subroutines, especially).

This commit is functional, but not complete. I'm sure there are still bugs yet to be discovered.