[Xastir] Need ideas for messaging changes

[Curt Mills]

I've been tweaking the messaging code quite a bit lately.  It is
still lacking.  Most recently I had a QSO going with a guy on local
RF that was a few hops away.

  He was getting my transmissions.
  I was getting his ACK's.
  I was getting his transmissions.
  He was _not_ getting my ACK's back, so kept transmitting.

Turned out the problem was with the default path(s) set for the
interface.  I had a path that didn't have much of a chance of
getting out.  I had changed the path in the Send Message dialog, but
that path only gets used for the outgoing messages, not for the
ACK's.  That made for a lop-sided QSO until I figured out the
problem.

The current rules in Xastir appear to be:

  Ack: Use the three round-robin paths in the interface properties.

  Outgoing message: Use whatever you type in the Path: field on the
  Send Message dialog.  This gets attached to the message in the
  outgoing queue, so changing it after you hit Send Now! or Enter
  has no effect except for future messages.  If you blank out the
  Path: field on this dialog, you'll have no digipeaters in your
  path (it doesn't default to doing the round-robin thing with the
  default paths).  The Path: field gets filled in with the best
  guess at a reverse path, which may or may not be useful.  In my
  case I find it hard to get to a WIDE directly, and must go through
  a relay digi first.  The reversed paths don't have that of course.


Any ideas on how best to change this stuff to make it easy to use
yet still get messaging done?  Some things I'm considering:

*) Put the guessed reverse path into a label instead of directly
into the Path: input field in the Send Message dialog.  That way you
can refer to the reverse path when trying to come up with a better
path, but it doesn't get used by default.

*) If the Path: input field is blank, revert to the three
round-robin paths in the Interface Properties dialog.

*) If the Send Message dialog is still up, use the current Path:
field for each transmission in the QSO, whether it is a message or
an ACK.

*) If the Send Message dialog is not up anymore, use the saved path
for the message that's in the transmit queue, just like it does now.
What I don't know is what path to use for the ACK in this case.

*) Another thing that would really help is a way to send an extra
ACK or three, sometime after the initial ACK.  Perhaps a button as
well to send an extra ACK if you notice that the station is still
sending the same message.

*) Oh yea, another few changes:  Don't pop up the dialog if we get
yet another copy of a previously received ack or message.  Only pop
it up when something new comes in.  Same for the audio alerts, and
perhaps Festival alerts.

Anyone used messaging enough with Xastir or others to be able to
streamline the above ideas into something simpler that would be
easier to use/maintain?  Right now I think the path stuff is strange
enough as to cause problems during normal QSO's.

-- 
Curt, WE7U.				archer at eskimo dot com
http://www.eskimo.com/~archer
  Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"