Hi Nate and others,
Am Thu, 23 Jan 2014 08:18:56 -0600 schrieb Nate Bargmann <n...@n0nb.us>: > * On 2014 22 Jan 23:56 -0600, Thomas Beierlein wrote: > > The whole initialization code is very complex and not easily to > > change. It is on my todo list already but changign needs a lot of > > care. Maybe we should write it completely from scratch. > > Here is a hare-brained idea from the peanut gallery. ;-) While I was talking about scoring and contest handling in my mail, you are quite right. It would be good to write a completely new tlf. Question is have we time and man power to do it? Anyway - I am in for it. > > If (and I say "if") a rewrite of some sort is desirable, then it may > be desirable to separate certain parts of TLF into a library so that > core functions such as duping, country lookup, scoring, managing the > log file, etc. would be separate from the UI. Then other UIs could be > written to take advantage of the library so that a TR compatible UI > would share the same core as one written for CT users or a general > logger, for example. As I see it, every logger out there does mostly > the same things and each one reinvents all of these similar functions. > The real differences are the UI and, up until such a libary would > exist, varying degrees of completeness of the common parts. > Right, one of the main things to do is to decouple the UI code from the rest. At the moment it is scattered all around. A second thing to do is to switch input handling to an event driven scheme - no polling of keys anymore. Reason is that most graphical UIs would require such a scheme anyway. Both is on the to-do list. Your other ideas to have a 'generic' logging machine with components for holding qso data, scoring lists and rules, writing cabrillo and so on is a very good and tempting one. And you are right that would allow to concentrate the efforts between different logging programs. I believe that idea was proposed already on the list some time ago. The main work is to define what should go into that library and how to structure it. But it seems worth to be done. > No matter the UI, a callsign given to the country lookup routine would > return the same answer based on the cty.dat installed. Log file > format would be separate from the UI. Perhaps mutliple log format > backends could be incorporated as some users may prefer a flat file > and others an SQL DB and so on. At the moment I would favor a tab separated list for the log format with a header line documenting the order and contents of the columns. That can be easily parsed, extended and even read and written without a special program. It can also be handled with any scripting language without problems. > A common interface would allow > easily reading a log file generated from one UI in another UI. Each > UI would have access to consistent Cabrillo and ADIF export and > import. A C library can be used with just about any other language > so these core routines wouldn't limit UIs to be written in C. > > Thoughts? Besides the above comments one major step forward would be an unified handling of the mass of contest rules around. Ervin did already wrote about that in his answer to your mail. I would like to add a little bit here: If we look over to other contest programs we see that most of them have the different contests hard coded and can simply choose which one to use. Easy for the user - hard for maintenance (it requires a lot of man power for development). N1MM seems to be an exception - he has a contest rule generator for simple cases. Tlf tried another way: Some hard coded contests and some configuration keywords to roll your own rule file. At present the chosen keywords normally solve only special problems. It is not easy to know which one to use without looking into the code and often we miss a keyword and hurry to add just anther special one (Sounds familiar?) As I see it the following could be a good way: - Have some very general keywords to roll your own simple contest. The MY_COUNTRY/MY_CONTINENT_/DX_ POINTS may be a good idea for point scoring. - Have some simple general configurable rules for multiplier counting: What to look at (call, exchange,...), what qualifies as a multi, once per band or once per contest, e.g. COUNTRY, DXCC, PER_BAND or CALL, PREFIX, PER_CONTEST - Allow more than one rule and allow to specify how to combine them, e.g. DXCC and WPX-PREFIX added - What can not be done these simple way (different points per band, special station bonus points, .......) have to be hard coded. These should be doable by the normal ham without a knowledge of the inner working of the program and without a need to compile code for the program. As Ervin told there are two ways. I too would prefer the second one - using a scripting language for that and I too think python is the way to go. It is easy to learn and program, the scripts can be debugged and tested independent of tlf and can be easily integrated into tlf. (I even did some thinking if we can not write the whole program in python...) 73, de Tom > > 73, de Nate >> > -- "Do what is needful!" Ursula LeGuin: Earthsea -- _______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
