caver456
commented
2 years ago The easier topic first:
Yes, we do use two com ports. Our trailer has two mobile radios at the radio operator station. We go DB25 --> DB9 --> USB-A on each one, then combine those both on a cheap USB hub outside the computer so that we only have to plug in one USB-A connector to the computer, but it's still two COM ports, one per radio. It can certainly operate with zero or one USB connection - but this is basically why we have two green lights at the top left of the radiolog main window. When it comes to the fs send functionality, if no acknowledge is received on the first com port, then it assumes the portable radio in the field is probably not tuned to the same channel as is the mobile radio on that first com port, so, it tries the other com port. If it got an ack on the second com port, then it remembers to try that com port first, next time something is sent to that portable radio. It's a runtime per-device determination. It does save a lot of time to not try again on the radio that didn't work last time. BUT, there's also a lot of the com port listening logic that I had a hard time following, even though I wrote it 7 or so years ago and I know it made good sense at the time. So I'm pretty hesitant to rework any of it until/unless a specific need arises. I did some deep diving into it earlier this year when adding the fs send stuff, and it wasn't that bad, but I'm glad that water is under the bridge.
As for the settings, I'm probably under-educated on the topic of the right place to put settings like this. In general, mention of the registry gives me the heebie geebies. That's probably a culturally ingrained holdover from the earlier days of Windows when you would get a BSOD if someone two rooms down the hall muttered the word 'registry' while sneezing. Even now Microsoft is vocal about saying that one could easily brick one's computer by touching the wrong thing in the registry.
Surely QSettings has addressed most or all of those concerns, so that one wouldn't need to go in to regedit and futz with anything directly. Still, I'm hesitant. Trying to analyze why that is, it's probably just lack of familiarity. What's the big advantage of the registry vs .ini? Seems on the surface that .ini is more portable, more universally editable, more readable, etc. The configparser module works pretty nicely, at least a few other repos under ncssar use it, but radiolog hasn't been changed to use it. Sorry if you mentioned it earlier - I did a pretty thorough brain wipe over the past month - but, have you considered .ini with configparser?
On Mon, Sep 5, 2022 at 4:34 PM Erinn Looney-Triggs @.***> wrote:
Welcome back and thanks for merging that. So one of the things we have sort of discussed on and off is the settings and where they are stored. I think you and I are on the same page that the settings should be moved on out of the installation directory and I've been thinking on how to do that. However, I want to make very sure that we are on the same page about this next idea because it will require a fairly significant amount of work I imagine.
My thought here is to move the settings into QSettings (as I've mentioned). This means on windows at least they will be stored in the registry. This is probably more 'proper' but may not be 'right' for your overall design, I don't know. If settings were to be moved from the INI files into the registry this would also imply/require a settings dialog so the user can interface with and change the settings. You currently have your 'options.ui' dialog that is accessed via the sprocket or on first start up. This is sort of close to a settings dialog, but my feeling is you need a 'New Incident' dialog and then a settings dialog separately, not rolled into one.
Along these lines one of the things that has puzzled me in the code base is the, 'fsFirstPortToTry' and 'fsSecondPortToTry' dance that is done. I can't really tease out from the code why you are doing that exactly. You are looking for the most recent com port that was used, but why? Do you run with two com ports regularly? Would it make more sense to have the settings dialog allow for the two com ports and be able to check one as the 'send port'?
Anyway, let me know your thoughts before I dive in, because this is more invasive than anything else I've done.
— Reply to this email directly, view it on GitHub https://github.com/ncssar/radiolog/issues/491, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEPCEZXY2YLYABIGGQI7NV3V4Z7QZANCNFSM6AAAAAAQFKYTAM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
erinn
johnpictin
Welcome back and thanks for merging that. So one of the things we have sort of discussed on and off is the settings and where they are stored. I think you and I are on the same page that the settings should be moved on out of the installation directory and I've been thinking on how to do that. However, I want to make very sure that we are on the same page about this next idea because it will require a fairly significant amount of work I imagine.
My thought here is to move the settings into QSettings (as I've mentioned). This means on windows at least they will be stored in the registry. This is probably more 'proper' but may not be 'right' for your overall design, I don't know. If settings were to be moved from the INI files into the registry this would also imply/require a settings dialog so the user can interface with and change the settings. You currently have your 'options.ui' dialog that is accessed via the sprocket or on first start up. This is sort of close to a settings dialog, but my feeling is you need a 'New Incident' dialog and then a settings dialog separately, not rolled into one.
Along these lines one of the things that has puzzled me in the code base is the, 'fsFirstPortToTry' and 'fsSecondPortToTry' dance that is done. I can't really tease out from the code why you are doing that exactly. You are looking for the most recent com port that was used, but why? Do you run with two com ports regularly? Would it make more sense to have the settings dialog allow for the two com ports and be able to check one as the 'send port'?
Anyway, let me know your thoughts before I dive in, because this is more invasive than anything else I've done.