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: Thomas Beierlein
Subject: Re: [Tlf-devel] WAEDC Summary - where are we going?
Date: Sat, 15 Aug 2015 11:13:29 +0200

With regard to the bandmap there is really some need to act on. 

There are some limitation in the actual tlf code base which makes it a
little bit difficult to build a quick solution. Thats why the entry
in the issue section on github is still not solved. The main problem is
the old hard coded key recognizer which can not be easily extended.
Changing it to curses key input would be the right way to go but is a
lot work (changing all key codes scattered around the whole program).
It give us the following possibilities:

- tlf window can be made resizeable - that allows room to display more
  information.
- we can add some new key codes (e.g. Ctrl-left, Ctrl-right) to
  navigate in the bandmap with only one keypress.

73, de Tom DL1JBE




Am Sat, 15 Aug 2015 09:13:38 +0200
schrieb Fred Siegmund <address@hidden>:

> 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 <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
> _______________________________________________
> Tlf-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tlf-devel



-- 
"Do what is needful!"
Ursula LeGuin: Earthsea
--




reply via email to

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