[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