Request: Export Multiple QSO for same callsign for Labels

[vazquezrodjoel]

It would be good idea to have the option on the log export allow multiple contacts for the same station in the same csv line. This would allow creation of Multi-Contact single labels. CQRlog has similar function that can be used as an example:
https://www.cqrlog.com/help/h22.html#bh4

Havent used in a while, but if I remember correctly what they do is export all contacts for CALLSIGN in the same line, then gLables can be setup to look thru all those points in the csv for each line.

What I used to do, I had 2 gLables templates, one for single contacts and one for multi-contact QSL. For me was easy because I just reply to received QSLs, so that worked.

Anyway, this function would help save some paper and help the environment.

Also (not sure if I should submit a seperate one for this) it would be good to have the date and time with format, like
YYYY/MM/DD and the time like 00:00:00 (either UTC or local, at least to me doesn't matter). It would be easier to read on the QSL card/label.

[foldynl]

There are two things here.

1. Date format. I agree, and I'll rewrite it. CSV date and time format will be in ISO8601 format - yyyy-MM-dd, hh:mm:ss

2. Multi-QSO chaining. I don't like this implementation described in CQRLog manual. What should happen if there are 6 or more QSOs? Should they all be concatenated? Otherwise CSV needs a header. Should header columns be repeated? That's not possible. So this will not be implemented.

[BI6NSL]

Great advice

Multi-qso recommends that users can customize the number of Qsos per label for real-time preview.
For example, clublog's OQRS

[vazquezrodjoel]

My point was not to directly import the way of CQRLog manages these, but a way of doing it. The reason of mentioning CQRlog was because if I rember correctly gLabels was mentioned before in another request, and thats the way in gLabels works (dont know any other way, but that foesnt mean there arent other ways, just I dont know any).

Obviously any label will have limitations because of the size limitations. So definetly the amount of contacts on the same label should be limited somehow.

But, what could be an alternative to achive this, multiple contacts on a single label. That would be the main question.

Ps. Im working on a script, but Im not a developer so is taking time and is not yet ready. But thatbwill print not the label, but the contact with the qsl card. Not the best solution, just a work around for myself.

[foldynl]

Please keep in mind that QLog cannot be adopted to a specific application like gLabels. On the other hands, it must be able to export to widely used standards.

If we adapt QLog to a particular application, users of other applications will request support for theirs as well. This is exactly why standards exist. If a specific application requires a workaround or "hack," it should be implemented outside of QLog.

[vazquezrodjoel]

But we are talking here about CSV files. That is a industry standard, not just for ham radio ops... and like I said, I just want the end-goal, in whatever way possible, CSV, ADIF, any... to Export Multiple QSO for same callsign for Labels.

Besides, I can't relate to the fact of other users/developers to request support for their applications as a bad thing. I mean, if I develop an application is to have the vast majority of the people to use it, to make it enjoyable to them so they can refer it to even more users... why would you don't want that? Not looking for creating an issue or argument, just think that it is a good (I should say great) thing that others consider a software that I develop good enough to bring their users to use this one as well! If not, whats the point of developing it?! I get it, there are many users and so few developers, but if I would spend that much time developing, it should be worth it for the must amount of users possible... Just my opinion, cause this is an awesome piece of a software...

[foldynl]

If not, whats the point of developing it?

A question I have been asking myself very often lately.

an awesome piece of a software.

I would like it to stay that way. Unfortunately, I've been writing more emails lately than focusing on QLog development.

However, I still want that QLog does not contain various hacks made for a single purpose but instead includes generally useful features. The fact that you want to print a QSL card using glabels and need to merge callsigns into a single line is, in my opinion, an example of the hack. This should be handled by an external script that prepares the CSV according to your requirements. How is QLog supposed to know what size QSL cards you have and how many records it can merge? Another settings option for merging? The problem starts growing. Instead, your request can be handled with a simple parameterized script to modify the CSV.

The Linux world was built on the premise that each utility should perform a specific function very well. An application should not attempt to do many things poorly, as is now often the case with many applications that are expanding uncontrollably.

QLog is a logging application. I will not attempt to develop a QSL card editor within it because QLog is not a drawing application. However, QLog must be able to provide you with the necessary data so that you can use another application to prepare the graphical form of the QSL. The responsibility for the design itself lies with the drawing application. If you need to modify the input data between these applications for design purposes, an additional interface - such as an external script - should handle this task.