tlf-devel
[Top][All Lists]
Advanced

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

Re: [Tlf-devel] WAEDC Summary - where are we going?


From: Ervin Hegedüs
Subject: Re: [Tlf-devel] WAEDC Summary - where are we going?
Date: Sat, 15 Aug 2015 09:59:37 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Fred,

On Sat, Aug 15, 2015 at 09:13:38AM +0200, Fred Siegmund wrote:
> I think the most important works have to be done in the bandmap.

yes, but would you elaborate on your ideas in detail related to
bandmap?

> And may be make qtc input a bit less strict, so that you can see where the 
> missing fields are.

I'm also interesting, what do you think about the logic of QTC
handling, and what would be the good way?


Thanks,


73, Ervin

 
> 73 Fred
> 
> ---
> Am 14.08.2015 23:26 schrieb Ervin Hegedüs <address@hidden>:
> >
> > Hello there,
> >
> > there was the WAE CW, my favourite contest. I've really enjoyed
> > it, I've made 270 QSO, and 740 QTC. I gained a lot of experience,
> > how could we develop Tlf, what is the right way.
> >
> > Here are some remark, and I would like to discuss with you, what
> > is your idea?
> >
> > - bandmap general: the bandmap is small :)
> >   we can't change the window size, so the bandmap stay as is now,
> >   but it could be better to shift columns left or right
> >   Alternate solution colud be an external bandmap window, which
> >   is size-independ, and communicates with Tlf throug some channel
> >   (socket, shared mem, tcp (xml-rpc), ...)
> >
> > - QTC's mark on bandmap: not bad, but some info's missing
> >   now, if I made a QTC with a station, then the number of
> >   received QTC are visible near to the callsign; if the number is
> >   10, you can see a "Q" (or "q"), elsewhere you see the exact
> >   number.
> >   Here, I think it _need_ to store somehow, if the station:
> >   - absolutely doesn't send QTC ("NO QTC", and it send more
> >     times)
> >   - stations send "LATER", "NO QSO", or any message, which
> >     indicates, it will be send QTC, but not now
> >
> >   question: how can we mark this stations?
> >   I found out, than OP opens QTC window, and callsign field is
> >   filled, then it can be mark with some keys, eg ALT-F1/ALT-F2
> >
> >   Next, how could be show these stations on bandmap? The "Q" sig
> >   (or "q") is busy... May be the "N" (NO QTC) and "L" (LATER)
> >   would be good... I don't have any idea yet.
> >
> > - the new request feature is affects in "Worked" window too. Now
> >   you can see the number of QTC's (or "Q") near to callsign in
> >   worked window, but if it not on the bandmap, then this is a
> >   very useful and important info
> >
> > - QTC's grab on bandmap: not good
> >   if there is a station on bandmap, which you already had QSO,
> >   but you have less, than 10 QTC, then the callsign is lowercae,
> >   and the color is black - that means, you've already had QSO,
> >   but the CTRL+G jumps over these stations
> >
> >   It could be better that if a callsign is on bandmap, and you've
> >   already QSO with it, BUT you've marked it as "QSO LATER" OR you
> >   have less, than 10 QTC, then CTRL+G will not jump over
> >
> > - QTC record: indispensable feature with small deficit
> >   I think the record is pretty good. The automatic start and stop
> >   trigger are work as well, but I think, it need to show
> >   somewhere, if the record is started. And it need to start and
> >   stop it as manually.
> >
> >   My idea is, if the recording is active, then somewhere in Tlf
> >   window, there would be a blanking red text, eg "REC".
> >   In QTC window, then could be star and stop the record, eg. with
> >   ALT+F3 and ALT+F4.
> >
> >   What do you think about this?
> >
> > - QTC handling: too strict?
> >   Now the flow of receiving of QTC is very strict: you can't go
> >   away, if a field is not complete. The order of fields is
> >   mandatory.
> >
> >   May be if somebody wants (optionally), and configure recording
> >   (automatically or manually - see above), then this severity
> >   is not required - if the OP hears the QTC as well, but
> >   something has happened, and could't fill the field (eg. sender
> >   is too fast - but clear), then just mark the line as
> >   "pseudo-right", and confirms the QTC block. Eg., if somebody
> >   just press ENTER 10 times, but all fields are empty, then it's
> >   no problem - the recorded audio file contains the info, and the
> >   superfast QTC sender is happy :)
> >
> >   What's your idea?
> >
> > So, here are several questions, please think about it, if you
> > interest to it, and let me share your ideas!
> >
> > 73, Ervin
> > HA2OS
> >
> > -- 
> > I � UTF-8
> >
> > _______________________________________________
> > Tlf-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/tlf-devel

-- 
I � UTF-8



reply via email to

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