tlf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tlf-devel] Tlf QTC support - pre-alpha release :)


From: Ervin Hegedüs
Subject: Re: [Tlf-devel] Tlf QTC support - pre-alpha release :)
Date: Thu, 1 May 2014 14:42:45 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Fred, hello all,

On Thu, May 01, 2014 at 12:50:27PM +0200, Fred Siegmund wrote:
> Fantastic work, Ervin.

thanks :),

> I hope I can test it soon. My time for radio is a bit limited right now. :(

everyone has been so :)

> Am 30.04.2014 00:11, schrieb Ervin Hegedüs:
> >* there are several QTC messages - does it need to possible to
> >   configure the messages?
> >   For example: if you opens the QTC window, Tlf sends a "QTC
> >   QRV". This is one of the many messages. Would you like to
> >   customize these?
> As long the standard not. Shorter is better, "QRV" would be enough.
> Import is that all messages are accessable by
> F-Keys, also after the QTC window has opened. In case something went
> wrong, after CTRL-Q.

you mean, if the QTC window is opened, the Fx keys keeps them
functionality? For example, if the QTC window is open, and you
press F12, then Tlf starts to send automatic CQ? I don't
understand, why does it right.

Anyway, I think the QTC messages could be configurable is not a
bad thing: if someone wants to send "QTC QRV", anyones wants to
send just a simple "QRV". Or there is the final message: everyone
wants to different messages.

May be that would be configured through with this opitions in
rule file:

QTC_QRV=QTC QRV
QTC_R=R
QTC_R_ALL=CFM ALL TNX

and so on...
(there is the another direction - sending QTC, and RTTY mode...)

> >* does it need to see the previous QTC blocks, like the QSO's?
> >   If you pressing the UP cursor, after the 5 lines Tlf hide the
> >   main window, and loads a pager, like "less" - would you like
> >   to see some similar feature? If yes, how would you like to use
> >   that?
> Yes, at least 5 lines would be necessary. Its important if you want
> to catch QTC at a later point of time in the contest. There it would
> be helpful if the calls in the bandmap would show, how many QTCs are
> still needed from this station, or if there is a need for QTCs at
> all.

on the bandmap it's showed, as on the worked window too. And the
info is showed in QTC window, if a callsign is exists in QTC
database, per band!

So, I don't understand this request yet, but the question is
adequate: how would you see the previous QTC's? All in one pager,
or you want to see grouping by callsing, and/or band?

When you in QSO mode, and press 5 times the UP cursor, the pager
(less) is opened in a shell. How should it work in QTC mode?

> >* does it need to delete the QTC's? There are two questions: does
> >   it need to delete only one, or more lines from a unique QTC
> >   block? And does it need to delete a complete QTC block?
> Well, it must be editable. Sometimes it happens that a station stops
> QTC traffic, because condx went bad, and wants to continue with CQ.
> For this a question at closing the dialog, Save Y/N would be ok, if
> QTC traffic was stopped you can press N.

if you pressing ESC, and changing callsign in regular callsign
field, that effects same result - if I understand correctly you.

> >* does it need to show the number of received/sent QTC's on the
> >   main window? That's not a simple question, because on the RTTY
> >   mode, both directions are enabled, so a station can has sent
> >   and received QTC's too.
> Statistics is always nice. :-)

another adequate question: where should I put this info? :)

> >* how could be good to calculate the points? Now if you
> >   send/receive a QTC block, then the number of QSO's in QTC
> >   will be added to the regular QSO's, so you can't see the
> >   total number of QSO's, only if you summary the bands values.
> Make a column for QSOs, QTCs and one for total points. Likely this
> is not compatible with the current implementation :(

yes, that's the problem... :(


any other idea?


thanks,

73,
Ervin
 

-- 
I � UTF-8



reply via email to

[Prev in Thread] Current Thread [Next in Thread]