¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Qlog
  2. Topics

Primary and secondary callbook info

 

In the setup we can set primery and scondary callbook for callsign querry. It's fine and working good.
But it could be fine to have displayed info from which callbook, primary or secondary, data comming. Just short text, e.g. qrz or hamqth.

Slav, EI6KW / SP3RXO
 

Hello,

I can't imagine a situation where I would need to run this and how it could be displayed. As an operator, you don't need to manage this. QLog tries to get data from the sources defined by the operator. If he/she trusts both sources (QRZ and HAMQTH), then it doesn't matter if the information was obtained from QRZ or HamQTH. There is no need to over inform the operator. If I'm wrong, please give me an example of usage.

Regards
Ladislav



p¨¢ 12. 7. 2024 v?13:29 odes¨ªlatel Slav, EI6KW via <sp3rxo=[email protected]> napsal:

In the setup we can set primery and scondary callbook for callsign querry. It's fine and working good.
But it could be fine to have displayed info from which callbook, primary or secondary, data comming. Just short text, e.g. qrz or hamqth.

Slav, EI6KW / SP3RXO
 

Hi,
First of all, do you always trust one source of information, or do you try to check and confirm it with another source? Secondly, if we have a choice of two callbooks, the logical consequence seems to be to show which callbook the information comes from. Thirdly, IMHO, showing this information is much more important than, for example, displaying DX flags which have no any meaning from the operator's point of view and are only an aesthetic addition. And last but not least, if it is a big problem, I can live without it, of course.
How it can be displayed?
Very easy, just short text like 'from QRZ' or 'from HamQTH' somewhere in the New QSO area of main window, it is a lot of space there. BTW, similar feature is used in Log4OM.



--
_ _ _
73,
Slav, EI6KW / SP3RXO
 

Slav,

How to search when both callbooks are defined is described on . It is up to the operator to decide what order to choose. If you don't trust QRZ, then you don't have to use the second callbook option.

Displaying data sources doesn't seem useful to me. It's something the operator will forget anyway, and the ADIF standard doesn't define anything like that to be saved. Later, you won't care whether the data came from QRZ or HamQTH. By the way, displaying the source of the data is not as simple as you describe, because the data can come from the operator and later also from external QSL services (some data is updated if you receive QSL from eQSL or LoTW). It may happen that callbook data is ignored in certain fields under certain situations. This means you would have to display the data source for each field. And you'll agree that's quite user-unfriendly.

QLog takes its own approach and tries to do things differently. It is up to the operator to choose whether to use QLog or another application.

Regards
Ladislav

p¨¢ 19. 7. 2024 v?1:05 odes¨ªlatel Slav, EI6KW via <sp3rxo=[email protected]> napsal:

Hi,
First of all, do you always trust one source of information, or do you try to check and confirm it with another source? Secondly, if we have a choice of two callbooks, the logical consequence seems to be to show which callbook the information comes from. Thirdly, IMHO, showing this information is much more important than, for example, displaying DX flags which have no any meaning from the operator's point of view and are only an aesthetic addition. And last but not least, if it is a big problem, I can live without it, of course.
How it can be displayed?
Very easy, just short text like 'from QRZ' or 'from HamQTH' somewhere in the New QSO area of main window, it is a lot of space there. BTW, similar feature is used in Log4OM.? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?



--
_ _ _
73,
Slav, EI6KW / SP3RXO
 

On Fri, Jul 19, 2024 at 07:28 AM, ok1mlg wrote:

It is up to the operator to choose whether to use QLog or another application.

Regards
You are absolutely right at this point. Your code is your castle.
Thank you for the informative discussion.
--
_ _ _
73,
Slav, EI6KW / SP3RXO
 

QLog should be a community project. Therefore, it is not just my code or my castle.?I can be wrong in many cases, which is normal but there is a need to maintain some direction in its development. QLog should not be a copy of other log applications. The main goal is to determine the scope of development, which should be simple and clear for the operator. Believe me, even QLog does not follow this philosophy in some areas, and I'm very sorry about that, but the Hamradio world is very complex in certain situations. Nonetheless, I still believe it is wrong to overload the operator with unnecessary information like this. For example, when you're searching something on Google, you don't care which Google data center is handling your request. It is similar in this case.

Regards
Ladislav

so 20. 7. 2024 v?0:17 odes¨ªlatel Slav, EI6KW via <sp3rxo=[email protected]> napsal:

On Fri, Jul 19, 2024 at 07:28 AM, ok1mlg wrote:

It is up to the operator to choose whether to use QLog or another application.

Regards
You are absolutely right at this point. Your code is your castle.
Thank you for the informative discussion.
--
_ _ _
73,
Slav, EI6KW / SP3RXO

1 - 6 of 6