I think the most important works have to be done in the bandmap. And may be
make qtc input a bit less strict, so that you can see where the missing fields
are.
73 Fred
---
Am 14.08.2015 23:26 schrieb Ervin Hegedüs <airw...@gmail.com>:
>
> 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
> Tlf-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tlf-devel
_______________________________________________
Tlf-devel mailing list
Tlf-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tlf-devel
