Re: [Xlog-discussion] Multiple log quicky (0.6 beta 3)

[Stephane Fillod]

> Which brings up another issue: should we fire up the log editor
> before an import, so people can decide how many fields the log
> will have and what the fields names will be?

Not sure about what's best.

* open the log file, find out what fields are available
* fire up the log editor, with field not available shaded (not selected),
  and others selected according to preferences
* let the operator make his/her choice
* import the data

Another possible behaviour:

* always keep all the fields that were in the logfile
* using the log editor, propose to add new fields.


BTW, I've attached a patch that does the following:
* moves all the logfile handling files into a logfile/ subdir. 
* log file support is gathered into the logfile/liblogfile.a archive
* updated some C files for new location of logfile/logfile.h
* Included also the import/export twlog format support. 
* POWER and GMTEND added to types.h. Adapt to your need.


Joop, would it be possible to keep liblogfile.a free of any gtk
dependancy? It would make much more sense. IOW, could you move
new_logwindow and logtype out of logfile.[ch] ?

Next step is to add ADIF/etc. support to liblogfile.a. Too bad logconv is
written in C++ and not using Lex&Yacc. liblogfile could have been shared.

If you're QRV tomorrow, let me know what band, I have a Friday off.

Cheers,
 Stephane F8CFE


PS: 
 wishlist: when using Hamlib, in QSO window, if mode is CW, retrieved RST
           should read something like "5x9" and not just "5x".

twlog-logfile-patch.gz
Description: Binary data