RE: [Xlog-discussion] RE: Hold your (xlog-) horses - suggestion

[WILLIAMS,TED (HP-NewJersey,ex2)]

> -----Original Message-----
> From: Joop Stakenborg [mailto:address@hidden
> Sent: Monday, January 07, 2002 4:18 PM
> To: address@hidden
> Cc: address@hidden
> Subject: Re: [Xlog-discussion] RE: Hold your (xlog-) horses - 
> suggestion
> 
> 
> On Mon, 7 Jan 2002 19:34:22 +0200 (EET)
> Tomi Manninen <address@hidden> wrote:
> 
> > On Fri, 4 Jan 2002, WILLIAMS,TED (HP-NewJersey,ex2) wrote:
> > 
> > > Been away for a while, but I'm back.
> > 
> > Me too.
> > 
> > > As for:
> > > > version:1\1program:gmfsk\1date:17 Nov
> > > 2001\1time:1200\1call:PA0DIN\1name:din
> > 
> > Joop, wouldn't '\n' serve as a bit more natural field 
> separator? Just a 
> > thought...
> > 

Also, Joop, watch out for that ":" - you may find it in other places - time
field.

> 
> Sure! Sounds reasonable.
> Tomi, just edit xlog to your needs and send me the patch.
> It's easy enough to release a minor version (0.5.1) for
> xlog, once you get things going with gmfsk.
> 
> > > Here is something you may want to think about for passing 
> this data.
> > > Instead
> > > of passing the message data a string, why not pass it as 
> a struct? (type
> > > cast as 
> > > needed)  That should make retrieving the data fields a 
> lot easier.  
> > 
> > Well, with structs there is always the problem of compatibility and
> > flexibility. We obviously don't have any architecture 
> problems, but I 
> > think things like alignment can be affected by the compiler 
> flags (not 
> > sure though).

Good point, Tomi.  A quick check found several compiler options for
struct padding and boundary alignment.  It looks like no problems if
the options are not used, but... Mr. Murphy

> > 
> > Also as the transferred data will in any case be extended 
> at some point, 
> > we need to be careful about how different versions of the 
> struct are 
> > handled.
> > 
> > I'm not necessarily saying that a struct is not a good way 
> to do it, it 
> > would just have to be well thought out.
> > 
> 
> I would like to stick with the current message format.
> While it will certainly not be the most handsome way of programming,
> I like the flexibility we have now.
> 
> > > Now, who wants to convince me that the data is being 
> passed in the right
> > > direction.
> > > I still prefer the log program passing the data to the app.  HI
> > 
> > Well, I think I was the one who requested the feature from 
> Joop so I can 
> > share my view. My gmfsk program has had the call/name/qth/rst etc. 
> > entry fields from day one and I always thought they are a 
> must. As one of 
> > my beta testers said it: "if your program doesn't have good 
> macros for 
> > automating the qso as much as possible, I won't probably 
> ever have a qso 
> > with it... :-)"

Smart beta tester you have!  Can I use them?   HI
The macros really are great.  I like Peter's keyboard-to-keyboard
philosophy, but macros sure eliminate the repetitive stuff, like
"overs" and make it a more enjoyable mode.  Macro "dumps"
for the whole QSO however get DULL real fast!

> > 
> > I think the name/qth etc. macros are rather necessary for a 
> program like
> > this (but then again I work very little and have had only a 
> couple of qsos
> > even with gmfsk myself so I may not know what I'm talking 
> about). Anyway 
> > I didn't want to make gmfsk dependent on any external 
> program and there 
> > really wasn't any good log programs I was aware of then.
> > 
> > I never meant to implement any log features to gmfsk and 
> never will. 
> > The original idea was to implement exporting the qso data in ADIF format
to
> > some file which could then be imported into a real log program.
> > 

> > With the above, app -> log program is the natural direction 
> for the data 
> > to go. However I don't see why xlog couldn't also export 
> the data in 
> > shared memory to other apps...
> > 
> 

We all agree on what is needed, just where should it be entered :-)

I always teach them the GUI should replicate the "real world".
When I hear a call on the rig, I enter it in the logbook.
So, I ended up going from log -> app.  
 
> Haa! I should have thought if this. This way both Ted and Tomi will
> be happy. I will have a look at Ted's twlog to see how he did it.
>

Now that works for me.  But, more work for you, Joop.

73,
Ted - WA0EIR