Enhancement: New QSO entry tab design

[ikbenkous]

Please note the improved display density and two notes fields. One field for saving data pertaining to this QSO. The other can act as a "station notes", things you can reference when talking to the station. Something like "Operator likes chocolate, has 2 kids, magloop user, feldhell club member, son studying to become operator himself", etc...

@ea4k It seems the QT Designer can 'compile' a QT design to C++ source. Is there a reason why klog doesn't do that?
That would make updating the UI a lot easier!

[ea4k]

I am not using QtDesigner to prevent an additional dependency on another tool.
We can, of course, use QDesigner for mockups but I prefer, up to now, keep the design in the Cpp code.

Regarding the proposal itself, it looks very nice, I like most of it.
I don't k ow it it will fit in the space, but it definitely is worth a test.
Regarding the STATE, it is in the Other tab and @ea5wa is working now to include all the primary subdivisions to KLog.

[ikbenkous]

include all the primary subdivisions
What 'primary subdivisions'? You mean counties?

I think a state entry box near the locator input is smart because:

1. I believe American hams exchange states fairly early & fast during a QSO.
2. States can often (but not always) be calculated from the grid locator and auto filled in. EM00 is in the middle of Texas for instance and has zero ambiguity as to what state they're in. Other grid locators might have 2, 3 or 4 states in them.

The state input box can also be disabled if the callsign isn't American. Or maybe replaced it with a province box. No idea what's smart.

Then again, not everyone is American and lives in states. So maybe we shouldn't have it in the first place?

This can always be revisited, changed or just removed. Small change.

---

I also agree that tool dependency is a pain and it's wise to avoid that.

Regarding the proposal itself, it looks very nice, I like most of it.

This is why I created this issue! I'm glad to hear.
What parts do you NOT like? (Other than the state thing.)
There have to be even more bad parts about my mockup!

[ea5wa]

Looks nice..... Even field "State" is interesting to be used for all the subdivisions I'm working on.... The problem is that depending on the country this field could have different names: States, Prefectures, Oblast, Provinces....

[ikbenkous]

Updating the label on that input field after a callsign is entered might be relatively simple. Is this a bad solution?

[barjac]

I like the improved display density of this proposal as I have complained in the past about the wasted real estate.

I am not keen on the 'state' proposal as it's purely US centric. In the UK the WAB (worked all Britain square) would be more useful and in other countries there are probably dozens of other area identifiers, so I don't think the US deserves a special case :)

Does ADIF actually cater for custom fields anyway?

Surely all this information can be saved in the 'Comment' tab, which BTW should be removed and placed in some of the recovered real estate on the main QSO tab.

I find it very inconvenient that a commonly used field is hidden away in another tab, which then hides the main QSO from view while it is being accessed.

[ea4k]

State is not US centric, maybe the label is US centric and we may rename it.
It is what ADIF calls "Primary Sudivision" and @ea5wa is working to include them all in the database for KLog 2.4.

We can try to add a name for each primary subdivisions and update the label once the DXCC entity is identified and leave "State" for those DXCC that don't have a name for that primary administrative Subdivision. It would not be difficult.

Let's implement first the functionality in the "Other" tab where is today and once it is created, it will be easy to move if needed to another tab.
I agree that it may be interesting to have it close to gridsquare.

[1] http://www.adif.org/314/ADIF_314.htm#Primary_Administrative_Subdivision