Loading ...
Sorry, an error occurred while loading the content.

1767Re: V4 GUI improvement proposal

Expand Messages
  • SV1UY
    Sep 5, 2011
    • 0 Attachment
      Hi Rick again,

      After reading your reply and realising that the changes need quiter a bit of programming and since the conctents of the 3rd window I propose are printed in the top window with a different font I will not insist. The program is OK as it is. The only problem I see is the change over mechanism, but then again the IRS station will attempt to seize the link after a full sentence has been typed in the buffer and the other guy has nothing else to send. I noticed this in my QSO with OH7TE yesterday. The only drawback in this is that if the other guy is a fast typist, you will never get the chance to become ISS until the other guy eventually stops typing. When I have a PACTOR QSO every word I type is sent and I can see it echoed back in a 3rd window. My station does not send the whole buffer as a big packet when I hit ENTER.

      73 de Demetre SV1UY

      --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
      > Demetre,
      > Thanks for the feedback. We have talked about a mechanism for showing the text confirmed received by the other side. While a third text window is possible it really gets to be messy. A better and more elegant mechanism is to use change the type font of the sent text (in the session window...now as blue italic) to something like blue-green italic and that would show which text is received. Note too that you already have a running indication of the confirmed delivered text by the outbound queue size. This shows in bytes how much is left for the other side to receive/confirm by ACK. When it goes to 0 everything has been confirmed delivered.
      > Maybe I don’t understand but the program is already set up for chat and that is just the way I use it for testing. There is no over or BTU command needed.
      > As the receiving station you can go ahead and type ahead and put data in your outbound buffer. It won’t send until you are the ISS and that won’t happen until the ISS has finished sending all queued data. The if you have data it will switch from IRS to ISS automatically.
      > The basic rule is simply this:
      > The ISS stays the ISS UNTIL:
      > 1) He has completed all data (confirmed received by the IRS) and the ISS outbound queue is 0
      > AND
      > 2) The IRS has typed data and has outbound data to send. The IRS outbound queue is > 0
      > When those two conditions are met the switchover occurs and should always be safe. There is an interlock mechanism to prevent a failed IRS<>ISS turnover if both IRS and ISS tried to enter data at the same (or near the same) time.
      > My suggestion of using BTU or some other indicator is just so the other side knows you are really finished typing and not just thinking of more to say with an empty queue. It is not at all required to cause the ISS<>IRS turnover. That is and always has been the idea of V4Chat. Maybe there is a better way to communicate that?
      > One thing that is important in making these suggestions is to think through and get some feedback on the changes before going ahead. E.g. the third window is probably 2-3 days or so worth of programming and testing and really conveys no more information than what is there now using the outbound queue indicator.
      > 73,
      > Rick KN6KB
    • Show all 30 messages in this topic