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
After install it would be nice if we could modify individual application config files to update personalised info such as:
Callsign,
Country,
bandplan,
rig(s),
location, etc
as well as named custom lists of specific data ( e.g. a country or regions 2m repeater frequencies)
Most applications have config files which could be modified to include this data.
A possible solution is maybe something like this:
A single - User data file:
a json file of the user's personal info. (entered by them).
All in a single file, possibly prompted for by a python tkinter UI script.
which could be reused across installs.
extras like 2m repeater frequencies would be in separate files which the user would select by name to include.
E.g. SDR bandplan category - selected from a named list of files each containing area specific data.
E.g. a set of options about what to display in the Hamclock app - focused on Ionospheric predictions vs another for EME, or satellites.
For each Application - a config_override file:
a file for each app which indicates:
the location of the config file,
which data will be used from the users data,
which code routine to use to substitute/insert that data (there are many kinds of config files so we would need our main procedure to support several named mechanisms).
this would be added to each app as support was added for that app.
The main program:
a main python program to do the substitutions in the config files.
written as we added support for each program.
run once after install phase completed.
which reads the user config file,
cycles through each supported app,
updating the config files, and
adding/modifying other specific files (like an SDRs bandplan file)
with the additional capability of extracting info from a manually setup config file so sets of useful data can be gathered.
E.g. if a country uses a series of repeaters we could extract this from an sdr bandplan program config file and add it as a named option during setup. (using the above example again)
An advantage of doing it this way is we could take PRs from people adding country specific details as well as support for individual programs and thereby spread the development load.
The text was updated successfully, but these errors were encountered:
Yes I expect a change in config file would fail. so testing to see if the config change successfully would have to be part of release cycle. I expect that the hampi-config command would validate the json files and then report if it was unable to make a specified change. So we would know if it broke substantially fairly quickly.
Off the top of my head I would start with Hamclock because the callsign needs an update and most users probably recenter the map on their location. We can also experiment with changing a config to show sunspot activity vs something else... I'll start a branch soon.
After install it would be nice if we could modify individual application config files to update personalised info such as:
Most applications have config files which could be modified to include this data.
A possible solution is maybe something like this:
A single - User data file:
For each Application - a config_override file:
The main program:
An advantage of doing it this way is we could take PRs from people adding country specific details as well as support for individual programs and thereby spread the development load.
The text was updated successfully, but these errors were encountered: